#ubuntu-devel 2005-05-23
* #ubuntu-devel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
<jdub> live.slug.org.au
<jdub> live from edu expo here in sydney
<tseng> lamont: it would be great if f-spot and gecko-sharp could both be i386 powerpc amd64
<tseng> hi jdub 
<lifeless> jdub: again ?
<jdub> lifeless: weekend expo
<jdub> morning tseng 
<lifeless> arh
<lamont> tseng: gecko-sharp is already 'any'.  f-spot changed.
<tseng> lamont: ta dude!
<lamont> elmo: pls sync PaS 1.566 or later
* tseng looks to see if gecko-sharp is still not building
<tseng> lamont: http://people.ubuntu.com/~lamont/buildLogs/g/gecko-sharp/0.6-2ubuntu3/ < i only see i386 for the last few revisions
<ogra> tseng, arch any
<tseng> ogra: am I missing something obvious?
<tseng> oh
<tseng> I am
<tseng> sorry.
<lamont> tseng: gecko-sharp isn't in breezy
<ogra> lamont, ?
<tseng> thats the source
<lamont> or it's arch: all
<ogra> lamont, ia have it intalled here...
<ogra> installedeven
<lamont> wanna-build -bi386/build-db -dbreezy --info gecko-sharp
<lamont> gecko-sharp: not registered
<tseng> yeah I understand now the x86 built it for everyone
<Burgundavia> tseng, I hate to bother you, but have you seen the latest blam error with the new gecko-cil?
<tseng> the what?
<Burgundavia> Unhandled Exception: System.DllNotFoundException: /usr/lib/mozilla/libgtkembedmoz.so
<tseng> worksforme?
<Burgundavia> gah, ok will update
<tseng> yeah try to give me a little more info please
<tseng> i have that file and all is right as rain
<Burgundavia> just a sec, trying something
<Burgundavia> tseng, ok, found it
<Burgundavia> geck-cil doesn't depend on mozilla-browser anymore, but it still needs it
<tseng> it depends on firefox
<tseng> and is built with firefox
<tseng> hm
<Burgundavia> if it isn't installed, you get that error
<tseng> ok
<Burgundavia> thanks for looking into it
<tseng>  /usr/lib/mozilla-firefox/libgtkembedmoz.so
<tseng> we need to make it use that instead
<tseng> give me 2 minutes
<tseng> buh wth
<tseng> this stupid thing is half in C for no reason
<tseng> blam-gecko-utils.cpp:#include <gtkmozembed.h>
<tseng>   --with-mozilla[=mozilla|firefox|thunderbird] 
<tseng>                           Whether to use mozilla, firefox or thunderbird
<tseng>                           gtkmozembed (default: mozilla)
<tseng> ah I'm dumb
<Burgundavia> it can be built with thunderbird as well? why can't it select at runtime?
<tseng> i guess because its built not very nicely into a C lib
<tseng> and is linked to the wrong place
<Burgundavia> ok
<Burgundavia> don't blame anything on malice, which could be blamed on incompletness instead?
<mkde> does anyone else have problems connecting to key servers using gpg?
<trulux> heya
<trulux> just near to go to bed
<mkde> hi trulux 
<trulux> I'll need to file some bug reports regarding HP all-in-one printers
<trulux> we must track support for them
<trulux> I get mine printing but not scanning
<trulux> though it's recgonized as a scanner too
<bur[n] e1> trulux: same for my HP PSC
<daniels> mine scans just fine
<daniels> i use hpoj to do scanning, but it's a pain in the arse
<bur[n] e1> either of you able to print to it shared via a windows xp machine?
<daniels> I have to stop cupsys, stop hpoj, unplug the printer, plug it back in, start hpoj, then start xsane
<trulux> bur[n] e1: I'll get over it tomorrow ASAP, and contact a folk from HP
<daniels> apparently hplip works fine
<daniels> bur[n] e1: yes
<bur[n] e1> i keep it on my gf's windows box for scanning, but i wanna print to it
<bur[n] e1> daniels: any tips?  or was it pretty painless for you?
<daniels> bur[n] e1: (in the sense that an XP machine can print to it when it's shared from my machine)
<trulux> daniels: could we work on it for Breezy? these devices are pure crack and people is bullying them quickly
<bur[n] e1> i even install unix printing for xp
<daniels> bur[n] e1: worked fine, but this is more #ubuntu than #-devel
<bur[n] e1> yeah yeah
<bur[n] e1> sorry
<daniels> trulux: yah, I know.  printingroadmap will take care of it
<bur[n] e1> i'm also talking the other way ;)
<bur[n] e1> with linux as the client
<trulux> daniels: s/will/we'll/ I take it personal, I need this bitch scanning ;P
<trulux> now I must go to sleep
<daniels> trulux: heh :) well, as I said, hpoj works in the meantime, even if it is a monster hack to get it switching between printing and scanning
<trulux> it's 4:00am here
<daniels> night dude
<mkde> night
<mkde> everyone happily connecting to pgp keyservers with gpg? :(
<mkde> i cannot work out where the problem is, whether its an ubuntu bug, whether its at my isp, or what
<TheMuso> mkde: What address are you using? Have you tried the round-robbin server mentioned in the gpg man page?
<mkde> TheMuso, yes i've tried em all :/
<mkde> #gnupg baffled so far
<tseng> mkde: just did a nice big --refresh-keys
<mkde> tseng, hmm
<mkde> tseng, you don't know of any ports that need to be forwarded incoming do you?
<tseng> no
<tseng> i use it over http
<mkde> tseng, on hoary?
<tseng> breezy
<tseng> but hoary was fine
<mkde> i can't get http working
<mkde> #ubuntu?
<mkde> ok i'm just gonna give up
<mkde> night
<trulux> daniels: just rebooted to see if it's working
<trulux> daniels: could you send to my email the details on how you got scanning of the psc 1315 working?
<trulux> daniels: I'll update hpoj packages to CVS snapshot
<daniels> trulux: er, I've never had a 1315, only a 1210
<daniels> and it's worked with the packaged versions since the warty days
<daniels> wretched hive of scum and villainy
<trulux> daniels: OK, then just send me the details about your one
<tritium> jdub, we had a rather crafty troll today with multiple hostmasks, and we hit the limit on the ban list, apparently
<jdub> heh
<jdub> ouch
<tritium> yeah, looks like daniels is cleaning out the list ;)
<tritium> Thanks, daniels!  By the way, did mako give you the list of ops from the last CC meeting?  What's the proper way to add us to the chanserv access list?
<daniels> no worries
<daniels> nope, he didn't; only jdub can add people to the access list
<daniels> the only ones I roughly remember were you, crimsun and Amaranth?
<daniels> but that was from the discussion at UDU rather than the CC
<tritium> ajmitch_ as well
<daniels> jdub: for i in ajmitch crimsun tritium amaranth; do /m chanserv access #ubuntu add $i 20; done
<daniels> jdub: kthx
<tritium> heh, thanks daniels, jdub.  I'm double-checking the irc logs to make sure there aren't any others.  e.g., possibly ogra
<tritium> okay, the UdU list (http://udu.wiki.ubuntu.com/InternetRelayChat) is correct, best I can tell.  However, dholbach declined, and carlk wasn't present to accept.
<tritium> That's from the log of the CC meeting here: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2005-05-10.html
<zyga> hello
* zyga just read about hp and ubuntu on slashdot
<zyga> interesting, if it's true
<daniels> yeah, it's very much true
<zyga> even more interesting that US got excluded
<zyga> daniels: does HP work with canonical to get every part of that laptop (and I mean evey single one) supported?
<zyga> stuff like working hibernation and wifi?
<zyga> (which is unfortunatly not the case for most laptops :/ )
<daniels> yeah, as I understand it, everything that works on Windows, works on Ubuntu out of the box
<daniels> working hibernation is a given for most laptops, and wifi generally works these days too
<daniels> given we support centrino and atheros out of the box, as well sa prism54 and a couple of others
<daniels> i dare say the majority of laptops with wifi these days would ship with ipw2[12] 00
<zyga> ipw2[12] 00?
<daniels> ipw2100 and ipw2200, the two generations of centrino wireless chipsets
<zyga> daniels: I've got broadcom card that just plainlny ... doesn't work, even via ndis wrapper (it appears but no connection is possible)
<zyga> daniels: ah
<daniels> apparently ndiswrapper has fun issues with breezy's kernel
<zyga> if this works out I'll gladly buy such laptop :-)
<zyga> and hell, I'd see my entire university buy lots of them too
<zyga> we got lots and lots of dells but they work less then great
<zyga> since they are couple of years old it's time to cycle hardware
<zyga> :-)
<zyga> very good thing indeed
<zyga> one thing still puzzles me, why no USA?
<whiprush> you can usually buy a new minipci wifi card to replace that broadcom. Used 2100's and 2200's go for around 20 bucks on ebay these days.
<whiprush> It beats messing with ndiswrapper.
<zyga> whiprush: It's a pcmcia card, even easier to replace
<whiprush> ah.
<zyga> my laptop has no internala antena so that's far less hassle 
<zyga> (strange thing though it does have minipci slot)
<zyga> 'computer freeze program' -- final episode looks interesting :>
<Unfrgiven> hey all
<Unfrgiven> i have an interesting problem... im running "dpkg-buildpackage -S -rfakeroot" and for some reason it is generating a "<package_name>-<version>.tar.gz.cdbs-config_list". whats that all about? how do I stop it generating the file? I'm using cdbs-0.4.28-1ubuntu1
<cartman> morning all
<Nafallo> morning all!
<zyga> hey Nafallo 
<mvirkkil> Doea a plan regarding the menu editor exist??
<mvirkkil> /s/??/?
<cartman> how is Cxx transition going?
<mvirkkil> Does anyone know why firefox doesn't have the gnome theme in hoary? (I was asked this, trying to find the answer)
<zoo> hello
<tgtf> I wanted to start a firefox translation project in to Amharic. But there is no template file in the system. if i just ask would some one put it there? 
<zoo> How does ubuntu automount external usb/iee1394-drives? only by help of udev or does it need automounter support in kernel?
<jdub> tgtf: almost certainly, yes - and help contribute it upstream
<jdub> tgtf: you should chat to mako, he speaks amharic :-)
<tgtf> jdub: I hope mako is listning. can I ask on IRC channel or must send it to the mailing list? 
<hunger> zoo: AFAIK it uses udev/hal/dbus and no kernel support.
<hunger> zoo: I am not 100% sure though.
<zoo> okay, thx
<hunger> zoo: it uses pmount to actually mount.
<zoo> great
* zoo is just building a new kernel
<hunger> zoo: You can always check the ubuntu-kernel's config in /boot/config-version.
<zoo> i know
<zoo> thanks
<jdub> tgtf: he's in the US, so probably not watching at the moment
<zoo> but i am stripping it down to my hardware
<jdub> tgtf: if you send an email to mako@ubuntu.com, he'll get you on the right track :)
<Lathiat> in front of a train
<Lathiat> (hi)
<hunger> Lathiat: ... and heading the wrong way? ;-)
<Lathiat> hunger: heh
<tgtf> jdub: thanx
<pitti> Morning
<Lathiat> evening
<Nafallo> morning pitti
* Nafallo got up early today.
<Nafallo> I looked at the date 15.5 instead of the time :-P.
<Nafallo> jdub: you know if the tool for setting dma on drives from early hoary are coming back in the future? :-)
<zyga> Nafallo: hdparm?
<Nafallo> zyga: is that graphical? :-)
<Nafallo> ooh, I never wrote graphical :-P.
<zyga> Nafallo: nope :] 
<zyga> Nafallo: gedit is grpahica l ;] 
<Nafallo> zyga: naah, I meant a graphical tool that let you check info on drives and stuff.
<Nafallo> zyga: so is gnome-terminal ;-)
<zyga> hehehhe, good point
<Nafallo> zyga: you have to play with mv to make hdparm start where it should, right?
<zyga> Nafallo: mv?
<zyga> Nafallo: what do you mean?
<zyga> Nafallo: /etc/hdparm.conf AFAIR
<Nafallo> zyga: yea, but it S07 in rcS.d here.
<zyga> ah you mean startup time
<tseng> Nafallo: you mean as in after udev?
<tseng> and hotplug
<tseng> so it doesnt fail on cdroms
<Nafallo> tseng: yea :-). it's the cdrom that needs the DMA.
<ogra> tseng, hey
<tseng> yeah just moving the script isnt a great plan
<Nafallo> I keep forget to set it manually :-P
<tseng> the whole system relies on symlinking it
<tseng> hey ogra 
<mdke> hmmm backports
<ogra> tseng, gecko-sharp just needs a one line change in the patch in debian/patches
* mdke muses
<tseng> ogra, blam just needs a hammer and a chainsaw
<ogra> tseng, that too
<Nafallo> hehe
<tseng> yep i was trying to add that line to blam, not gecko
<tseng> silly me
<tseng> ogra: BenM wants our distro patches.. maybe not this one but in general
<ogra> tseng, but blam still crashes for me :/
<ogra> great
<ogra> tseng, lets make a big debdiff session in the end of the process for BenM
<tseng> and for meebey
<ogra> yep
<tseng> BenM only needs debian/patches/00list
<tseng> ogra: oh man he upaded a bunch in svn
<ogra> oh
<tseng> buh, merge
<tseng> he got the __thread fix
<mvirkkil> Riddell: ARGH
<mvirkkil> Riddell: You messed up the formatting of breezy goals. Every single tab was replaced by a space :-(
<Riddell> mvirkkil: oops, I didn't see any tabs
<Riddell> mvirkkil: feel free to revert
<mvirkkil> Riddell: I think it's a bug in kedit or something. It simply refuses to export tabs, it replaces them with spaces.
<mvirkkil> Riddell: Can't. Don't have the rights.
<mvirkkil> Riddell: Did you edit it with an external editor?
<Riddell> mvirkkil: konqueror
<Riddell> does sound like a problem
<mvirkkil> Riddell: I stumbled on that problem when I tried to edit with kedit.
<mvirkkil> Riddell: Maybe it wasn't you ;-)
<mvirkkil> Riddell: Though the diff shows it was caused by your edit: http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals?action=diff
<mvirkkil> But if konqueror automatically replaces \t in forms with a space, I'd say that's a bug in konq.
<mvirkkil> Riddell: Do you know who is responsible for the udu wiki?
<dato> Riddell: what Qt version are you using? 3.3.3 has a bug that does precisely that, IIRC.
<Riddell> dato: 3.3.3
<dato> people complained that e.g. KMail converted tabs to spaces, and it was Qt. fixed in 3.3.4.
<dato> Riddell: there you are.
<Riddell> how evil of qt
<mvirkkil> Truly evil }:-I
<mvirkkil> Riddell: Is that qt version default for kubuntu?
<Riddell> mvirkkil: 3.3.3 is in hoary
<Riddell> 3.3.4 will be in breezy
<mvirkkil> Riddell: Ok. Thanks for reverting the changes. Do you have some other browser you can redo the changes?
<Riddell> I have firefox installed which seems to keep crashing and which doesn't have search inside textareas
<ogra> Riddell, keeps crashing ? works fine here...
<Riddell> or disappearing or something, when I do alt-left
<ogra> hmm, mine swtches pages on alt-left....
<Riddell> damnit, it did it again, something to do with editing large textareas I suspect, is there a way to get a backtrace from firefox?
<ogra> gdb ?
<ogra> strace ?
<ajmitch_> hi
<Riddell> ogra: on BreezyGoals edit the page and move the cursor to near the bottom of the edit box selecting text with shift-left and shift-right
<ogra> works fine
<jdub> dudes
<jdub> http://www.slug.org.au/gallery/edexpo05
<jdub> first set of photos from the edu expo this weekend
<jdub> where we handed out over 500 ubuntu CDs :-)
<tseng> pia is glowing
<mdke> nice
<tseng> radioactive!
<jdub> tseng: don't worry, she's not pregnant
<tseng> k.
<jdub> ;-)
<Riddell> jdub looks pretty orange too
<tseng> that is some costume
<jdub> very handy
<jdub> everyone knew "those crazy orange dudes from the linux booth" :)
<Nafallo> hehe
<ogra> the "orange man group" ?
<jdub> ogra: heh
<ajmitch_> scary
<Treenaks> jdub: you'd do great on "Koninginnedag" (Queen's Day) here in .nl :)
<Treenaks> it's a bit of a tradition to wear orange on that day :)
<jdub> is that roughly translatable to "dress and act like an idiot day"?
<jdub> oh
<jdub> heh :)
<Treenaks> and I've been invited to do a talk about "something ubuntu-ish".. but: I've never done a talk in my life.. ever..
<Treenaks> does anyone have any tips?
<Treenaks> uh
<ogra> speak
<Treenaks> hints
<Treenaks> ogra: that's the obvious part..
<ogra> ;)
* ogra wonders why the buildds are this silent since 11:41
<tseng> im the only person uploading
<tseng> they dont like me.
<ogra> there ares also synced packages that didnt build yet and should retry...
<ogra> but i see only i386 output of gsl for today
<ogra> yay
<ogra> speaking of the devil :)
<tseng> cli-common just built
<ogra> yep
<Treenaks> hey.. cool: http://www.tomshardware.com/hardnews/20050512_124421.html
<ogra> bah
<ogra> The company confirmed that it is working with Ubuntu, one of the smaller Linux distribution providers
<ogra> Elizabeth Phillips, PR Manager for Integrity [...]  said she was not aware of the Ubuntu project.
<ogra> heh
<ogra> mako should send her some shipit boxes !
<Treenaks> ogra: only a few :)
<tseng> 10 bags full
<ogra> yeah
<Loevborg> I know that move will make me consider buying HP.
<Loevborg> (if it's serious, of course)
<ogra> Loevborg, it is...
<tseng> they were talking about it awhile back
<tseng> selling business laptops in the us with freedos installed
<tseng> and a disc with ubuntu and some other linux flavors
<Loevborg> they'd better offer actual support for linux on their laptops instead of justing shpping a cd.
<tseng> heh, "they'd better"
<jdub> Loevborg: canonical provides support
<Treenaks> this must be one of the reasons for the OEMInstaller stuff?
<Loevborg> jdub, that's better :)
<zoo> I just installed a self-built kernel. Now my eth0 is not setup at boottime any more. ifup eth0 helps. I see that in /etc/network/interfaces is no "auto eth0" line. Do I need that? I thought that the hotplug system brings the eth0 up anyway. 
<jdub> zoo: "auto eth0" does it
<zoo> but with an ubuntu kernel it is working without
<mdke> bonjour dholbach 
<dholbach> hellas mdke, how are you?
<mdke> i am very well thanks
<mdke> yourself?
<dholbach> i planned to do something on my thesis today, but ended up here doing some stuff for the c++ transition :-)
<dholbach> but i'm fine, i don't complain
<mdke> hmm
<dholbach> thanks :-)
* jdub sends dholbach to his room ;)
<mdke> what stage is your thesis at?
<dholbach> jdub: i AM in my room :-)
<jdub> d'oh!
<mdke> jdub, you can't send a geek to his room
<dholbach> mdke: it needs love, it really does
* jdub sends dholbach to the norty corner :-)
<mdke> you just feed the addiction
* mdke sends dholbach out walking the dog
<ogra> hehe, remote controlled dholbach ...
<zoo> again, when booting with an ubuntu kernel, I don't need to have "auto eth0" in /etc/network/interfaces. The hotplug system is setting eth0 up anyway. But when I use my self-compiled kernel it does not work like this. How can I enable this hotplugging with my kernel? did i forget something?
<mdke> *grins*
<ogra> dholbach, you should waer your tinfoil head ;)
* doko sends ogra to join dholbach and the dog for a small "walk"
<ogra> doko, i just had one :)
* tseng too
<tseng> stupid dog
<dholbach> me as well
<doko> ogra: last week? ;)
<ogra> doko, .... at the right speed for a walk btw ;)
<dholbach> jdub: what is the "norty corner"?
<tseng> naughty
<tseng> with a silly australian accent
<mdke> *laughs*
<mdke> we use that here in england too
* dholbach couldnt find it in any dictionary
<tseng> schlesht?
<jdub> dholbach: when little kids are naughty, a common punishment is to send them to the corner
<dholbach> i see
<jdub> it's very brutal and fascist ;)
<doko> jdub: he should know this, that's usual here as well :)
<dholbach> if all of you guys were working on the c++ transition, i wouldnt be here
* mdke gets out his ruler
<tseng> dholbach: way to pass the blame
<ajmitch_> dholbach: we are working...
<dholbach> tseng: i have no other choice... if i get remote controlled it's only appropriate to pass the blame
* Nafallo studies for his frenchtest tomorrow *
<ajmitch_> dholbach: feel free to assign some c++ packages to me to fix
<jdub> ha ha ha
<dholbach> everybody just sign up for packages on CxxLibraryList :-)
<ogra> jdub, 100yrs ago in germany the kids also had to wear paper hats
* ogra hands dholbach a paper hat
<ogra> *g*
<dholbach> you all... get a grip!
<ajmitch_> dholbach: I seem to have run out of packages to fix after doing the ones there
<mdke> *grins*
<mdke> cool paper hat idea
<mdke> good old days
<dholbach> ajmitch_: there are "some" packages left :-))
<ajmitch_> dholbach: good, I can't choose which ones to do, so throw some my way ;)
<dholbach> i will do mine
<dholbach> not exactly now, but i will do them :-)
<ajmitch_> ok
<ogra> tseng, Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object
<ogra> in <0x00023> PixbufUtils:Fit (Gdk.Pixbuf,int,int,bool,int&,int&)
<ogra> in <0x00052> PixbufUtils:ScaleToAspect (Gdk.Pixbuf,int,int)
<tseng> yes
<ogra> looks like f-spot has the gdk problem too
<ogra> so it might lie deeper down.... not at the application level....
<tseng> is that f-spot 0.0.13?
<ogra> yep
<tseng> wtf
<ogra> with some small changes (dh_clideps etc)
<ogra> tseng, form mono: debian/patches/02_soname_map.dpatch:-   <dllmap dll="libgdk_pixbuf-2.0-0.dll" target="libgdk_pixbuf-2.0.so" /> 
<ogra> debian/patches/02_soname_map.dpatch:+   <dllmap dll="libgdk_pixbuf-2.0-0.dll" target="libgdk_pixbuf-2.0.so.0" />
<tseng> yes?
<ogra> dunno if thats correct...
<tseng> to check it we have to grep around for DllImport of gdk_pixbuf
<tseng> i doubt it is loading .dll explicitly
<tseng> is that on /etc/mono/config?
<ogra> nope
<tseng> so..
<ogra> but
<tseng> what file
<ogra>  ldconfig -v |grep libgdk_
<ogra>         libgdk_pixbuf_xlib-2.0.so.0 -> libgdk_pixbuf_xlib-2.0.so.0.400.10
<ogra>         libgdk_pixbuf-2.0.so.0 -> libgdk_pixbuf-2.0.so.0.400.10
<ogra>         libgdk_imlib.so.1 -> libgdk_imlib.so.1.9.14
<ogra>         libgdk_imlib.so.1 -> libgdk_imlib.so.1.9.14
<ogra>         libgdk_pixbuf-2.0.so.0 -> libgdk_pixbuf-2.0.so.0.600.7
<ogra>         libgdk_pixbuf_xlib-2.0.so.0 -> libgdk_pixbuf_xlib-2.0.so.0.600.7
<ogra> amd64 prob it seems
<ogra> the 32 bit libs are libgdk_pixbuf-2.0.so.0.400.10
<ogra> the 64 bit ones libgdk_pixbuf-2.0.so.0.600.7
<tseng> ahah
<tseng> well that is craptastic
<tseng> would you mind working with lewing on that? I had really great success getting him to fix other (similar) issues upstream
<tseng> or we can hack around installing 2 seperate config files
<ogra> tseng, let me talk to tollef first
<tseng> ok.
<ogra> there is also ... warning: could not find path for ld-linux-x86-64.so.2
<tseng> cant help you there either :(
<ogra> thats definately a thing i need explanation for from tollef 
<ajmitch_> night all
<tseng> bye ajmitch_ 
<tseng> jdub: time to test new gamin!
<tseng> jdub: dude.. it doesnt suck
<tseng> jdub: upload!
<jdub> tseng: fab asked me to wait for his next kernel :)
<Lathiat> jdub: got a test one?
<Lathiat> man pizzas are sucha  rip
<Lathiat> $16.95 for _ONE_ pizza delivered.. fortunately they have a coupon on their website for $10 delivered
<zoo> Lathiat: what a scam
<Lathiat> zoo: ooh yeh
<Lathiat> you can get it down to like $7 per pizza if you buy two and have the right voucher
<zoo> i never pay more that 7$ per pizza, even if it's delivered
<lifeless> zoo: where do you live ?
<zoo> lifeless: germany
<zoo> lifeless: and you?
<lifeless> AUD.au
<lifeless> so you nevceer pay more than 7 marks ? whats the exchange rate ?
<lifeless> :)
<zoo> lifeless: ha ha ha, we use EURO nowadays
<zoo> shit shit, i meant 7 
<lifeless> thats 14 AUD IIRC
<lifeless> Lathiat was talking AUD  
<zoo> anways, i always bake my pizzas myself 
<Lathiat> yeh
<Lathiat> 14aud is abotu 7 euros
<Lathiat> which is what i paid
<Lathiat> 13.20 for pizza+garlic bread
<opi> hi
<mdke> zoo, ++
<mdke> its all about home made pizza
<ogra> tseng, still alive ?
<tseng> ogra: yes
<ogra> grep db2 /etc/mono/config
<ogra>         <dllmap dll="db2cli" target="libdb2_36.so"/>
<tseng> another amd64 miss-number?
<zoo> mdke: I always bake a whole plate and eat it on my own :)
<ogra> tseng, i think its more general
<ogra> tseng, libdb2_36.so doesnt exist, we only have libdb2.so
<tseng> i only have .so.2 and 1.so
<tseng> ok
<ogra> libdb2.so.2
<ogra> yep
<zoo> mdke: cd pizza-1.6-dev-cvs; make --with-onions --with-pepperoni --with-peppers --with-special-cheese
<ogra> zoo, does that work with gcc4 ?
<zoo> ogra: when you check it out from cvs, yes
<zoo> ogra: but you need very very recent yeast from cvs, too
<ogra> it should have a gjc run afterwards as well to get the kaffee
<tseng> ogra: hm it looks like we arent patching mono/config anymore
<ogra> tseng, yes, i noticed, there is debian/patches/02_soname_map.dpatch that seemsnot to get applied
<tseng> alot of it is fixed
<tseng> we have awesome upstream support now dude, so everything we can should go there
<ogra> ok
<tseng> the rpms are now patch free
<tseng> we can get close
<tseng> do you have a list/memory of your stuff so far?
<ogra> hopefully
<tseng> we should make a wiki page
<ogra> yep
<tseng> because its getting to be too much for me to give off the top of my head
<tseng> ill make a section for each app, then changes from debian and upstream
<ogra> i'll just have to look at the debdiff in the end...
<tseng> benm says drop 07 in mono
<tseng> for 1.1.7, so there are no patches there
<tseng> i started putting it on MOTUMono
<tseng> but i need to work look at gtk#2
<tseng> see if this svn snapshot from upstream works all right
<vuntz> hi
<vuntz> mjg59: ping?
<vuntz> mjg59: I made a small program to handle the hotkeys that generate acpi events so that they can be useful in gnome
<vuntz> mjg59: If you're interested: http://www.gnome.org/~vuntz/gnome-acpi-keys-0.1.tar.gz
<vuntz> most of the code comes from gnome-control-center
<vuntz> and with the right scripts in /etc/acpi, it works nicely :-)
<vuntz> at least here
<pitti> Hi
<KaiL> vuntz: but that's only usefull for gnome?
<vuntz> KaiL: it works the same way than the gnome-settings-daemon does, i.e. it looks for some things in gconf
<vuntz> KaiL: but it can certainly be made more generic
<ogra> vuntz, hmm, could i use it to replace the weird acerhk crack ?
<vuntz> KaiL: you can also use it without running gnome, but it'll launch a gconfd
<vuntz> ogra: I don't know the acerhk crack, so I don't know
<ogra> acer laptops only are able to send otkey keycodes, but no events... the acerhk patch bends the kernel in a way that they generate events instead, but its a weird hack
<ogra> s/otkey/hotkey
<ogra> so having such a remapping done in userspace would be rad
<vuntz> ah
<vuntz> no, it won't solve your problem
<ogra> sad...
<vuntz> I have the same situation for my asus
<ogra> next time lets buy ibm or hp ;)
<vuntz> the program I wrote is just a quick way to use the generated events
<vuntz> ogra: ahah
<ogra> ah, so rather something to attach to pmi
<KaiL> vuntz: be happy then - the only report about an Asus laptop I have goes: "boot with acpi=off, else it won't start"
<ogra> KaiL, but that problem ies deeper down :)
<ogra> lies even
<ogra> (kernel layer)
<KaiL> ogra: yes :/
<KaiL> but Asus + Linux is really a bit problematic
<karim> hi
<tseng> ogra: do you have a patch for your manpage fixes?
<ogra> tseng, nope, but i'll make one of it
<tseng> ogra: awesome!
<trulux> pitti: ping
<pitti> trulux: I'm half here
<trulux> pitti: I'm working on a school-related thing, just wondering if you could update -hardened packages to latest grsec and even take patches from http://pearls.tuxedo-es.org/gentoo/hardened/kernel/hardened-patches-2.6-11.3.tar.bz2
<trulux> pitti: almost finished the patch
<trulux> pitti: BTW, TCP src ports randomization should be enabled by default, same as pids
<trulux> pitti: there's no sense on making it sysctl'able
<pitti> trulux: not today, I'll look at it next week
<trulux> pitti: OK, no worries. I need to release the spec. ASAP though
<pitti> bye
<CarlK> ubuntu-5.04-dvd-amd64.iso.torrent has 0 seeds.  shouldn't the original always be "up" ?
<zenrox>  hears a good question what file do i need to edit to change to get my specal vol key to change the vol on the pcm vol control and not the master?
<CarlK> zenrox - 
<CarlK> zenrox - im answering in #ubuntu
<zenrox> ok
<mkde> is there a decent GUI for changing boot services in universe or something? if not, could I suggest one which might be of interest
<thom> mkde: there's not one i know of, so if you wanted to suggest one go ahead
<mkde> ok
<mkde> its called Ubuntu Bootup Manager
<mkde> screenie http://mdke.mine.nu/ubm.png
<Loevborg> the beautiful 404 boot service manager.
<mkde> damn
<mkde> sarky
<mkde> capitalise UBM sorry
<mkde> screenie http://mdke.mine.nu/UBM.png
<Loevborg> mkde, IMO, the whole bootup process needs to be revamped (drop runlevels, get rid of scripts, parallelize, allow for user-level services) anyway
<mkde> Loevborg, yes i agree, but thats not what i wanted to talk about
<Loevborg> mkde, what does it do when you uncheck the "boot" flag?
<mkde> it stops the service starting at boot
<Loevborg> mkde, I mean, how does it disable it
<mkde> its a frontend for update-rc.d
<Loevborg> ah.
<Loevborg> it doesn't disable the service.
<mkde> it does it properly in accordance with debian policy
<Loevborg> (because, there's no way to properly do that AFAIK)
<mkde> http://www.marzocca.net/linux/ubm.html <-- download http://www.marzocca.net/linux/ubmdocs.html <-- explanation of how it works
<trulux> argh, still not getting the psc 1315 scanner working
* trulux feels stupid with that
<blueyed> The torrents are still down.
<mdke> mako, around?
<dholbach> Rickdangerous! i loved that game :-)
<Rickdangerous> dholbach, yes I'll always remeber that christmas (that've played first)
<dholbach> :-))))
<dholbach> hey seb128 
<seb128> hey dholbach !!
<tseng> hey dudes
<dholbach> seb128: long time no see
<dholbach> hey tseng 
<seb128> dholbach: as you say :)
#ubuntu-devel 2005-05-24
<mxpxpod> is it alright to use linux-source-2.6.12 from breezy in hoary?
<tseng> works for me
<tseng> just doesnt have -restited-modules yet
<tseng> restricted
<KaiL> mxpxpod: you only need to update one other package
<srbaker> anyoen here experiencing difficulties with gnomebaker?
<srbaker> it won't seem to burn for me, but nautilus burns just fine (or appears to)
<Burgundavia> srbaker, more a question for #ubuntu
<mxpxpod> tseng: well, I don't use anything out of -restricted
<tseng> mxpxpod: its worth a try
<mxpxpod> tseng: are you using the binary?
<tseng> yes
<zul> mxpxpod: i havent had any problems with 2.6.12 yet
<mxpxpod> tseng: also, what version of .12 is it? -rc4?
<tseng> i guess
<zul> rc4
<mxpxpod> zul: awesome
* mxpxpod wants benh's new patches :)
<zul> mxpxpod: im using x86 though
<mxpxpod> zul: ok, so how do I know if the powerpc binaries have been updated to -rc4?
<zul> mxpxpod: its built from the same source
<zul> i dont have a ppc so i dont know how well it works
<mxpxpod> zul: right, but generally ppc gets built after i386
<mxpxpod> zul: what exact version is your linux-image-2.6.12?
<zul> mxpxpod: try it and see..:)
<zul> latest one
<mxpxpod> :P that's helpful
<zul> 1.1
<mxpxpod> 2.6.11.92-1.1?
<zul> yep
<mxpxpod> cool
<mxpxpod> ouch... to install linux-headers-2.6.12, I have to have the new libc6
<tseng> you didnt dist-upgrade?
<mxpxpod> tseng: no, I'm still using hoary
<tseng> i think i missed that part.
<mxpxpod> topic in #ubuntu says to not use breezy ;)
<tseng> good call
<mxpxpod> KaiL: so, you're using hoary with a breezy kernel?
<KaiL> well, I have it installed on my K6-2, but as I need the nvidia driver there for now, I haven't tried it that much there
<KaiL> also installedon this K7, but not used yet and on my K8 (with runs breezy)
<mxpxpod> ah, ok
<dholbach> mxpxpod: stop, better wait
<dholbach> we're doing the c++ transition
<mxpxpod> dholbach: huh?
<dholbach> and it will break all your fancy stuff
<mxpxpod> dholbach: oh, I'm not doing a full breezy upgrade
<dholbach> -> g++-4.0
<wasabi> it's really frustering trying to help peopl in #ubuntu
<mxpxpod> I just want 2.6.12
<KaiL> dholbach: that's why he shouldn't update to breezy but only try the kernel ;)
<mxpxpod> tseng: you've got an ibook, right?
<tseng> dell
<mxpxpod> oh, right
<mxpxpod> for some reason, when my ibook comes back from sleep, usb hotplugging doesn't work
<mxpxpod> so I have to restart hotplug
<dholbach> mxpxpod: prod pitti :-)
<mxpxpod> dholbach: I'm not sure whether its a userspace issue or a kernel issue
<dholbach> i think i'm going to bed now
<dholbach> sleep tigh guys
<mxpxpod> night dholbach 
<dholbach> mxpxpod: he has the same problem, maybe he will care enough to fix it :-)
<mkde> night dholbach 
<KaiL> mxpxpod: with 2.6.10 or 2.6.12? ;)
<dholbach> bye mxpxpod, mdke 
<mxpxpod> KaiL: huh?
<KaiL> ah, ok
* KaiL should read first, ask then
<mxpxpod> KaiL: the hotplug problem happens with 2.6.10
<mxpxpod> ok, brb... gonna boot into 2.6.12
<bluefoxicy> tseng:  I feel your pain.
<mxpxpod> sooo, that didn't work so hot
<mxpxpod> pbbuttonsd didn't like the new binary kernel
<Loevborg> is it a known problem that hoary's gcc crashes while compiling mplayer?
<bluefoxicy> clamav 0.85 is out and has significant improvements over 0.83
<tseng> thats great do you have an updated source package?
<bluefoxicy> all I can find is tar.gz
<tseng> well, yes.. i meant did you make a package
<bluefoxicy> tseng:  maybe if I had any clue how to actually make a source package.
<tseng> well thats the point of this channel
<tseng> people making source packages.
<bluefoxicy> show me later.  I can probably adapt the clamav-0.83 one if someone shows me htf to do it.  :/
<bluefoxicy> for now I want to find out how to write a plug-in for nautilus
<pixelmonkey> wow, I just tried out gtkwifi... finally a simple and nicely done wireless network selecting applet.
<KaiL> some known IDE issues with 2.6.12 and VIA KT133?
<jsgotangco> hello
<ajmitch_> hi jsgotangco 
<jsgotangco> ajmitch_, hey how was your weekend
<ajmitch_> pretty good, how about you?
<tseng> hi ajmitch_.
<ajmitch_> hello tseng 
<jsgotangco> not bad, was hot though, we went to a nearby pool
<jdub> I LOVE BEING A TURTLE!
<lifeless> ok
<lifeless> you need more dried rabbit
<tseng> jdub: turtles have no pants.
* lu|away turns jdub upside down
<tseng> elmo: if you could clear NEW before cxx freezes it that would be rad.
<tseng> g'night all
<jsgotangco> night tseng 
<jbailey> dilinger: Around?
<jbailey> dilinger: Wondering what you think of  supporting a hack in cdbs where if DEB_BUILD_OPTIONS="ccache", that it changes CC="$(which ccache) ${CC}"
<daniels> awesome
<daniels> Gnome - Window switching shortcut is "@" in CF (french-Canadian) keyboard.
<daniels> Impossible to write any mail in Ubuntu 5.4 with "CF" keyboard. "@" is
<daniels> combination of "alt-car" (the "alt" on the right) and "2" on the CF keyboard
<Unfrgiven> elmo: ping?
<daniels> Unfrgiven: it's 0436 in the UK
<Unfrgiven> daniels: so you're saying he might be asleep? ;)
<bluefoxicy> oh god this is painful.
<AndyFitz> daniels,  have you got any artists to recommend listening to
<daniels> AndyFitz: plenty
<daniels> AndyFitz: right now I'm listening to a DJ Craze set; other good ones include TZU, Squarepusher, Fabio, High Contrast, Boards of Canada, Pendulum, UNKLE, et al
<jsgotangco> heh nice selection
* jsgotangco likes listening to classic chillout music when working
<AndyFitz> daniels,  great list cheers mate. 
<AndyFitz> jsgotangco,  loved the chillout music while working . then I realised I wasn't getting any work done :-)  .   now I listen to a genre that is in my opinion crappy music  but is awesome for the graphics work.   psytrance.   its horribly productive but I get sick of it quick
<mpt> AndyFitz!
<AndyFitz> mpt!
<mpt> how's work?
<AndyFitz> its pretty rad,  check out my IP ;-)
<mpt> Eh.
<blahrus> AndyFitz: redhat?
<AndyFitz> blahrus,  contractor
<blahrus> ahhh
<blahrus> thats cool though
<mpt> AndyFitz: Are you doing stock toolbar icons, or just file/folder/program icons?
<AndyFitz> mpt,  Im still in the search of an army of graphics ninjas to help out set up and work on the project.   yes I intend to do stock icons. I've already done some
<mpt> cool
* AndyFitz needs time and help :-S
<mpt> Coz every time I use Epiphany, I'm bothered by the Home icon, it looks like the house is falling down.
<AndyFitz> mpt,  yeah back,forward home stop are bit on the list.      
<AndyFitz> I've got a little list of pixmaps I need to track and replace also.  ( like the firefox one  that is displayed in metacity )
<mpt> the Waterworld icon
<mpt> AndyFitz: Should there be an icon style guide on the wiki?
<AndyFitz> mpt, there should be an icon development website, repository and roadmap
<AndyFitz> styleguide,  asset repository
<AndyFitz> everything
<mpt> http://www.ubuntulinux.org/search?SearchableText=icon is weird
<mpt> AndyFitz: Well if I knew who to pester about that, I would :-)
<AndyFitz> its more about doing than about pestering 
<AndyFitz> I can pester cause I havent got the skills to set it all up
<AndyFitz> hehe
<AndyFitz> if you have the skills theres no excuse 
<mpt> nope
<count0nz> any TV Dev's in here ?
<bluefoxicy> damnit is this right
<bluefoxicy> cap_p = cap_from_text("CAP_DAC_OVERRIDE,CAP_DAC_READ_SEARCH=pe =i");
<bluefoxicy> permitted and effective dac override and read-search; inheritable none
<count0nz> your heating on?
<count0nz> opps
<AndyFitz> Bam, retrotastic
<count0nz> Hay is there a link to where i can see what packages are being worked on anyone doing xawdecode , xdtv ?
<daniels> fabbione: ping
* Amaranth goes to bed
<daniels> fuck
<daniels> lamont: ping
<AndyFitz> http://andy.fitzsimon.com.au/messin.png
<AndyFitz> http://andy.fitzsimon.com.au/messin.svg
<Burgundavia> AndyFitz, nice
* Burgundavia is waiting for inline svg in the fox
<zyga> good morning everyone
<AndyFitz> morning zyga
<AndyFitz> http://andy.fitzsimon.com.au/messin.png  http://andy.fitzsimon.com.au/messin.svg   
<AndyFitz> bling
<jsgotangco> whoa
<jsgotangco> major bling
<whiprush> Fridge!
<jsgotangco> whiprush, hey
<whiprush> that's hot bling man
<whiprush> hey
<AndyFitz> pimptastic
<jsgotangco> make sure its yellow bling heh
<jsgotangco> and lots of red
<jsgotangco> heh
<whiprush> very 50's art deco
<AndyFitz> yeah I'll chrome, shade and radify it ... ;)  if its approved 
<Lathiat> hahaha
<Lathiat> thats mad
<Lathiat> except some people will kill you ;p
<AndyFitz> b&w is the best proof of concept tho ..  ant it works on faxes, t-shirts and other paraphernalia 
<AndyFitz> ant=and
<AndyFitz> jdub: ping
<AndyFitz> Lathiat,  what do you mean mate ?
<whiprush> I like the one just bottom right of the ubuntu logo one
<Lathiat> all i have to say is
<Lathiat> THE! FRIDGE!
<AndyFitz> the typeface evolved from bitstream vera sans bold oblique .. musclecar-ed it up :)
<Burgundavia> AndyFitz, I like the big typeface in the bottom with the old style fridge
<AndyFitz> Burgundavia,  the potato style ?
<Burgundavia> ya
<whiprush> the pill looking one is cool
<JaneW> does anyone else have UDU photos which they'd like to share?
<AndyFitz> the capsule is used with the ubuntu logo . its the only way I could make a connection without actually putting the logo
<AndyFitz> JaneW,  I have a few but not accessible from here.
<whiprush> I just linked my photo's to the one wiki page.
<whiprush> anyone have a link to that big group picture we took at the end?
<JaneW> whiprush: yes thanks I picked those up, I put a link to them from the warthogs page too, that ok?
<whiprush> sure.
<whiprush> warthog's page?
<JaneW> whip yes tha's on er... Jblacks page, go look at the links, pic #1
<whiprush> k
<JaneW> whprush: I loved your blog footage btw, esp the uduflu!
<whiprush> heh
<jsgotangco> hey JaneW how is your weekend
<whiprush> wow that picture turned out great.
* whiprush saves
* JaneW *LOL* at mako in that one
<JaneW> mjg59: you here?
<whiprush> is that mako under the poster?
<whiprush> heh
<JaneW> whiprush: yeah :)
<jsgotangco> yeah
<jsgotangco> hehe
<jsgotangco> there was also a photo with mdz trying the headspin
<JaneW> I got that one, not a get pic though a bit dark. It's pic #1 on my page
<jsgotangco> JaneW, on the BreezyGoals page, we're the ones supposed to change the status of our projects?
<jsgotangco> oh wait i just read the page
<jsgotangco> theres an explanation now
<JaneW> jsgotangco: yes, or mail/msg me and I can do it for you. I am sending out a nag mail right now :) Trying to avoid it?
<Burgundavia> jsgotangco, I have a tester for PDA stuff
<Burgundavia> jsgotangco, do we want to put out a general call on -users?
<jsgotangco> Burgundavia, i have some wiki pages i ripped from mjg59's wiki
<jsgotangco> similar to that
<jsgotangco> http://www.ubuntulinux.org/wiki/PDATesting
<zyga> AndyFitz: nice fridge :-)
<AndyFitz> cheers zyga
<zyga> AndyFitz: any specific reason to make a fridge?
<Burgundavia> jsgotangco, still a little confused
<jsgotangco> Burgundavia, needs to be fleshed out more
<AndyFitz> zyga,  talk to jdub ;)  http://udu.wiki.ubuntu.com/TheFridge
<Burgundavia> jsgotangco, ok
<zyga> AndyFitz: interesting
<whiprush> thefridge will rule.
<jsgotangco> if you build it :)
<whiprush> who says it isn't yet? :p
<whiprush> (mysterious music)
<zyga> firefox should have some bookmarks so that new users will find such sites easiyly
<zyga> easily
<jsgotangco> including (the fridge)
<AndyFitz> whiprush ,  I'm creeped out already  :)
<JaneW> anyone know how to get hold of tseng>
<JaneW> ?
<AndyFitz> JaneW,  he isnt on Aim, jabber etc 
<JaneW> AndyFitz: his whois says ~tseng@mail.thegrebs.com, but that bounces back
<JaneW> as does tseng@mail.thegrebs.com
<Nafallo> JaneW: trying to send e-mail? :-)
<Burgundavia> JaneW, you can ping him here
<Nafallo> or use the mailaddy in his nickserv info :-)
<AndyFitz> janeW,  he's online on jabber
<AndyFitz> just away
* JaneW did ping tseng earlier - no response, and I don't see him on jabber...?
<jsgotangco> i think he said good night a few hours ago
<JaneW> ok. I need to nag him to update a Breezy Goal ;)
<JaneW> I'll wait till he wakes up ;)
<ogra> JaneW, if its about mono i can probably help out...
<ogra> morning everybody
<Nafallo> morning ogra :-)
<Burgundavia> salut ogra 
<Unfrgiven> elmo: ping?
<JaneW> ogra: no it's about IntroDeveloperDocs
<ogra> ah, ok
<Burgundavia> JaneW, I might be able to answer that
<JaneW> ogra: I am just chasing the people who need to finish updateing the Breezy Goals page. You included... ;)
<Unfrgiven> tritium: ping?
<JaneW> Burgundavia: cool wanna update the page?
<Burgundavia> JaneW, what do you need answered?
<ogra> JaneW, yep, saw your mail right after my sentence ;)
<jsgotangco> the spec
<ogra> JaneW, the list is missing WIP ?
<Nafallo> JaneW: you should add an explanation for WIP to :-).
<Burgundavia> ogra, seen this? http://ubuntuforums.org/showthread.php?t=27740
<ogra> Burgundavia, yep, i know the tool
<azeem> what about fixing/improving the services component of the gnome-system-tools?
<ogra> azeem, to many options
<ogra> azeem, (in the tool)
<Burgundavia> ogra, ok, just checking
<ogra> azeem, http://udu.wiki.ubuntu.com/GraphicalConfigTools
<azeem> ogra: well, that's what I meant with 'fixing' I guess :P
<ogra> Burgundavia, btw, bootup manager is far from being an appropriate name for the app ;)
<Burgundavia> ogra, yes
<Burgundavia> ogra, names can be changed easier than UIs and code
<ogra> hehe, yes
<jordi> moo
<Burgundavia> http://udu.wiki.ubuntu.com/CalendaringSynchronisation says hula in main
<Burgundavia> is this true?
<ogra> hey jordi :)
<Burgundavia> jordi, bah
* ogra lols
<Kamion> morning
<ogra> hula in MAIN....
<Treenaks> main? wtf?
<jsgotangco> hmmm...really?
<Burgundavia> would be nice, but is it really mature enough?
<ogra> if you rewrite the backend before ...
<Burgundavia> there is serious work being done on both ends of the app
<GheRivero> res
<JaneW> ogra: oh sorry. it's Work In Progress, but I'll update now
<ogra> JaneW, i know what it is ;) its just missing as an option in your mail  :)
<JaneW> Burgundavia: it needs a current status, and I resume it does NOT affect the kernel (since it's just a set of docs?)
<Burgundavia> JaneW, no idea as to current status, but it does not affect the kernel (unless tseng is doing something really strange)
<jsgotangco> JaneW, its still drafting i believe, most of the stuff in the wiki are whiprush's notes
<JaneW> ok, should I set it to drafting then?
<jsgotangco> yes will have to bug tseng and whiprush about this
<Nafallo> Burgundavia: tseng's plan was to start writing this on the wiki IIRC? if so, and it isn't there it's probably pending :-P
<JaneW> DONE
<jsgotangco> a lot of stuff is already in the wiki regarding this issue
<jsgotangco> it just needs cleaning up
<Burgundavia> Nafallo, I assume so, I hadn't heard to the contrary
<zyga> does anyone around have experience with RPC?
<Nafallo> Burgundavia: yepp, the wiki part I recalled from the spec *reading* ;-).
<jsgotangco> along with PackagingSystemDocumentation
<Nafallo> jsgotangco: seems to me that's integrated in IntroDevelDocs.
<jsgotangco> Nafallo, yes very
* Nafallo wonders why the PackagingSystemDocumentation spec isn't terminated ;-)
<jsgotangco> heh, it was explicitly indicated that it will be part of IntroDeveloperDocs
<thom> hula in main? RUN AWAY
<thom> good morning ;-)
<jsgotangco> hi thom 
<Nafallo> thom: morning :-). you should update BreezyGoals btw ;-)
<Treenaks> thom: yes, and it's going to be the default mta!
<Nafallo> Treenaks: lol'
<jsgotangco> gyah
<ogra> thom, i dont think they're serious
<Burgundavia> but it is on the wiki, it must be true!
<tseng> JaneW: pong. it was sleep time here
<Nafallo> tseng: morning tseng :-)
<tseng> hey dude.
<Unfrgiven> tseng: morning
<jsgotangco> there bug him :D
<zyga> hello thom
<tseng> JaneW: if you are looking for breezy goals status, we are working hard on Mono. intro developer docs will be next, I dont have time to do them in parallel but the doc wont take more than a week or two
<Unfrgiven> tseng: want some help writing it?
<tseng> sure I meant to do the first draft, but we filled out a pretty solid outline at udu
<tseng> you probably have a pretty good idea where im going with it
<Unfrgiven> tseng: yeah... if you want, i'll take what we did at udu and start fleshing it out.
<Unfrgiven> i can send you frequent updates...
<tseng> hm sure
<tseng> can you work with jsgotangco?
<jsgotangco> sure
<Unfrgiven> yeah sure... 
<tseng> rock on dudes!
<JaneW> tseng: hi, np, I just needed to give it a status, I have made it drafting, ok?
<tseng> JaneW: sure.
<jsgotangco> we better flesh out the notes made by whiprush
<Unfrgiven> tseng: and where will u come in? or are you handing it over to us?
<JaneW> cool, you guys respond really well to nagging!
<JaneW> this is gonna be fun! ;)
<tseng> JaneW: mono is being implemented now, it sounds like these guys want to do first draft for the doc
<tseng> JaneW: hey only when im awake!
<Unfrgiven> jsgotangco: where can we get his notes?
<JaneW> heh
<JaneW> hey, let tseng wake up!
<jsgotangco> Unfrgiven, http://udu.wiki.ubuntu.com/IntroDeveloperDocs
<Unfrgiven> jsgotangco: oh righht.... yeah ive seen those... i was there when he wrote it :)
<Unfrgiven> jsgotangco: i thought you meant something other than the spec.
<tseng> the notes are great.. i threw out all my ideas for the outline, people gave criticism, and whiprush wrote it all down
<jsgotangco> waa
<tseng> if something isnt clear ask obviously
<Unfrgiven> tseng: yeah for sure...
<whiprush> pretty sure that those are my notes
<whiprush> I got a few things in my tomboy notes that aren't in there
<Unfrgiven> whiprush: hey dude
<tseng> The documentation should also explain the correct way to build packages for stuff that aren't compilable (php, python, documentation, artwork etc) - MikkoVirkkil (mvirkkil)
<tseng> ^ hm?
<tseng> python we should do sure
<Unfrgiven> whiprush: oh. could you add those notes to the spec?
<whiprush> yep
<Unfrgiven> tseng: yeah the edubuntu guys seemed really keen for those
<whiprush> I'll do so in about an hour
<whiprush> heading off to work
<Unfrgiven> whiprush: yep cool, no probs
<tseng> Unfrgiven: yeah i got to work with them on it, they left with a reasonable understanding
<jsgotangco> hmm what happened to edubuntu anyways
<Unfrgiven> tseng: sveet.
<tseng> yeah elkner hasnt mailed me yes
<jsgotangco> i was very keen on that
<tseng> yet*
<tseng> he asked me to appear at a computing in education conf
<tseng> the plan is to demo edubuntu stuff
<Unfrgiven> tseng: when is it? has there been any work on edubuntu?
<jsgotangco> there's a good spec
<jsgotangco> though
<tseng> Unfrgiven: well maybe a little, but they have a solid base already
<jsgotangco> but it relies too much on ltsp work
<tseng> ltsp has been around for years
<jsgotangco> yeah
<tseng> they already ran it previous years at the booth
<tseng> so im sure they can handle setting it up on ubuntu :)
<Unfrgiven> is that all it was though? ubuntu + ltsp = edubuntu?
<tseng> well, yes and no
<tseng> it involves integrating it in and using casper instead of a full install
<tseng> but im sure they could build something more manual in the mean time
<tseng> netbooting casper will be awesome
<Treenaks> what was the dbus-newmail-notifier again?
<Treenaks> (the one that waits for evolution messages)
<ogra> Treenaks, there is already a frontend ?
* ogra was just about to port evonotify to use dbus...
<Treenaks> ogra: I think so
<torkel> Treenaks: check the evolution-patches mailing list
<tseng> seb128: oh that reminds me, id be happy if you could give your input on http://tseng2.ath.cx/~brandon/gst-plugins/
<tseng> seb128: i plan to make it build lame also
<seb128> k
<tseng> thanks!
<seb128> np
<thom> doko: did you upload a new firefox, or shall i do that shortly?
<mdke> ooh
<mdke> new one for hoary?
<thom> no?
<jsgotangco> thom, hey are you doing (or planning) to do a PDA spec? I can just fix the existing stuff and add more
<thom> not till wednesday
<thom> jsgotangco: go for it
<jsgotangco> ok
<seb128> elmo: libgtk2-perl sync from experimental
<mdke> thom, k sorry
<jsgotangco> mdke, you mean firefox 1.04?
<mdke> jsgotangco, i was thinking that possibly there was a security coming
<mdke> security update*
<ogra_d> jsgotangco, did you have a look at familiar linux for the PDA spec ?
<doko> thom: no, I didn't need it. firefox-dev already has the new C++ ABI
<thom> doko: um, you're aware that firefox didn't actually build, right?
<ogra_d> jsgotangco, they are debian based....
<seb128> elmo: libidl sync too please
<thom> doko: i really need to upload 1.0.4 to breezy, is that going to cause huge grief?
<doko> no, not at all. using which compiler?
<thom> 4
<doko> fine
<thom> righto
<mjg59> Kamion: Arse, I forgot to deal with IR setup
<Kamion> mjg59: in the HP CD?
<mjg59> Kamion: Yeah
<mjg59> Kamion: Needs setserial adding to desktop and for me to update the hp6xx0 package
<mjg59> Kamion: If I feed you an updated package later on, is it easy enough to regenerate the CD?
<Kamion> mjg59: yeah
<Kamion> mjg59: I've moved setserial into desktop in that seed branch
<mjg59> Kamion: Cool. I'll send the package soon.
<jsgotangco> bye bye
<Kamion> er ... well I would've done if chinstrap were reachable
<Kamion> ok, what's going on? it's reachable from my server but not from my laptop. grr.
<Kamion> ah, fixed
<seb128> daniels: around?
<Riddell> if I have a multi-processor machine how can I tell debuild to make use of that?
<jordi> Kamion: now that it's early you might want to explore the possibility of importing nano/experimental to breezy
<jordi> Kamion: I haven't seen any important bug report in debian bts or upstream mailing list
<jordi> and it has  the UTF-8 support stuff
<Kamion> jordi: don't see why not
<Kamion> elmo: please sync nano 1.3.7-0 from experimental
<Kamion> Riddell: wrong level - debuild just invokes dpkg-buildpackage which invokes debian/rules. Getting debian/rules to use make -j depends on the package.
<jordi> Kamion: easy :)
<carlos> jordi, hi old man :-)
<jordi> carlos: dude
<jordi> it's still 27
<jordi> it will get worse
<Burgundavia> is this statement correct? "Breezy is going to be completely compiled with GCC 4.0"
<mdke> i got a report of a pm spammer in #ubuntu
<mdke> "msg pvt: come and see my photos at ..." sort of thing
<ogra_d> Burgundavia, with exception of the kernel, yes
<mdke> any ops around?
<Burgundavia> ogra, ok, thanks
<Seveas> mdke, i've tried to msg all ops, no one answers...
<mdke> ok
<mdke> will try freenode staff
* ogra_d is supposed to be an op, but i'm obviously not on the access list yet
<Kamion> Burgundavia: various workarounds other than the kernel have been applied; I'd say something more like "with a few exceptions, ..."
<Burgundavia> Kamion, ok
<daniels> seb128: not really, no
<mdke> daniels, if you get 10 seconds would you ban Lidia21 from #ubuntu, it is a spam bot
<mdke> daniels, oh forget it sorry
<daniels> already done
<daniels> yeah, cheers
<mdke> sorry to bother ta
<mdke> ya
<daniels> no worries
<seb128> daniels: that's just about your panel issue.. do you have a drawer near of a corner?
<ogra_d> seb128, https://bugzilla.ubuntu.com/show_bug.cgi?id=8285 "...we just have to grab it" ??? HAHA
<seb128> ogra_d: "just" :p
<ogra_d> heh
<doko> seb128: could you have a look at 9982?
<seb128> doko: k
<lamont> daniels: ack
<fabbione> hey lamont 
<lamont> morning fabbione 
<ogra> hey fabbione 
* lamont heads to the breakfast table
<fabbione> hey ogra
<thom> apt really is getting intelligent:
<thom> The following packages will be REMOVED:
<thom>   xchat xchat-common
* thom applauds apt
<lu|sleep> heh
* lu|sleep hopes someone builds an xchat-gnome 0.4 package
<seb128> thom: hum, what's screwed?
<seb128> lu|sleep: is that usuable now?
<lu|sleep> seb128: getting there
<lu|sleep> I've actually been using 0.3 for a couple months
<lu|sleep> and am now using svn builds
<seb128> I should give it a try
<thom> seb128: not sure; i don't see why the pango upgrade should cause xchat to be pulled
<thom> seb128: ah; xchat is out of sync with xchat-common on amd64
<seb128> oh, k
<mjg59> Kamion: http://www.codon.org.uk/~mjg59/tmp/hp/
<Kamion> mjg59: ok, I'll put another build together with that
<Kamion> mjg59: (the Pre-Depends on grep and sed seem a bit gratuitous, seeing as how both of those are Essential)
<doko> Kamion: I see the new directfb upstream version is prepared for gcc-4, but, it will change the name of an udeb. is there anything to consider besides a normal build?
<Kamion> doko: that udeb isn't used by anything yet, so don't worry about it
<doko> Kamion: fine
<mjg59> Kamion: Ah - is essential stuff guaranteed to be usable by the time second stage stuff is installed?
<Kamion> mjg59: absolutely!
<Kamion> it's guaranteed to be usable by the time debootstrap has done its "required" stage
<mjg59> Ok, cool.
<Kamion> mjg59: rsync://cdimage.ubuntu.com/cdimage/custom/20050516/hoary-install-i386.iso
<Kamion> popularity-contest is asking a question in a breezy install
<Kamion> make it stop
<Amaranth> eek
<Kamion> thom: ^-- that was your merge
<Kamion> and there's an fdutils question too
<Kamion> (non-debconf)
<thom> Kamion: righto
<thom> thanks
<Kamion> thom: ah, it probably wasn't the fault of the merge
<Kamion> thom: we went from installing it within debootstrap (under the noninteractive frontend) to installing it in the second stage
<thom> oh, ok
<thom> hrm
<thom> i guess i'll just drop the priority of the question
<GheRivero> res
<fabbione> daniels: ping?
<doko> elmo: ping?
<fabbione> lamont: ?
<fabbione> jbailey: ping?
<doko> jbailey: ping?
<jbailey> fabbione, doko: 'sup?
<fabbione> jbailey: time to start working on the C++ transition?
<jbailey> Sounds luvly.
<doko> jbailey: the toolchain for hppa is fixed?
<fabbione> yeah we need elmo, lamont and daniels too
<fabbione> doko: afaik hppa is missing glibc
<jbailey> doko: No, I'm hacking on that in the background.  I was trying to figure out sparc stuff this morning, but it looks like the failures there may be actual package failures doing special things for sparc that they don't need to anymore.
<Kamion> fabbione: can I have another hour or so?
<Kamion> I want one more try at producing working CDs
<fabbione> Kamion: sure, don't worry. it will take more than that
<fabbione> Kamion: we need elmo and lamont at the mixer to make the disco going :)
<Kamion> thom: popcon> if it's just dropping the priority, I can do that
<thom> Kamion: 'k; i have to pop out for a couple hours now anyway
<Kamion> ok, doing, thanks
<fabbione> thom: do you know if elmo is at the DC?
<doko> fabbione: and daniels to flash the xlights :)
<thom> fabbione: he's not
<fabbione> doko: that too...
<fabbione> thom: ok thanks mucho
<Kamion> ok, popularity-contest uploaded; I should be able to produce CDs after the :33 cron.daily
<Kamion> hmm, ubuntu-desktop is uninstallable on amd64?
<fabbione> Kamion: take your time. this is not going to be a 2 minutes thing i am afraid
<doko> fabbione: great, we found Kamion to be guilty that we cannot start the transition ;-)
<Kamion> oh, bugger, and apt-setup is hosed
<mjg59> Argh damned rsync
<mjg59> Why doesn't it deal with running out of space non-destructively?
<Kamion> oops
<fabbione> doko: no shit.. i come back here on public holidays for the transition. the transition will start today or people will wake up tomorrow with a dead horse head in the bed
<mjg59> (More to the point, why does it not notice that it's going to run out of space beforehand?)
* mjg59 now has half a CD
<Kamion> mjg59: come round here, rsync off my copy? :)
<mjg59> I have to go and supervise now, so I might as well leave it downloading
<jbailey> doko: Is there a list for us to work from, or a wiki page with steps to follow?
<doko> http://www.ubuntulinux.org/wiki/BreezyToolchainTransition
<doko> https://www.ubuntulinux.org/wiki/CxxLibraryList
<jordi> seb128: is this merge of gnoem-mud something that was asked by users, or rutinary work?
<jordi> seb128: it's uploaded now
<Kamion> merges are generally routine
* lamont starts using the DCT timezone abreviation. (data center time)
<thom> lamont: please, please gzip build logs rather than bzip2ing them so they're viewable in a browser :-)
<ogra> or use a cgi to bunzip them if clicked
<fabbione> thom: fix your browser :)
<fabbione> thom: remember... ssh + bzless are the rock :)
<jbailey> lamont: You should send in a patch to drepper to at DCT
<jordi> Kamion: I wonder how this typo in build-deps wasn't spotted before
<jbailey> Yeah, the .bz build logs are really annoying. =(
<jbailey> lamont: s/at/add/
<lamont> thom: gziped files don't show up clean in my browser either.
<Kamion> jordi: no idea what's being talked about :)
<thom> lamont: that's fixable
<jbailey> lamont: Really?  they ought to - the http protocol has addons to support gzip compression, IIRC.
<jordi> Kamion: there was a typo in gnome-muds b-d's, plus it was build-depending on python-gtk2.3-dev, instald of python-gtk-dev.
<jordi> I guess this was bad for hoary already, but I got notified today
<lamont> http://people.ubuntu.com/~lamont/buildLogs/a/a52dec/0.7.4-1/a52dec_0.7.4-1_20040620-0954-i386-successful.gz
<lamont> thom: tell me how to make that behave any differently than .bz2, and I'll switch it.
<Kamion> ok, fixed apt-setup, I think
<lamont> for extra credit, make bz2 behave the same way
<lamont> thom: it wants to open it with Archive Manager
<bluefoxicy> someone recommend me a C API for storing configuration data in config files
<bluefoxicy> I can't figure out which manual to read
<Riddell> elmo: are you able to let knetworkconf into hoary-updates?
<mdke> rsmy god the wiki is slow right now
<Kamion> seb128: did you see that xchat failed to build?
<Kamion> checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
<seb128> Kamion: http://people.ubuntu.com/~lamont/buildLogs/x/xchat/2.4.3-0.1ubuntu1/
<Kamion> indeed
<seb128> Kamion: only on amd64, I blame the buildd
<Kamion> ok, unfortunately it hoses the amd64 CD
<seb128> jordi: I'll ask for a sync
<Kamion> lamont?
<seb128> jordi: sync are automatic when there is no ubuntu changes ... and atm there is ubuntu changes due to the python version :)
<jordi> seb128: I see. Thanks :)
<seb128> thank you
<seb128> elmo: libgtk2-perl (experimental) gnome-mud (incoming) libidl speex gnome-blog contact-lookup-applet gnomoradio ding gaim-encryption revelation at-spi gnome-mag gok goobox gnome-doc-utils monotone pythoncad syncs please
<jordi> you do syncs from inc too? wow
<seb128> why not? that's just grabbing a source package
<jordi> sure
<lamont> Kamion: ack
<lamont> Kamion: ah, xchat... hrm.
<seb128> kick a new build
<thom> lamont: also, what the hell is that most recent firefox amd64 build log about?
* trulux needs a pitti
<surak> xchat is nice, but... it seems a little redundant with gaim.
<seb128> not at all
<lamont> surak: no way.
<mdke> *laughs*
<lamont> gaim sucks for irc
<surak> indeed
<seb128> s/for irc//
<thom> s/for.*//
<mdke> i'd rather use firefox irc than gaim
* seb128 will package xchat-gnome soon
<mdke> seb128, yay!
<surak> just thinking on terms of disk space.
<surak> (for the live-cd)
<lamont> thom: it's about yellow being really really really annoyed
<thom> lamont: well, feed it sedatives, or give it lots of tea. or something
<Kamion> surak: it's only about 300K, no big deal
<Kamion> there are many better targets
<Kamion> :)
<Amaranth> if gaim sucks what else is there to use?
<Amaranth> for AIM, MSN, YIM, etc
<nohar> on ;)
<thom> Amaranth: i said it sucks, not that you shouldn't use it
<Amaranth> heh
<mdke> gaim is good for that, but sucks for irc
<luis_> s/good/decent/
<seb128> does any say there is a non-sucky IM for MSN etc ?
<surak> fedora people have been discussing for weeks about keeping lilo or not. Someone from redhat said about maintaing it... and they were reminded that lilo hasn't changed since 2002
<mdke> luis_, nods*
<seb128> gossip rules
<luis_> yeah
<Amaranth> too bad gossip is just jabber
* luis_ keeps praying for AIM support for gossip to fall from the sky
<seb128> they should use libgaim 
<luis_> seb128: I think there was talk of that and then hallski decided to kill it
<Amaranth> yeah, that'd be cool
* Amaranth kills hallski
<mdke> do you guys know if it is possible to sign GPG keys based on just a phone call?
<seb128> transports way?
<Kamion> surak: lilo's still needed for a number of things grub just doesn't support
<Kamion> surak: and lilo *has* changed since 2002 ...
<Kamion> Changes from version 22.6 to 22.6.1 (17-Nov-2004) John Coffman
<luis_> mdke: doesn't the protocol require checking ID?
<surak> Kamion: I know, but they dropped it indeed. That's why the discussion. And redhat's lilo hasn't changed...
<luis_> seb128: no, transports sort of suck
<mdke> luis_, thats what i want to know. Do you have a link for the policy?
<luis_> seb128: basically unuseful for anyone except the admin
<luis_> mdke: I don't, I don't even have a key
<Kamion> surak: ah. that's just RH being slack I think :)
<luis_> brb
<Kamion> there've been 16 upstream releases of lilo since 2002
<luis_> need more tea
<surak> Exactly :-)
<Kamion> mdke: only if you know the person well enough already that you could be convinced about who they are from a phone call (i.e. you know their voice and can talk about things you're both familiar with)
<mdke> Kamion, guess not then
<Amaranth> heh, that'd make things easier :)
<mdke> Kamion, so meeting in person is necessary basically
<mdke> ?
<Kamion> I've once signed a key based on a phone call, but it was somebody I already knew well and I was just re-signing a new key because he'd lost his old one
<Kamion> mdke: generally, yes
<mdke> Kamion, with some kind of ID?
<Kamion> mdke: yes
<mdke> right
<Amaranth> i can call anywhere in the world but i can't go there so i'm screwed
<mdke> hmm
<Kamion> mdke: otherwise I could just wander up and claim to be you
<mdke> Kamion, yeah i see
<mdke> then again, if I turn up and say, I'm mdke, please sign my key, you still wouldn't know if its the same person that is chatting now
<Amaranth> Hi, my name is Colin Watson and I need you to sign my key. ;)
<Amaranth> mdke: That's why you need a photo ID.
<mdke> gosh
<mdke> it gets even more complicated
<Amaranth> Although if you accept any kind of photo ID I could just make up something and make an ID for it with my picture and someone else's name.
<mdke> :/
<Amaranth> So basically you need something government issued and hard to fake.
<Kamion> mdke: if you're sensible you also check that the e-mail address on the key matches up
<Kamion> mdke: i.e. that the person behind that e-mail address owns the private half of the key you're signing
<mdke> Kamion, yeah
<Kamion> it's pretty easy to come up with several obvious schemes for doing that; there are a couple of more or less standard ones
<mdke> by emailing and saying, "how many times did i scratch my nose when we met in person just now?"
<Kamion> that, or by mailing the signed key to them encrypted under their key
* mdke nods
<Kamion> (and not uploading it to the keyservers) so that they can only get hold of the signature if they own the key
<mdke> yes i c
<thom> lamont: also, a completely clean breezy chroot just built firefox fine, but none of the buildds seem able to
* trulux updating stuff to latest Breezy archives and building the Breezy's SELinux-capable packages
<lamont> thom: ../../../../dist/private/nss/oiddata.h:46: error: array type has incomplete element type
<lamont> make[5] : *** [Linux2.6_ppc_glibc_PTH_OPT.OBJ/asymmkey.o]  Error 1
<lamont> could that be part of the issue?
<lamont> certdb.c: In function 'cert_GetCertType':
<lamont> certdb.c:662: warning: pointer targets in passing argument 1 of 'PR_AtomicSet' differ in signedness
<thom> lamont: probably, but i can't duplicate it
<thom> hrm, i wonder
<lamont> similar error on i386
<thom> yes
<seb128> Kamion, lamont: xchat/amd64 ok this time
<lamont> yeah
<trulux> doko: ping
<doko> trulux: no
<trulux> doko: do you know when pitti will become available?
<doko> it's bank holiday today
<trulux> doko: haha, here I have holidays too. anyways, it seems that I'm so screwed up that I still sit in front of my little box to help out my Ubuntu folks
<trulux> ;P
<trulux> done
<trulux> krsec finished
<trulux> just about to add the randomization stuff
<thom> omfg
<Amaranth> ?
<thom> firefox is fubar
<thom> in a really, really odd and irritating way
<zyga> thom: why?
<thom> because the build system for security/ isn't integrated into the rest of the build system in 1.0
<zyga> thom: was it any better before 1.0?
<thom> zyga: eh? it's always been broken, but the change in compiler really shows up the breakage hard
<zul> hey
<cartman> any news on Cxx Abi transition?
<Kamion> lamont: could you enable breezy d-i daily builds, please?
<Kamion> doko: the CDs are looking pretty good now; please don't consider yourself blocked on me any longer, if you were waiting on me
<doko> Kamion: thanks, it's not you I'm waiting for
<trulux> dilinger: ping
* thom sighs
<thom> some combination of MoM, debian and me dropped a part of the gcc-4.0 patch
<thom> suck
<dilinger> trulux: pong
<trulux> dilinger: could we talk for a whle?
<dilinger> trulux: a little busy atm; it would be better if you emailed me or something
<trulux> dilinger: OK
<trulux> dilinger: will do
<thom> lamont: also, the new firefox has hppa and ia64 love, so we may well get an installable -desktop finally
<lamont> thom: woot!
<lamont> Kamion: will do
<thom> and it's uploaded
* thom -> dinner
<AndyFitz> mpt: ping
<bluefoxicy> fabbione:  more on the zv5405us bug
<bluefoxicy> fabbione:  usb 1.1 doesn't work, usb 2.0 does
<fabbione> bluefoxicy: add the info to the bug please
<bluefoxicy> firefox just crashed.
<daniels> tseng: ping
* mode/#ubuntu-devel [-o daniels]  by daniels
<mpt> AndyFitz: pong
<fabbione> elmo: ping?
<fabbione> lamont: ?
<AndyFitz> mpt: pmed 
<fabbione> jdub: ping?
<jdub> fabbione: pong
<fabbione> jdub: some rhcluster stuff is going upstream right now :)
<fabbione> at least they pushed the patches
<fabbione> so that's good
<jdub> fabbione: that's great news :-)
<fabbione> yup
<fabbione> less work for me :)
<Lathiat> hehe
<hiweed> hey all
<hiweed> a question, please.
<hiweed> does Ubuntu manage pkgs pool via dak?
<hiweed> a tool named katie, akar dak.
<bob2> katie is part of dak
<hiweed> and, does ubuntu define the tubuntu-desktop TASK via dak?
<hiweed> I know it install the tubuntu-desktop Task after reboot.
<hiweed> but I dunno when and where the task was defined.
<bob2> ubuntu-desktop looks an awful lot like a package to me
<hiweed> no, it's a task.
<bob2> if you say so
<hiweed> in fact, it is. :-)
<bob2> even tho it's built from the ubuntu-meta source package?
<bob2> and appears in the pool?
<hiweed> ehhhh...
<hiweed> sorry I can not get it. Would you change a word?
<jdub> hiweed: it's both :-)
<hiweed> both?
<jdub> both a task and a package
<hiweed> oh?
<hiweed> well...
<hiweed> so, which one will be installed? the task or the meta-pkgs?
<jdub> both :)
<hiweed> Wow
<hiweed> cannt believe it~
<hiweed> are u sure?
<jdub> relatively sure, yes
<jdub> the only bit i'm not positive about is whether we still use the task in the installer
<jdub> but i'm fairly sure of that
<hiweed> ok thank you, jdub.
<Burgundavia> jdub, can I close 9373
<hiweed> I studied Ubuntu only 4.10, so...
<hiweed> jdub, is the task define by dak?
<jdub> Burgundavia: if you've fixed it, yes, if not, comment that it should be considered
<jdub> hiweed: believe so, for the moment
<hiweed> ok thanks.
<Burgundavia> jdub, ok, is odd
<pitti> Morning
<jsgotangco> pitti, hey
<hiweed> Is the Ubuntu LiveCD built automatically?
<fabbione> hi pitti
<fabbione> pitti: you got some crack
<fabbione> hiweed: yes
<hiweed> thank you, fabbione.
<hiweed> I can find the debian-cd package from archive.ubuntu.com before, but now I cannot find it.
<hiweed> and I also wanna get the Live-CD-auto-build-tool.
<Treenaks>  morning chmj 
<chmj> morning Treenaks 
<daniels> thom!!!
<koke> any dkpg mantainer here??
<seb128> why not asking your question?
<koke> seb128: it's not a question :D
<koke> http://amedias.org/~koke/patches/dpkg_support-for-ubuntu-naming-scheme.diff
<Treenaks> seb128: maybe he's monitoring/stalking dpkg developers, and that /is/ the question
<mjg59> Kamion: Ok, that CD image looks good to go
<seb128> koke: questions like "any .... here" are likely to be ignored
<koke> seb128: sorry, you're right
<seb128> np
<koke> I usually ingore them too
<seb128> what does the change do?
<thom> daniels: ?
<seb128> thom: they comment to say "dup of ...", there is no way to duplicate a bug with malone?
<koke> seb128: when you are packaging a new upstream version with -0ubuntu1 you have to specify -sa to debuild to upload the full source
<seb128> koke: right, I was just wondering why you use a fixed number, changelog not clear :)
<seb128> anyway you should bugzilla that on dpkg imho
<jdub> morning euros :-)
<seb128> hey jdub :)
<daniels> thom: so, um
<daniels> thom: hypothetically, if every time I pressed an arrow key in a large multi-line text box (BreezyGoals edit), Firefox crashed ... ideas?
<seb128> jdub: can you change the xscreensaver component on bugzilla to point to ogra?
<jdub> seb128: ok
<seb128> thanks
<seb128> daniels: about this panel hating you ... do you have a drawer near of a screen corner?
<daniels> seb128: what's a drawer? :)
<daniels> seb128: my panel is totally stock
<seb128> a box which contains icons
<seb128> ie: you click on it, it opens a line with the icons you have stored here
<seb128> anyway that's not a part of the stock panel, so that's not that
<seb128> can you do what upstream asked on the bug? :)
<thom> daniels: bug filed, no idea why
<JaneW> who is in charge of GnomePanelEnhancements?
<JaneW> mjg59: can I put you as as econd on WirelessNetworkManagement?
<seb128> JaneW: me?
<thom> JaneW: put me, since it's just a side effect of NetworkMagic
<jdub> JaneW: put seb128, i'll second or interested
<seb128> JaneW: oh, no, this one. No BOF about that... is that actually anything?
<JaneW>  are we talking about Gnome now?
<jdub> seb128: i'll write it up - it's about making the panel sexy :)
<seb128> GnomePanelEnhancements
<thom> JaneW: WirelessNetworkMagic probably shouldn't really exist as a seperate goal, tbh
<seb128> jdub: stop giving me extra work dude :p
<JaneW> yes, there's not much there
<jdub> JaneW: i spoke to mark about it in more detail
<thom> uh, WirelessNetworkManagement
<seb128> jdub: but alright, if we can make it sexier :)
<jdub> seb128: it's, uh, bounty material... :)
<JaneW> ok, so can I merge WirelessNetworkManagement with NetworkMagic?
<thom> yes
<JaneW> ok done
<seb128> jdub: k
<ajmitch> evening all
<daniels> thom: cheers.  i'm on 0ubuntu5 fwiw.
<thom> daniels: nod. 1.0.4-1ubuntu2 doesn't appear to be any better  :/
<JaneW> ok so who's on Gnome?
<fabbione> did anybody bother to fix hal FTBFS?
<jdub> JaneW: in general, seb
<JaneW> seb and jdub then?
<jdub> JaneW: for this one, yeah
<daniels> thom: bong
<jdub> ogra_d: ping
<jdub> i wonder what _d means
<JaneW> dead?
<jdub> *uncomfortable silence*
<JaneW> heh
<Treenaks> daemon mode?
<JaneW> dormant
<JaneW> docile
<JaneW> decaying
<Treenaks> ogra? docile? :)
<jsgotangco> ah JaneW just the person i want to see today
<JaneW> douching
<fabbione> ducking
<JaneW> hi jsgotangco ;)
<jdub> *uncomfortable silence*
<JaneW> hehe
<jdub> JaneW: *cough*
<jsgotangco> douching yes!
* JaneW stops lest jdub gets offended (further)
<jdub> this is a family channel ;)
* Burgundavia is now glad he was not at UDU, as assignments seem to be more plentiful than wanted
<JaneW> Burgundavia: indeed, wnat some!?
<daniels> Burgundavia volunteers for XorgAutoconfiguration
<JaneW> doko: ping
<JaneW> cool ;)
<Burgundavia> JaneW, I don't program
<JaneW> but do you code...? ;)
<Burgundavia> nope
<JaneW> or hack?
<JaneW> :P
<Burgundavia> nope
<Burgundavia> produce hot air, docs and more hot air
<doko> JaneW: pong
<jsgotangco> JaneW, PDASupport draft spec Done, needs editing/review
<seb128> Burgundavia: merge bugs are closed when we have actually merged the Debian changes (ie: we have <debian-version>ubuntu<n>), not when we have the same app version
<JaneW> doko: hi, could you update the status of your Breezy Goals please?
<thom> jsgotangco: you rule, dude
<JaneW> http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<doko> JaneW: which ones?
<Burgundavia> seb128, ok, I just wondered, as I couldn't see anything in the buildlogs, but the version numbers were the same
<JaneW> jsgotangco: COOL, is cc still available for that?
<ajmitch> hey jsgotangco
<JaneW> doko: go look at page, the ones with your name as lead. Thanks.
* jsgotangco not sure he didnt put anything in queue
<jsgotangco> anything/anyone
<jsgotangco> ajmitch, hey
<seb128> Burgundavia: the version number is not the same, -1ubuntu against 1.1
* Burgundavia is affirmed in his role as a non-coder/hacker/etc.
* JaneW gets coffeee
<jsgotangco> its not so hard once you get your bearings
<JaneW> seb128: so now that you own GnomePanel... what's the status... ?
* JaneW wonders where mvo is these days?
<seb128> JaneW: <jdub> seb128: i'll write it up     <jdub> seb128: it's, uh, bounty material... :)
<jdub> ha ha
<cc> JaneW: available for what? poke me, and i'll take a gander
<seb128> JaneW: yesterday was not working days for him, dunno for today
<seb128> jdub: :-P
<daniels> jsgotangco: nice work with PDASupport :)
<jsgotangco> :D
<jsgotangco> took me an hour heh
* jsgotangco wonders why he wasn't that good during UDU
* JaneW pokes cc
<JaneW> cc: jsgotangco: JaneW, PDASupport draft spec Done, needs editing/review
<cc> JaneW: ok, will take a gander
<JaneW> jsgotangco: lack of sleep maybe?
<JaneW> seb128: thanks I updated accordingly.
<seb128> np
<jordi> hey JaneW 
<jordi> seb128: do you have experience moving CVS branches?
<seb128> jordi: sure, ignore other people :p
<JaneW> hey jordi: you better?
<seb128> jordi: moving branches? what do you mean?
<jordi> seb128: I want a branch to become HEAD, HEAD to become another branch
<JaneW> seb128: jealous? ;)
<seb128> JaneW: not really :p
<jordi> JaneW: I still have the last bits of the cold, but fever and all of that is thankfully gone :)
<jordi> JaneW: he is
<JaneW> jordi: good..
<JaneW> about being better I mean!
<jordi> lol
<seb128> jordi: not sure on how to make a branch become HEAD
<jordi> I'll find out, Hallski should know. He does this every 3 days with gossip
<daniels> merge it to HEAD?
<seb128> what I was thinking
<JaneW> thom: would netwprk magic affect the kernel? (I am thinking not..)
<JaneW> s/netwprk/network
<thom> JaneW: no
<JaneW> cool thanks
<jordi> JaneW: hey I'm catched up with you again last Sunday: I'm 27 now :P
<jordi> s/I'm/I/
<thom> seb128: yes, it seems that way (no way to do dups in malone; luis has already filed a bug for it)
<daniels> it would be ironic if luis's bug was a duplicate of something else, but they couldn't mark it as such
<seb128> thom: :(
<seb128> daniels: you have opened a couple of dups too :)
<JaneW> jordi: cool congrats... not quite caught up though ;)
<jdub> daniels: that's almost filing two bugs for anyway :-)
<daniels> seb128: bah
<jordi> JaneW: I'll get there sometime :)
<daniels> only one, AFAICT
<daniels> and I blame the search for not letting me find it easily
<seb128> yeah, at least the malone search works *g*
<JaneW> jdub: you happy to be 2nd on FontHandling?
<jdub> JaneW: best to choose someone else, methinks
<seb128> oh, jdub doing fonts stuff? :)
<JaneW> jdub: ok, any suggestions?
<seb128> I've some font issues for you dude :p
<jdub> JaneW: seb128 of course!
<jdub> ;-)
<seb128> no way
<JaneW> jdub: for the record it was doko who nominated you
<seb128> daniels for fonts?
<JaneW> hehe
<JaneW> seb it is
<jdub> no, i think daniels, thom, ... ?
<JaneW> *duck*
<jdub> possibly ogra
<thom> jdub: piss off. :-)
<JaneW> we need a lead and 2nd
<doko> JaneW: FontHandling:  People: BenjaminMakoHillLead, JeffWaughSecond, why daniels?
<JaneW> I thought this was a family # ;)
<jdub> doko: mako and i wrote the spec only :)
<JaneW> doko: yeah lead and 2nd on spec aren't always who are lead and 2nd for implementation
* seb128_ kicks the dsl IP changes
<seb128_> <JaneW> seb it is
<doko> jdub: I committed for the OOo side, you wanted at least to ask somebody / make it a bounty, IIRC
<seb128_> <seb128> no no no
<seb128_> <seb128> fonts hate me
<seb128_> <seb128> I've switched to aterm because I can't get a correct g-t with the new fontconfig
<seb128_> --- Disconnected ().
<seb128_> 
<seb128_> why not trying with daniels? :)
<jordi> seb128: heh, aterm eh?
<daniels> um, please not me for fonts
<jordi> seb128: does aterm do utf-8 these days?
<seb128_> not the Debian version
<jdub> seb128_: what's wrong with it?
<daniels> not being funny or anything, but I really don't know that much about fonts
* JaneW waits for volunteers for FontHandling
<seb128_> but there is a malone bug I've read this morning saying aterm 1.0 does and is around since january
<seb128_> but not packaged
* ajmitch backs away quickly from fonts
<JaneW> does anyone know /like fonts?
<JaneW> even a little?
<seb128_> jdub: before: http://people.ubuntu.com/~seb128/font1.png
<seb128_> jdub: now: http://people.ubuntu.com/~seb128/font2.png
<jordi> seb128: you mean aterm in Debian does not do utf-8 while it can?
<jordi> doh, I'm killing goran
* JaneW will bbl, conducting an interview now...
<seb128_> jdub: that's supposed to be a fixed 10x20
<seb128_> jordi: yep
<jordi> seb128_: those fons rock :D
<seb128_> jordi: I like the font1 :)
<jdub> seb128_: weird
<thom> seb128_: and it's made it be in the wrong language too!
<jordi> thom: people like the climbing pics
<seb128_> jordi: there is a aterm 1.0 since january according to the website 
<jordi> I should post them in planet
<thom> jordi: so it seems
<jordi> seb128_: pfft
<daniels> ok, so font handling seems to mainly be about font selection UI, and actual fonts themselves (as opposed to font-handling libraries, e.g. fontconfig, pango, xft, freetype)
<JaneW> daniels: that mean you want it? huh huh?
<jdub> daniels: i think a chunk of it will be fontconfig configuration changes
<daniels> JaneW: so, I know a little bit about fontconfig/pango/xft/freetype, but absolutely shit-all about fonts themselves, and even less about UI design
<jdub> daniels: doko mentioned that he's done something on the OOo side
<daniels> doko: ?
<Burgundavia> daniels, I can help you with UI stuff, but I know shit about programming
<doko> done? no. OOo does have it's own selection mechanism, on top of fontconfig.
<jdthood> mdz: I have a question about http://udu.wiki.ubuntu.com/AudioInfrastructure
<jdub> jdthood: mdz is away atm
<JaneW> ok so daniels and Burgundavia it is...?
<JaneW> you can call on help if/when you need it...
<JaneW> as you can see everyone LOVES fonts
<jdub> it will mostly involve fontconfig config changes
<jdub> possibly some OOo and GTK+ hacking
<jdub> and maybe some standards definition with upstream
* JaneW taps fingers
<jsgotangco> would you like a manicure on those fingers
<daniels> seriously, I'm out of my depth on FontHandling
<jordi> bunch of slackers :P
<seb128_> jordi wants to do fonts, see
<jordi> having said that, it's time for break/cafeteria.
<ajmitch> jordi: slacker :P
<doko> jordi: great!
* Burgundavia now observes why fonts look like crap on linux
<seb128_> they do?
<JaneW> jsgotangco: absolutely, you offering?
<jsgotangco> no way
<JaneW> jordi!
<JaneW> ok it;s yours
<ajmitch> lucky jordi :)
* jsgotangco doesnt know anything about looking good either
* JaneW ammends with jordi's name
<Burgundavia> jsgotangco, your a guy
<JaneW> jsgotangco :P
* ajmitch was almost tempted to step forward for fonts for a minute there
<JaneW> ajmitch, it;s not too late... we need a second
<mpt> Did someone mention UI design?
<jdub> mpt: daniels was grasping for straws
* ajmitch doesn't want to take on what he can't guarantee time for at the moment
<JaneW> mpt: you want your name there too?
<mpt> my name where?
* mpt finishes reading scrollback
<Burgundavia> mpt, UI for the font stuff
<mpt> okie dokie
<jdub> none of it requires ui design
<mpt> What am I good for then? nothing
<jdub> making launchpad rock
<mpt> Fontilus looks like it'd be very cool with a couple of tweaks
<jdub> and some exposure
<jdub> there's something for you to muse upon
<jdub> the only way of clicking into fonts:/// atm is the button in the details section of the font preferences dialogue
<jdub> ie. it's very well hidden
<jdub> it would suck to have two fonts related icons in the desktop preferences menu though
<jdub> so if you can figure out a good way to expose fonts:/// that'd be cool
<mpt> oh, I hadn't noticed that button
<jdub> it may just involve a nicer button from the first font prefs page
<mpt> That's easy
<mpt> Just make Fonts a real, single folder somewhere obvious
<jdub> (i believe that dialogue is going to be tabbed in future)
<mpt> At least the *design* is easy :-) ... I imagine implementing that would be hell
<jdub> "somewhere obvious" and "real" are the problems there
<jdub> fonts:/// is currently a list of the fonts fontconfig knows about, between system fonts and user fonts (in ~/.fonts)
<mpt> fonts:////////////
<mpt> What is it with Nautilus and slashes
<JaneW> mpt: careful just soeaking can be construed as voluneteering, if I am desperate ;)
<jdub> mpt: that's actually the correct definition of a hostless schema
<jdub> fonts://<host>/<path>
<mpt> e.g. fonts://localhost/Vera%20Sans ?
<jdub> that's what fonts:/// means, yeah
<jdub> fabbione: has anyone mentioned problems with tg3 in the current ubuntu 2.6.12?
* mpt dreams about Fonts/ being just another search folder
<jdub> fabbione: also, i'm starting to have regular ipw2200 resets, which i didn't have before
<fabbione> jdub: i use tg3 here and it works fine
<jdub> hmm
<fabbione> ipw2200 is a known upstream problem
<jdub> can't seem to get link lights on my notebook
<jdub> hrm
<jdub> might be a docking station buglet
<fabbione> probably
<jdub> fabbione: hrm, okay - so with 2.6.10 i can use my docking station ethernet port, with 2.6.12 i can't
* jdub throws things around a bit before considering the most useful way to deal with this issue
<fabbione> jdub: is it a passtrough? or the docking station has its own hw?
<fabbione> because we are traking tg3 from upstream... there is nothing fancy about it
<jdub> fabbione: docking station has its own port, but it's the same nic running it
<fabbione> jdub: try to unload/reload the module once you are docked?
<jdub> i have some power management problems with the docking station too
<jdub> fabbione: yeah, have done
<jdub> fabbione: did not work (with 2.6.12)
<fabbione> same if you boot directly docked?
<jdub> hrm, can't be sure i adequately tested that
<jdub> will reboot again
<fabbione> jdub: the driver has major updates...
<fabbione> between .10 and .12
<jdub> aha :)
<jdub> i'm in a terrible position for LaptopMission though - dell just stopped shipping this model ;-)
<Treenaks> fabbione: also between 8.1 and .10 (warty vs hoary)?
<jdub> hrm
<jdub> fabbione: ok, now it worked
* jdub tries a few other things
<fabbione> Treenaks: mostlikely yes
<Treenaks> fabbione: cool, that might fix my "8 megabit tcp connections stall out after some time" problems
* Treenaks pokes Dell
<fabbione> Treenaks: i am not sure i want to know about it :)
<Treenaks> fabbione: I'll file a bug if it isn't fixed in hoary -- I'm going to upgrade that server sometime this or next week
<fabbione> Treenaks: i am more interested to know if it doesn't work in breezy
<fabbione> in hoary there is nothing i can do
<Kamion> mjg59: ok, great, thanks
<jdub> morning Kamion 
<Kamion> morning
<fabbione> hey Kamion 
<fabbione> Kamion: any news for partman-auto-lvm?
<Treenaks> fabbione: I'm not going to upgrade production servers to breezy, tyvm
<fabbione> Treenaks: no need to. just test the kernel :)
<pitti> Hi again
<fabbione> hey pitti
<seb128> hi pitti 
<seb128> pitti: how do you feel?
<pitti> Hey seb128
<pitti> seb128: my stomach and me have different opinions :-/
<seb128> :(
<pitti> stomach lining  inflammation
<Treenaks> pitti: ouch
<Riddell> Kamion, thom: the torrents still don't seem to be working
<sladen> jdub: get a thinkpad!
<tseng> daniels: pong
<daniels> tseng: how's mono-in-main going?
<tseng> daniels: its up to pitti now
<daniels> pitti: ping :)
<pitti> oh right, I'm going to review it today
<pitti> daniels: lemme finish my security mail, then I take a look at mono
<ogra> pitti, btw, these packages will still need some love so dont judge them to hard :)
<pitti> daniels: (I mean, evertything other than "it's fine for me" is out of discussion anyway, isn't it? :-) )
<ogra> yeah
<pitti> neverthless, I also look for obvious packaging bugs
* ogra sighs
<tseng> lintian has silly stuff still ogra, but i dont think there are a bunch of "bugs"
<ogra> lets see :)
<seb128> do you guys merge with debian packages for blam/muine/... ?
<seb128> there is some bugzilla bugs open about the merges, who should get them?
<tseng> me
<ogra> seb128, tseng 
<tseng> we are ahead of debian for both
<tseng> but I will be sure to check them out
<seb128> same for GNOME, but doesn't prevent to merge and put the changes on top of the merge
<Kamion> fabbione: that would be an elmo question
<Kamion> fabbione: er ... except no it wouldn't, sorry
<Kamion> fabbione: I'll upload it today
<fabbione> Kamion: is it sitting in NEW i guess....
<fabbione> ah ok :)
<fabbione> thanks
<Kamion> fabbione: no, I'm just talking bollocks :)
<Kamion> Riddell: no idea about that, sorry
* fabbione hands some more caffeine to Kamion 
<Kamion> two cups of coffee already, probably not enough
<fabbione> ehhe
<daniels> pitti: heh
<fabbione> daniels, pitti: who did the last hal upload?
<pitti> fabbione: me
<fabbione> (0.5.2)
<fabbione> pitti: it's FTBFS
<fabbione> in all arches
<pitti> meh?
* pitti looks
<Burgundavia> mpt, ping
<mpt> pong
<Burgundavia> mpt, speaking of fonts, have you seen the thread on usablity about fonts?
<mpt> yes
<pitti> gosh, compressed build logs are so evil...
<Burgundavia> ok, just checking, you usually comment on these things, but I noticed you hadn't
* seb128 hates these .bz2 build logs
<mpt> Burgundavia: What's the use
<Burgundavia> mpt, ok
<Burgundavia> mpt, the latest post seemed to be quite promising
<fabbione> jdub: new inotify is in my kernel branch :)
<fabbione> hmm it would be nice if we could get automatic notification of FTBFS
<mpt> Burgundavia: It needs some rich philanthropist to come along and say "the filesystem hierarchy is full of crap", and pay bounties to fix it, so that (as one of the side-effects) Fonts is in a single folder people can find in Nautilus
<Treenaks> mpt: yeah, let's break unixyness!
<Burgundavia> mpt, we have one of those, in a cage somewhere, we just need to prod him in the right way
<mpt> Treenaks: I'm tired of being a eunuch
<Treenaks> mpt: usability is nice, but please think about reality too
<Burgundavia> you can do it so that it is transparent to the user and it doesn't break unix stuff
<Burgundavia> Treenaks, that is what MS says. We have to do better
<mpt> Treenaks: Thankyou for being exhibit A
<daniels> seb128: you too, hey?
<Treenaks> mpt: np
<seb128> daniels: yeah!
<Burgundavia> mpt, fonts are a major blocker issue for artists. How can we make our pet billionaire know that?
<mpt> Burgundavia: The good news is that about two years after Longhorn eventually ships with Search Folders that work roughly the way they do in OS X, someone on lkml will say "Oh yeah, maybe we should get around to doing that", and then two years after that it'll be ready, and then about two years after that someone will say "hey, we could use that for fonts", and about five years after *that* apps might mostly be looking in a single Fonts fold
<daniels> hate to break it to you all, but 'let's get rid of the hierachy' doesn't solve any problems
<ogra> mpt, http://beaglewiki.org/Main_Page
* daniels notes that OS X still has a very definite hierachy.
<ogra> mpt, we were first
* JaneW is back
<Treenaks> ogra: now all it needs is a "Fonts" plugin and a way to find only fonts, AND a way for apps to use it
<Burgundavia> we just need to hide the hierachy from the user
<mpt> "The most recent version of Beagle is 0.0.9"
<JaneW> so what was the final result on FontHandling? jordi & ajmitch?
<ogra> mpt, beagle was announced and showed before apple had stolen its original name (dashboard)
<daniels> if only we had a generally unified font-handling library
<jsgotangco> yeah
<daniels> mpt: beagle works today
<jordi> JaneW: err, seb128 and gtk+
<ogra> mpt, breezy will ship it :)
<mpt> it's all about the ship date
<Treenaks> why does the dog in the logo look so angry? (or am I just not a dog expert?)
<Burgundavia> Treenaks, it doesn't look angry to me
<mpt> It's angry that it's a stand-in for another name? :-)
<mpt> yeah, the eye needs rotating 180 degrees
<ogra> yeah, itz wants its name back :)
<jsgotangco> dashboard?
<ogra> yep
<jsgotangco> hehe
* jsgotangco prefers beagle
* seb128 kicks jordi 
<jsgotangco> yeah apple's dashboard was a total rip
<ogra> jsgotangco, i prefer that big companys dont steal names from OSS ;)
<Treenaks> ogra: register them as trademarks :)
<Treenaks> ogra: slap them with lawsuits
<ogra> bah
<Burgundavia> dashboard is a very very common name
<JaneW> grrr
<ogra> why cant the world "just work" ?
* ogra sighs
<jsgotangco> although apple's dashboard is actually some software they bought
<mpt> ogra: You talking about trademarks, or computers?
<ogra> mpt, humans
<jsgotangco> they look morelike gdesklets
<mpt> ogra: Because there's humans in it.
<Treenaks> in computers? so THAT's why it's unreliable ;)
<ogra> lol
<JaneW> lol
<mpt> Ubuntu is made of people! PEOPLE!
<JaneW> yes little shunken humands
<Treenaks> mpt: So is Soylent Green. Your point? :)
<JaneW> who flick switches
<mpt> Treenaks: Yes, thankyou for picking up on the reference
<JaneW> but they get tired sometimes and make mistakes
* jordi goes see what's FontHandling is actually about.
<jordi> woah, I'm actually listed as lead
<pitti> ogra, tseng: it is right that only a single patch in debian/patches is actually applied?
<tseng> pitti: yes
<tseng> pitti: upstream says we can drop it also.
<tseng> so it will be gone soon.
<jsgotangco> im going home
<tseng> bye jerome
<jsgotangco> bye bye
<jordi> JaneW: now seriously, I guess I can help with finding useful fonts for i18n and so on, but other bits I'm probably clueless
<jordi> JaneW: also, I dunno how much time I can devote to this, and when
<pitti> ogra, tseng: there are lots of dummy manpages in debian/man, will they become real eventually (from upstream)
<pitti> ?
<tseng> pitti: ogra is making patches for manpage suckiness
<ogra> i think they wait for my patch (not sure )
<tseng> i can help fill i missing ones
<ogra> ah, ok
<tseng> we need to push back really hard on upstream about docs / build systems over the next few months
<pitti> ogra, tseng: mono.deb should be arch all
<tseng> hm you sure?
<ogra> hmm, amd64 has special compile options
<pitti> tseng: it only contains a single symlink
<pitti> tseng: ./usr/share/doc/mono -> mono-common
<pitti> tseng: or does it have arch-specific dependencies?
<tseng> are you talking about the meta package?
<pitti> mono_1.1.7-0ubuntu4_powerpc.deb
<tseng> yes that is a meta package on the other parts
<tseng> some are arch dependent
<pitti> tseng: yes, but mono_1.1.7-0ubuntu4_powerpc.deb should be arch:all
<tseng> ok.
<tseng> it will be in my next upload
<pitti> tseng: same for mono-devel
<ogra> tseng, btw, shouldnt we sk for main upload rights for you ?
<ogra> ask even
<tseng> ogra: we should but mdz is not here?
<ogra> today is TB meeting
<tseng> yes
<tseng> do I have to be there?
<tseng> I can try
<Kamion> if you can
<ogra> put you on the agenda.... and letsa see
<ogra> --a
<pitti> tseng: OTOH mono-devel is so utterly empty that this package should probably disappear entirely
<Kamion> bugger, I have to rebuild before releasing colony-1
<daniels> Kamion: you're releasing colony-1 now?
<ogra> heh
<Kamion> accidentally built it against the hoary-hp-laptop debian-cd branch ... no wonder it didn't reboot properly on amd64
<Kamion> daniels: yes
* ogra cant get used to this new name scheme
<daniels> oh, cool
<tseng> pitti: it was added for users, they have a really hard time keeping straight what packages you need
<daniels> so breaking the archive isn't too incredibly fatal
<tseng> pitti: and complained loudly
<Kamion> if the CDs I'm building now don't work, I'll just errata the problems from the last build
<pitti> tseng: so it's a metapackage again?
<tseng> yes.
<pitti> tseng: so at least it should be arch all then
<tseng> done
<pitti> tseng: but what about the mono package then?
<pitti> it's a metapackage too
<Kamion> daniels: right, I'm amazed I got this long to do it :-)
<tseng> they both are
<tseng> one is runtime, one is extra devel bits
<pitti> tseng: m-assemblies-arch is empty as well
<tseng> ill have to check with meebey on that
<pitti> tseng, ogra: okay, if the manpages and empty/arch all packages are dealt with, the packaging is okay for me
<tseng> <meebey> there was and there may will be in the future
<tseng> <meebey> winelib it was I think
<tseng> but I can remove it locally for the time being, if its against policy
<pitti> tseng: no, it's not against policy, but it clutters up the archive somewhat
<tseng> pitti: yay! thanks
<pitti> tseng: but it's not a biggie
<mkde> hi all
<mkde> pitti, is a security update for firefox in the offing do you know?
<pitti> tseng, ogra: only one CAN so far (CAN-2005-0509), is that fixed?
<pitti> mkde: yes, as soon as the 1.0.4 patches are published (tomorrow)
<mkde> pitti, for hoary?
<tseng> pitti: appplies to 1.0.5
<pitti> mkde: yes
<mkde> pitti, supercool
<ogra> pitti, we use 1.1.7
<mkde> thanks
<pitti> tseng: okay, fixed upstream then I guess
<tseng> pitti: but i should put that on my list for hoary
<pitti> okay, great
* pitti -> lunch
<tseng> thanks pitti
<tseng> see you soon, time for work
<ogra> yeah, thanks pitti 
<thom> Keybuk: ahah!
<Keybuk> hmm?
<thom> Keybuk: did you have udevd/hotplug-ng packaged?
<Keybuk> no, but Md has doesn't he?
<thom> dunno, was just about to ask him when you showed up ;P
<mvirkkil> is dotUbuntu going to be some sort of central registeration/online identity creation system for Ubuntu users?
<mvirkkil> Never mind. Found the spec.
<thom> mvirkkil: don't bet on it staying as dotUbuntu; that name's just a place holder
<mvirkkil> thom: Yeah. I was just interested in what it was, since I've been playing around with something similar.
<thom> mvirkkil: nod
<mvirkkil> thom: Adding "online-identity" in to about-me
<thom> mvirkkil: oh really? awesome
<mvirkkil> thom: Which would be a 'canonical' registration point, for a jabber id/voip/bugzilla/malone/forum.
<mvirkkil> thom: Oh, that should read, playing around with a similar _idea_
<mvirkkil> thom: No coe.
<mvirkkil> thom: No code.
<thom> mvirkkil: awww, you had me hopefull then ;-)
<mvirkkil> thom: I'm rather exited about bringing jabber in to the communication mix. 
<thom> mvirkkil: definitely
<mvirkkil> thom: Since it's an IM (which people love) and a file transfer system (which people love). It's easy to build bots (which I like), and you can use it for irc (which is less scary, and where devs are at).
<mvirkkil> mvirkkil: I've built a bugme-bot, which will ask questions to write a bugreport for you and submit it.
<mvirkkil> thom: --^
<mvirkkil> thom: Thogh unfortunately, it's for our internal bugreport system, which is a custom job.
<mvirkkil> thom: But it was a fun hack :-)
<thom> mvirkkil: cute!
<mvirkkil> thom: Writing bots with xmpppy is trivial and fun :P
<daniels> win 31
<daniels> er
<mvirkkil> Are the python bindings for capplets in ubuntu?
<pitti> ogra: hmm, apt-get install beagle, "$ best" -> "/usr/bin/best: line 24: exec: mono: not found"
<pitti> ogra: that sounds like a missing mono dependency
<pitti> ogra: (same for f-spot)
<jordi> is anyone familiar with Ubuntu on the PowerPC?
<koke> jordi: depends on what do you mean by "familiar" :)
<jordi> I'm surprised, I'm trying to boot a Dual G5 with Debian, failed with d-i rc3. Now I downloaded the Ubuntu hoary livecd, and it fails as well...
<jordi> it's probably http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287030
<jordi> it's a kernel bug, apparently, and I assumed hoary would solve it
<fabbione> jordi: we need ppc64 kernels
<jordi> fabbione: what's the workaround?
<fabbione> jordi: none.. we need ppc64 kernels
<jordi> I assume the power3 or power4 kernels don't help at all
<jordi> fabbione: great
<Kamion> jordi: you're not booting with power4?
<Kamion> jordi: G5 systems will not work with the powerpc kernel, in either Debian or Ubuntu, at all
<jordi> Kamion: so power4 should work?
<fabbione> jordi: didn't you try all kernels?
<jordi> Kamion: people had been telling me g5 should work with the ppc kernel
<Kamion> jordi: they were wrong
<jordi> I think so
<jordi> I'll try again
<Kamion> jordi: powerpc stands no chance of working; power4 may work
<jordi> nod
<pitti> Hi trulux 
<trulux> hey pitti 
<trulux> pitti: I have some sweet for you today... finished the framework for our kernels
<trulux> pretty simplistic, cabale of being enabled/disabled at both boot time and runtime
<pitti> neat
<trulux> among the enable/disable sysctl interface for each feature
<trulux> also I've been porting Manoj's patch for dpkg (selinux support) to our Ubuntu'ized dpkg
<pitti> for breezy?
<trulux> among taking a look over the packages and rebuilding
<trulux> yep
<trulux> pitti: could you do some testing? I lack of infrastructure and time
<pitti> trulux: I apt-get dist-upgraded, but no dpkg from your site
<trulux> pitti: also, could you review the spec. I'm going to send you?
<pitti> trulux: I can build a kernel with your patches soon (or maybe somebody from the kernel team wants to...)
<pitti> sure
<trulux> pitti: I said here that pearls.tuxedo-es.org is a mirror, and the machine whicb rsync's it is *out of business*
<trulux> hard disk error
<pitti> uh, I didn't read that
<trulux> fscked up hard, lost MySQL DB backup
<pitti> darn
<trulux> only patches and the other stuff remains there but there are no db backups
<trulux> that is, my SELinux on Ubuntu HOWTO is lost
<trulux> and all the rest of doc
<trulux> of the wiki
<pitti> trulux: it's not in the Ubuntu wiki somewhere?
<trulux> (including the Hardened Gentoo wiki I was moving for proposal)
<trulux> pitti: nope, I wrote it on my own wiki due to wikimedia formatting and also 'cos it has wikitex
<trulux> I can add gnuplot, etc to it, so, it's mor handy
<trulux> pitti: I will send you an email right now (with the patch for dpkg and the one for the kernel)
<trulux> pitti: PID randomization also to be included
<trulux> but testing now is a good idea
<pitti> yeah, I agree
<trulux> one sec
<pitti> trulux: I can test the dpkg stuff a bit, but Keybuk should review it
<trulux> OK, no worries
<Keybuk> which patch is it?
<trulux> it's just that I've got the devel box back again with a 19" TFT
<Keybuk> Russell Coker's or Manoj's?
<pitti> trulux: I would appreciate if Keybuk could review and upload the patch
<trulux> Keybuk: none of them
<trulux> Keybuk: based on Manoj's
<Keybuk> "based on" ?  what's wrong with Manoj's?
<trulux> Keybuk: dcc there?
* trulux has no rsync or pearls wisdom right now
<trulux> Keybuk: won't apply to Breezy's dpkg
<Keybuk> oh, right, it's based on 1.13
<trulux> ;)
<lamont> morning fabbione 
<Keybuk> we've talked vaguely about putting 1.13 in breezy anyway
<trulux> lemme dig in my Breezy chroot....
<Kamion> aren't we getting 1.13 in breezy anyway?
<trulux> until 1.13 gets inside Breezy, then we can use "mine"
<jdub> fabbione: woo :)
<pitti> Keybuk: what holds back 1.13 for Breezy right now? dpkg sounds like "early breakage"
<Keybuk> I expect we'll put 1.13 in during the C++ transition, as it actually compiles with 4.0 and 1.10 doesn't :p
<pitti> ah, cool
<Keybuk> nothing's holding it back, just nobody's done it yet
<pitti> ah, ok, no showstoppers then
<Keybuk> it'll probably break a dozen or so builds
<Kamion> Keybuk: you aren't in the Ubuntu upload keyring, are you?
<trulux> Keybuk: then we hold dpkg SELinux support until 1.13 hits Breezy
<Keybuk> Kamion: yeah, I am
<trulux> we will gain momentun instead of lacking time
<Kamion> oh, ok
<trulux> now we must focuse on the rest of packages which are more easy to deploy
<trulux> pitti: need to build cron with WITH_SELINUX=1
<Kamion> Keybuk: is the Replaces fix in 1.13? I guess it'd just be a sync then, anyway
<pitti> trulux: are there more packages missing? I already have your packages from your site
<Keybuk> yeah it is
<trulux> pitti: I said I can't upload nothing
<trulux> you won't get the new packages from there
<Keybuk> can we sync from experimental?
<pitti> trulux: yes, but I'm interested which other packages are missing
<elmo> Keybuk: yes
<pitti> Keybuk: yes, we can
<Keybuk> elmo: pleased to be syncing dpkg from experimental
<trulux> pitti: ok: sysvinit, openssh, libpam (easy to fix now), logrotate, cron, dpkg (on hold?)
<trulux> pitti: coreutils
<pitti> trulux: okay, and I already have most of them
<pitti> trulux: (for the sake of testing). No problems so far
<mvirkkil> Are the python bindings for creating capplets in ubuntu?
<elmo> Keybuk: done
<daniels> elmo: did you get my syncs from the other day?
<trulux> pitti: I need a good python+GTK/Gnome hacker for the usability/user-side stuff
<Keybuk> trulux: there's a bunch of outstanding "neatness" changes to Manoj's patch, otherwise it looks clean, so will most likely be merged upstream soon
* pitti points to mvo, ogra, jamesh, and seb128 
<pitti> Hi mvo
<mvo> hey pitti 
<ogra> heh, speaking of the devil
<fabbione> hey elmo
<mvo> ogra: so you where speaking about me? :)
<mvirkkil> mvo: Hi. How's the pyapt stuff coming along?
<mvo> mvirkkil: have you checked the michael.vogt@ubuntu.com--2005/python-apt--mvo--0 branch ?
<ogra> mvo, nope, pitti was
<ogra> :)
<pitti> mvo:<trulux> pitti: I need a good python+GTK/Gnome hacker for the usability/user-side stuff
<pitti> mvo: * pitti points to mvo, ogra, jamesh, and seb128 
<pitti> mvo: :-)
<elmo>  [dpkg-source output:]  dpkg-source: error: file libidl_0.8.5.orig.tar.gz has size 456545 instead of expected 454225 
<elmo> seb128: ^---
<elmo> fabbione: hi
<mvo> pitti: aha :)
<elmo> daniels: going through backlog now
<seb128> elmo: hum, thanks
<trulux> pitti: just for a little while (did some cleanups to the patch, then I'll send you), lunch time
<fabbione> elmo: we missed you yesterday :)
<trulux> pitti: ;)
<daniels> elmo: thanks dude
<elmo> fabbione: yes, sorry about that :(
<fabbione> elmo: dude.. no problem.. i still love you a lot :)
<fabbione> today is even better... wife -> out
<elmo>  [dpkg-source output:]  dpkg-source: error: file monotone_0.19.orig.tar.gz has size 4796148 instead of expected 4796447 
<elmo> seb128: ^---
<mvirkkil> mvo: not in a long while. I halted all work on gnome-app-install since it seemed the whole idea would get revamped (and no one seemed interested in my patches).
<mvirkkil> mvo: Been toying around with a bootsplash thingie instead :P
<mvo> mvirkkil: yeah, someone needs to find time to look at your patches again, a lot looked pretty good :) but working on usplah is nice too
<seb128> elmo: :(
<seb128> elmo: these are conflict now, or just not imported stuffs?
<mvirkkil> mvo: Well, I never even sent the cleanup patch anywhere. I split everything up in to different classes, and tried to make a more logical structure. 
<elmo> seb128: stuff that can't be synced because we haven't a different orig.tar.gz to Debian
<seb128> elmo: right, but IIRC we have renamed some orig tarball due on such broken imports... no?
<trulux> back
<seb128> elmo: ie: is there any archive b0rkage due to that, or I just have to sync whatever way I want (ie: wait on next upstream is fine)?
<mvirkkil> mvo: But I realized that most of the stuff will get scrapped because of the new features.
<elmo> seb128: the archive scripts really can't cope with that kind of messing with the orig.tar.gz
<elmo> and mirrors are great fans of it either
<trulux> fabbione: potatoes "a la parmentier", do you know it?
<elmo> s/are/aren't/
<fabbione> trulux: no
<trulux> fabbione: aren't you Italian?
<seb128> elmo: ok
<fabbione> trulux: yes, but it tells me nothing
<fabbione> that sounds french to me
<seb128> that's french
<mvo> mvirkkil: there is a spec for cool new stuff, we'll have to see how much we can manage (have you looked at the udu.wiki.ubuntu.com page yet?)
<trulux> fabbione: hmm, sorry. I have NFC on French
<trulux> seb128: yep
* trulux checked the box
<mvirkkil> mvo: Yes. Looks like cool stuff is coming with breezy :-)
<mvirkkil> mvo: Though I _really_ hope aptitudes capabilities of tracking why a package was installed (was it a dep or not), would get integrated in to dpkg or libapt or whatever.
<mvo> mvirkkil: a patch is there, it needs review :)
<mvirkkil> mvo: Currently I use aptitude for that reason, and will not use any other.
<mvirkkil> mvo: Wow. Awsome.
<mvirkkil> mvo: Are there patches for synaptic and aptitude to use that?
<mvo> mvirkkil: not yet. we need to talk to daniel (aptitude upstream) if he would accept such patches. and synaptic shouldn't be too hard to integrate
<mvo> mvirkkil: I was toying with the idea to integrate the patch into synaptic first to see how well it works in the wild
<mvirkkil> mvo: Good. That's really a an important feature, and will make users feel less afraid of trying out software, since they won't need to be afraid of 'bloating' their system.
<mvo> mvirkkil: yes
<JaneW> mvo: ping
<JaneW> mvo: sorry to be a nag, but please update your Breezy Goals on http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<JaneW> they need statuses set and affcts kernel Y/N
<mvo> JaneW: will do, sorry for not doing it earlier
<JaneW> mvo: it's ok ;)
<maswan> Hm.. Speaking of breezy goals, is there a paying-customer path of influencing/adding goals?
<jdub> maswan: please email me
<maswan> jdub or jeff@u.c? or perkypants?
<jdub> maswan: jeff.waugh@canonical.com
<jdub> i only wear perkypants in my free time ;)
<maswan> Ah, ok.
* maswan sends mail frmo @work
<maswan> Nothing clear, just a bit of an inquiry and so.
<jdub> sure
<maswan> the background is that we @work want to see AFS, but do not have manpower. A bit of a support contract and stuff might be doable though. I'll be clearer in mail. :)
* maswan moves off to write stuff
<koke> ogra: have you seen this http://mail.gnome.org/archives/desktop-devel-list/2005-May/msg00075.html ??
<koke> for the GraphicalConfigTools one?
<koke> jdub: IIRC, you manage the mailing lists??
<ogra> koke, yay, great
<Kamion> elmo: thanks for the syncs
<jdub> koke: yo
<Kamion> "grep: /etc/crontab: No such file or directory"
<Kamion> I seem to get that during standard+desktop preconfiguration on every install
<koke> ok, I'll ask you for one maybe this week
<koke> jdub: BTW, my head is not showing at planet ubuntu
<Kamion> it's really tempting to divert fc-cache during the install in the same way we divert scrollkeeper-update, especially now that ttf-indic-fonts has been split up into a million tiny pieces that all call fc-cache in their postinsts
<jdub> koke: yeah, haven't figured some of those out yet
<jdub> Kamion: yes! :)
<thom> PHWOAR
<thom> hotpluggable dbus magic
<Lathiat> humm?
<Kamion> jdub: of course triggers would solve the same problem a lot more elegantly ...
* koke has to go
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released!  http://lists.ubuntu.com/archives/ubuntu-announce/2005-April/000023.html | MOM is awake! | Colony CD 1 released
<daniels> Kamion: nice work
<thom> Kamion: rocking
<daniels> Kamion: (he says, preparing to upload the packages that will doubtless monumentally fuck the archive)
<trulux> daniels: hey
<daniels> trulux: yo
<jdub> Kamion: yayayayayay!
<trulux> daniels: could you send me the details on how you got the psc scanner working, please?
<daniels> trulux: um ... 1) install hpoj, 2) sudo invoke-rc.d hpoj setup, 3) start xsane
<daniels> apparently hplip works with no configuration
<daniels> but I haven't tested that, been too busy
<jdub> Kamion: got an announcement for it?
<Kamion> jdub: already gone out
<Kamion> (before I changed the topic :-))
<jdub> Kamion: heh, rad :)
<jdub> Kamion: lwn, here we come :-)
<zul> anyone got a dm9102 card for some testing?
<trulux> daniels: I will try hplip, do you have good news on it? anyone has it working (both scanner plus printer)?
<daniels> trulux: i've only heard vaguely that it apparently works
<Kamion> pitti: USN-127-1> "indefinitively" => "indefinitely"
<trulux> dand: strange:
<pitti> uh, thanks Kamion (I guess I will ask for review next time)
<trulux> err
<trulux> daniels: got this:
<trulux> Probing "/dev/usb/lp0"...
<trulux>     *** Found "psc 1310 series " but failed to communicate with it!
<trulux> arrrgh
<trulux> shit
<trulux> daniels: http://216.239.59.104/search?q=cache:dhSkonGrkBoJ:www.belgeler.linux-sevenler.org/pdf.php%3Fcat%3D70%26id%3D412%26lang%3Den+PSC+1315+scanner+linux&hl=es&client=firefox
<daniels> i see
<jdub> Kamion: ha ha ha, good quote :)
<Kamion> maybe this release I'll actually keep coming up with quotes rather than giving up after CD 1. :-)
<trulux> daniels: really, I'm not getting the scanner working with this
<trulux> daniels: could you check further what you have there?
<trulux> it's important to to make Ubuntu supporting this devices
<daniels> trulux: all I know is what works for my 1210; right now I'm way too busy (it's 2337 and I'm looking at hours of work yet) to look into it further, sorry
<trulux> daniels: OK, any wiki page where I can write up on it?
<daniels> not sure ... maybe printingroadmap
<trulux> daniels: OK, brb, reboot
<trulux> daniels: thanks though
* Kamion makes slightly controversial seed change
<Kamion> (although it only preserves the status quo, for now :-))
<JaneW> mjg59: ping
<Kamion> there's a live CD on cdimage.ubuntu.com/daily-live/ now
<Kamion> (for breezy)
<Kamion> who knows whether it will work? :-)
* Lathiat gets a copy 
<Kamion> surak: 14:47 < Kamion> there's a live CD on cdimage.ubuntu.com/daily-live/ now
<Kamion> 14:47 < Kamion> (for breezy)
<Kamion> surak: you guys might want to try that out
<surak> Thanks, already getting it
<lu|bbiab> ooh
* lu|bbiab gets too
<JaneW> mjg59: ping
<Nafallo> morning
<JaneW> lo
<JaneW> does anyone know if anything is happening with edubuntu? I have had no responses from the guys yet...
<surak> Kamion: i see something odd here. The announcement says: " This release includes only the Install CD, as we haven't started to build the Live CD yet.  "
<surak> This link is for live cd. should it be announced also?
<mjg59> JaneW: Hi
<Nafallo> surak: nope, it's for installcd
<surak> Nafallo: there are two pages... http://cdimage.ubuntu.com/daily-live/ and http://cdimage.ubuntu.com/daily/
<JaneW> mjg59: hi, Juan says he is not on PowerSavingMode anymore. Can you take it, or are you overloaded already?
<Kamion> surak: Colony CD 1 is for neither of those URLs, it is for /releases/breezy/colony-1/
<daniels> surak: daily-live might not even work
<Kamion> surak: daily* are automatic, generally un-QAed, and unreleased
<Nafallo> surak: we're not talking about the same mail then ;-)
<mjg59> JaneW: Hmm. I probably don't really have time, I'm afraid
<Kamion> surak: I didn't release daily-live/ because I didn't build it until after I released Colony CD 1. :-) I'll release a live CD with Colony CD 2.
<Kamion> (and by the time I did that release, I was really *really* bored of testing CD images)
<lu|bbiab> hehe
<JaneW> mjg59: hrrrm, we may need to leave it off
<Kamion> JaneW: PowerSavingMode is not exactly crucial, I don't think
<Nafallo> LowPrio :-)
<daniels> agreed, low priority
<surak> :-)
<JaneW> Kamion: can I strike it from the list? - no I'll move it to Low ok?
<JaneW> ok done
<JaneW> bye
<JaneW> see you all at tech-board later
<jdub> oh
<jdub> good
<jdub> god
<maswan> yes?
* jdub kicks mozilla.org
<jdub> you can't get to the update/extensions stuff if you're running an older version of mozilla
<jdub> er, firefox
<maswan> you've discovered the no-extensions-unless-you-say-1.0.4 or later?
<jdub> http://www.mozilla.org/products/firefox/upgrade/
<jdub> yeah
<maswan> yes.
<jdub> HUUUUULK SMAAAAASH!
<whiprush> you have to manually set a version in about:config to 1.0.4
<maswan> "the 1.0.x series is just bug and secuirty fixes anyway"
<jdub> dude. what? no way. that is total crackrock insanity.
<Lathiat> whiprush: yeh thats pretty crack
<Lathiat> maswan: heh
* jdub smacks head
<Lathiat> just run breezy and get the new 1.0.4 package. :)
<Lathiat> hrm it mus thave FTBFS orsomething
<jdub> neh, doesn't work
<jdub> i am offended
<jdub> and hurt
<maswan> "RedHat and Fedora did it right. :)  I just pulled 1.0.4 on Fedora this morning."
<bluefoxicy>  * Starting Hardware abstraction layer:
<bluefoxicy> /usr/sbin/hald: unrecognized option `--drop-privileges'
<Kamion> Lathiat: try 'firefox', not 'mozilla-firefox'
<Kamion> (still in universe as yet)
<Kamion>    firefox | 1.0.4-1ubuntu2 | breezy/universe | source
<Kamion> oh, no, you're right, it didn't build
<Lathiat> no such package apparently
<Lathiat> yeh
<bluefoxicy> what?  Ubuntu is moving from mozilla-* to *?
<maswan> (quote from the mozilla guy I pestered about that)
<jdub> maswan: because new versions never have new security holes!
<Kamion> hmm, that's odd, it did build but apparently didn't get uploaded or something?
<g14> Will prelinking be turned on by default in breezy?
<Kamion> bluefoxicy: trademark requirements from the mozilla foundation
<elmo> it's new
<Lathiat> Kamion: new package name needs manual accpetance or something?
<Kamion> see the changelog
<jdub> g14: no, it's undesireable
<Kamion> elmo: it's not in queue/new
<g14> jdub: Why? It improves performance
<Kamion> g14: it disimproves maintainability
<maswan> jdub: yes. but the conclusion is that a security fix should bump the vendorVersion or whatever to the latest mozilla.org release. or something.
<jdub> g14: not always, and not nicely
<elmo> Kamion: that's because I just processed it
<Kamion> elmo: oh :-)
<jdub> elmo: sneaky yay!
<g14> jdub: Well your not even going to include prelinking for bloatware like OO.o? It even ships with "ooprelink1.9"
<g14> Fedora has a semi-intelligent cron script for prelinking some stuff
<g14> I was just curious why it isn't in ubuntu
<Kamion> we looked at it and decided against it
<Lathiat> just becuase fedora has it doesnt mean its the right thing to do
<jdub> g14: it rated very high on the baby-jesus-o-meter
<g14> Lathiat: I completely agree, I don't know much about how it works and was just asking.
<Lathiat> g14: righto.
<g14> And how does it make maintainability worse?
<Kamion> binaries aren't what the .debs shipped any more
<Kamion> sucks for various reasons
<Kamion> debuggability, reproducibility of problems, etc.
<g14> That makes sense
<g14> I am afraid to update to breezy yet on this machine to test, but does anyone know soundservers very well?
<g14> I know breezy is switching from esd to polypaudio and was wondering if it will have the same problem esd does
<jdub> RHEL 2.1 was upgraded to mozilla 1.7
<Lathiat> g14: Youd have to be specific about the problems to get an answer to that...
<jdub> that is INSANE
<jdub> g14: *might* switch, *might*
<bluefoxicy> Kamion:  ah, good.
<maswan> jdub: anyway, the mozilla.org stand on that is that distributions should bump general.useragent.vendorSub for firefox to 1.0.4 if the distribution fixes the security problems that 1.0.4 was released for.
<bluefoxicy> Kamion:  I prefer 'firefox' and 'thunderbird' to mozilla-*
<jdub> maswan: which no one can sanely do anyway ;)
<bluefoxicy> remember they're sub-projects hosted by mozilla but developed as independent
<bluefoxicy> they're not mozilla :p
<surak> g14: prelink loves to suck all baterry juice in fedora... several people are not fond of it @ fedora-devel...
<Kamion> interesting how http://www.mozilla.org/foundation/trademarks/policy.html talks about "Mozilla Firefox" then
<maswan> jdub: well, the mozilla guys have some odd ideas. like the requirement for a top-level mirror to sync every 10 minutes.
<g14> http://www.ubuntuforums.org/showthread.php?p=175681 I started this thread
<surak> g14: (talking about notebooks)
<jdub> maswan: ...!
<maswan> jdub: exactly.
<jdub> maswan: makes baby elmo cry :)
<g14> If you use gdmflexiserver to start new user sessions, there are issues with esd accepting sound events from other users
<bluefoxicy>  # linux happens.  Blah
<bluefoxicy> # alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"BAD-TRAFFIC bad frag bits"; fragbits:MD; classtype:misc-activity; sid:1322; rev:7;)
<bluefoxicy> bad-traffic.rules, from snort o_O
<surak> g14: are there issues with what? Mostly are permissions, ain't it?
<bluefoxicy> ok, I need to know
<g14> surak: Not permissions at all
<bluefoxicy> what the hell determines where synaptic puts a confirmation window to replace a config file?
<maswan> jdub: indeed. we just about manage to keep up with that, normally a sync takes 2-4 minutes.
<ogra> surak, if esd runs already its owned by the former user
<bluefoxicy> some times they pop up left aligned with the synaptic window, you click yes, the next is aligned like 150 pixels farther right
<trulux> pitti: ping
<pitti> trulux: pong
<bluefoxicy> and they alternate between those two positions, somewhat
<trulux> pitti: did you like the patch?
<g14> surak: esd is started by the primary user who logs in via gdm. When gdmflexiserver starts a new session, esd is already started as the first user. Adding the fix in my post will allow it to proxy sound
<bluefoxicy> it's kinda random.
<trulux> ;)
<pitti> trulux: sorry, still swamped in security updates *sigh*
<ogra> doko, -dbg packages are renamed accordingly to the binarys ? 
<pitti> trulux: I'll take a look at it now, squid hates me anyway (will continue tomorrow)
<g14> surak: But thats not an optimal solution. I was wondering if polypaudio will fix this
<doko> ogra: they don't have to
<trulux> pitti: ok
<ogra> doko, thanks
<bluefoxicy> g14:  why isn't esd a system service
<g14> bluefoxicy: I'm not saying it should be a system service, that could have security issues. I was just wondering if polypaudio will proxy sound events from different users better
<g14> bluefoxicy: If not, maybe I could look into figuring out how it could
<bluefoxicy> g14:  it should be a system service that drops caps and becomes user 'esd'
<bluefoxicy> g14:  if it's owned by, say, me
<bluefoxicy> and someone exploits it
<bluefoxicy> they have access to my account
<bluefoxicy> On a multi-user machine, esd is started by the first user logging in?  That means you have a hit-or-miss at hijacking a random user's account if you have a way to hijack esd, yes?
<g14> bluefoxicy: Yes, you bring up a really good point that would solve the problems
<bluefoxicy> g14:  ask pitti or trulux though, or tseng, 'cause i'm not really much of a security expert more than someone in his parents' attic with a turring logic engine for a brain  ;>
<pitti> trulux: btw, SELinux is built into the kernel since hoary times (just enable at the kernel command line)
<g14> bluefoxicy: Thanks for the ideas, that will make breezy "that much better"
<pitti> trulux: (reading your spec)
<g14> But I've got to run out for a bit
<bluefoxicy> g14:  I'm also interested in polypaudio, when it's ready to properly support esd
<trulux> pitti: I know
<bluefoxicy> last time ubuntu went that way though shit broke :)
<bluefoxicy> aight bye then
<jdub> Kamion: hrm, will breezy be able to install and run from firewire?
* zyga just saw ps3 promo videos
<zyga> fantastic hardly describes it
<pitti> trulux: read your patch, looks really nice
<pitti> trulux: I'll try to apply it against our 2.6.12 kernel
<trulux> pitti: great, bbl, class
<pitti> trulux: upstream inclusion would be nice 
<pitti> trulux: but it's unintrusive enough to be applied anyway, I think
<trulux> pitti: vsec upstream inclusion even more
<trulux> yeah
<pitti> trulux: yeah, see you later
<trulux> pitti: ok, must go to class
<trulux> pitti: I hope to catch you around 6:00pm
* trulux away
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released! | MOM is awake! | Colony CD 1 released | gcc4 transition starting, breezy probably well broken
<Lathiat> note to self: dont upgrade
<Nafallo> Lathiat: hehehe
<daniels> we're also starting the /usr/X11R6 -> /usr transition with some, um, interesting hacks
<Lathiat> i thought we were trying to get rid of the hacks. :)
<daniels> this one is just to placate the buildds
<daniels> xorg-common -10's postinst checks if /usr/{include,lib}/X11 are symlinks and bombs if so
<daniels> x-common's postinst removes those if they're symlinks and makes directories of them
<daniels> xorg -11 removes the bit of xorg-common's postinst that does that check and bombs
<daniels> but xorg -11 also build-depends on a couple of things which pre-depend on x-common
<daniels> so x-common's postinst runs, usually before xorg-common's, so you can't fulfill the build-deps
<daniels> so x-common now pre-depends on xorg-common
<mako> schweeb: hey dude
<Lathiat> daniels: heh
<lu|bbiab> Kamion: FWIW, the new liveCD seems to work fine so far
<Nafallo> Kamion: ping
<Kamion> lu|bbiab: miracles sometimes happen. :)
<Kamion> Nafallo: yes?
<Nafallo> Kamion: shouldn't cdimage.u.c/daily/jigit/ be updated?
<lu|bbiab> indeed :)
<Kamion> Nafallo: good point - done, thanks
<Nafallo> Kamion: glad you helped me. I'm about to make some nice mirrorscripts :-).
* Lathiat boots the livecd
<Lathiat> Kamion: everything works great, not sure if we want the update notifier running on the livecd tho? especially since it already thinks there are updates to OO.o on boot. :)
<Lathiat> for everything values of vmware anyway
<Lathiat> Kamion: hmm, seems to be using hoary packages ? 
<Kamion> Lathiat: update-notifier> *shrug*, it's in desktop, so it's on both. it's fine and sometimes useful to upgrade the live CD
<Lathiat> sources.list is hoary and from what i can tell the packages seem to be too? base-config isnt updated at least, dunno what else to look at.
<Kamion> that would be a lamont question
<Kamion> lamont: ^--
<Lathiat> is the install cd likely to be in at last some possibly working order?
<Kamion> Lathiat: considering I just released yet, one might think so
<Kamion> er, "released it"
* Lathiat wonders how rsyncable against hoary-install it is
* Lathiat tries
<Kamion> Lathiat: slightly, but it's not great
<Nafallo> Kamion: you can't have jigit for dvds?
<Kamion> Nafallo: takes far too long to generate
<Kamion> and besides I haven't started breezy DVD builds yet
<Nafallo> Kamion: aha, so that's the problem :-).
<Nafallo> Kamion: well, you will sometime ;-).
* Nafallo settles for install- and livesyncs support :-)
<lamont> Kamion: oops
<trulux> back
<trulux> pitti: heya
<pitti> Hi trulux
<trulux> pitti: howya?
<pitti> trulux: I ported your patch to 2.6.12 (was easy) and started building the kernel
<pitti> trulux: however, that will still take a while until it is ready
<pitti> trulux: I started it on powerpc for now
<trulux> pitti: tell me, lemme take all the kernel hacking work
<pitti> trulux: tell what?
<trulux> though I'm a sucking-portability kid
<lamont> Kamion: guess I should detect what suite I'm building the fs for, eh?
<trulux> pitti: errors, etc
<trulux> pitti: oops, whatever else
<trulux> pitti: could you send me your dmesg?
<trulux> dcc here
<pitti> trulux: uh, they were rather trivial, just some patches that didn't apply (like KERN_SECURITY=68, that must be 69 in 2.6.12, etc.)
<trulux> right
<pitti> trulux: the kernel hasn't yet built
<pitti> trulux: if it finished, I download and test the deb
<trulux> I still work on 2.6.11., 'cos the kernel guys won't take patches for 2.6.12 if they're not bug fixes and the like
<pitti> trulux: yeah, but we are based on 2.6.12rc4 now
<trulux> pitti: no worries, will work over it
<Kamion> lamont: yeah, might be a plan :)
<pitti> seb128: here?
<trulux> I stack the patches with akpm's utils, so, I can cross-work on a few mm and other trees ;)
<lamont> Kamion: you need new images soon ish, or can I wait a bit to actually fix it?
<Kamion> lamont: don't mind
<lamont> Kamion: and yes, that means you got a hoary fs, at least recently
<lamont> I think it might be left over from me doing the hoary-base fs images
<Kamion> lamont: just turned the daily-live cron job off again though; let me know when you've done it and I'll turn it back on again
<lamont> woot
<lamont> dealing with g++ transition right now, that's next on the list
<lamont> source fixed, etc.
<trulux> pitti: the spec. is OK for you, right?
<pitti> trulux: a little verbose, but nice
<Riddell> elmo: could you let knetworkconf into hoary-updates?
<pitti> trulux: however, it should be merged into the official wiki spec
<pitti> trulux: since it needs to be ack'ed by mdz 
<elmo> Riddell: no, you need kamion or mdz
<trulux> pitti: yup, cc'ed mdz for it
<trulux> pitti: I will try to upload it ASAP (THIS DAMN MAHCINE IS STILL BEING RESTORED)
<Riddell> Kamion pointed me at elmo yesterday
<trulux> -ECAPS
<trulux> :)
<pitti> trulux: upload the SELinux patched packages?
<Riddell> Kamion: are you able to do it?
<pitti> trulux: do you have them somwhere else?
<trulux> pitti: I'm going to build them, when should we upload them? after you test the stuff?
<trulux> pitti: nope
<pitti> trulux: after I tested all of them for a couple of days and mdz blesses them
<elmo> Riddell: best way to do these things that involve multiple people, is to mail mdz (+ kamion), cc me.  then when kamion or mdz ack it, I can do it without fear of wrath and retribution
<pitti> trulux: I'm fine with them, and it's still early in the development cycle, so unless something crucial breaks, I would be glad to upload them asap
<elmo> Kamion: but, fwiw, you have katie supah powahs again
* Riddell wills Kamion to use his katie super powers
<trulux> pitti: OK, going to build coreutils and some others
<trulux> pitti: fun();
<Kamion> Riddell: ok, I'll have a look in a moment then
* pitti kicks cdbs
<pitti> jbailey: here?
<jbailey> pitti: Yup
<pitti> jbailey: I added a "common-post-build::" rule, but it is never called
<pitti> jbailey: what is the right rule to add stuff to which must happen after the source gets built?
<jbailey> pitti: Use the arch bits.  I'm just on the phone, but I can look it up after.
<pitti> jbailey: I modify gnome.mk to automatically update the pot file for gnome packages, this will save us from modifying a bazillion gnome packages
<jbailey> Ah, nice. =)
<pitti> jbailey: however, -arch wouldn't be called on arch: all packages?
<pitti> jbailey: likewise, -indep might not be called on packages which only produce arch:any (or is it?)
<jbailey> pitti: The buildds ignore Debian policy.  I think -arch is always called.
<pitti> ah, neat
<pitti> jbailey: yay, -arch works
* ..[topic/#ubuntu-devel:doko] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released! | MOM is awake! | Colony CD 1 released | gcc4 transition starting, breezy probably well broken, uploads of C++ packages restricted
<pitti> yay doko
<fabbione> GO DOKO GO!
<pitti> gimme the b0rk :-)
<fabbione> be sure something will break down to death
<ogra> even if it's us afterwards :)
<pitti> lol
* fabbione starts to feel tired
<fabbione> 14 hours and 30 minutes already :/
<ogra> fabbione, for one kernel build ? 
<doko> heh, we're rocking again in some hours ;)
<fabbione> ogra: no, since i started this morning
<ogra> i knoww...
<fabbione> doko: yeah.. if X will not break
<ogra> <--- kidding
<doko> fabbione: does it use gcc/g++ or gcc-4.0/g++-4.0 for the build?
<fabbione> doko: yes
<ogra> heh
<fabbione> gcc/g++ <-
<fabbione> but daniels did test build with 4
<fabbione> and i am retesting right now
<doko> Ubuntu Installer  May 17   10/256   "gcc-defaults_1.23_source.changes ACCEPTED"
<trulux> is there any way to remove exif information from photos?
<fabbione> doko: where is build-essential? :)
<doko> uploaded
<trulux> got it
* fabbione phears doko's power
<doko> ok, bbl for now, see you later :)
<fabbione> cya later doko
<Kamion> Riddell: Installed 1 package set, 111 KB.
<jbailey> pitti: Hey - if sb's okay with that patch, feel free to upload it.
<pitti> jbailey: okay, will do
<jbailey> pitti: I'll work out backporting it to Debian at some point later.
<jbailey> pitti: GIven their freeze, I probably won't touch it in Debian until after Sarge releases.
<pitti> jbailey: oh, in any case
<pitti> jbailey: it has the potential to make half of gnome FTBFS :-)
<jbailey> Brekaing things doesn't scare me..
<jbailey> Kamion coming after me for breaking the Sarge release scares me. =)
<pitti> jbailey: well, for Sarge it should
<pitti> jbailey: ah, right :-)
<seb128> pitti: now here
<pitti> seb128: you have mail
<seb128> k
<seb128> pitti: you have mail from carlos on the cdbs mail :)
<maswan> elmo: what timeout settings do you ahve on the archive syncproxy?
<elmo> maswan: on rsync? 7200
<maswan> Odd, because we fail after half an hour with "rsync: read error: Connection timed out"
<seb128> elmo: file-roller verbiste sync from experimental please
<maswan> and that sync is with --timeout 7200
<elmo> maswan: reproducably?
<maswan> elmo: yeah, we've had this issue since we started mirroring mozilla with the insane updating frequency they have
<elmo> May 17 11:42:10 syowa rsyncd[11920] : rsync error: timeout in data send/receive (code 30) at io.c(153) 
<elmo> is that you?
<elmo> (GMT+1)
<elmo> seb128: verbiste?
<elmo> oh, it's a package
<seb128> right :)
<elmo> [BLACKLISTED]  verbiste_0.1.9-2ubuntu2
<maswan> probably
<elmo> seb128: I guess it's CXX
<elmo> and it thinks nothing to sync for file-roller
<maswan> Done at Tue May 17 19:01:12 MET_DST 2005
<maswan> last was that
<maswan> which means half an hour ago
<elmo> eh, ignore that about file-roller
<seb128> elmo: 2.10.3 from deb
<seb128> k
<elmo> file-roller done
<seb128> the other is probably CXX right, I'll wait
<seb128> thanks
<elmo> maswan: odd, I don't see anything in the logs on this side at all
<maswan> Starting at Tue May 17 18:31:24 MET_DST 2005
<maswan> or in relative terms, exactly one hour ago now
<maswan> Ok, want me to start a new one and see if that one turns up somewhere?
<elmo> err, meh, sorry, yes I do see it
<elmo> May 17 17:31:24 syowa rsyncd[13644] : rsync on ubuntu from se@churchill.acc.umu.se (130.239.18.141) 
* maswan nods, exactly that one
<elmo> why on earth are the rsync's taking so long in any event?
<maswan> I don't know, perhaps mozilla is evicting too much from the metadata cache these days. I don't know really.
<maswan> Hm.. I can check with vfsstats and see what takes time though.
<maswan> I might drop the mozilla mirror if it is this bad, but I hope we can get away with it. :)
<thom> elmo: did you see my firefox request from yesterday?
<pitti> seb128: I updated http://people.ubuntu.com/~pitti/gnome.mk, could you please take a look at it?
<thom> huh, firefox in breezy is really crashy :/
<Lathiat> yeh it is
<Lathiat> i think i fixed some of it by nuking flash player
<thom> i have no flash crap
<Lathiat> like i said, some.
<lamont> Kamion: you around?
* Riddell was about to ask the same thing
<g14> trulux: To strip exif and comments out of images, try mogrify -strip image.png
* lamont goes to do a little on-site support work, about 500 meters from his house
<trulux> g14: thanks, worked
<trulux> :)
<Kamion> lamont: yes?
<Kamion> Riddell: yes?
<Riddell> Kamion: I don't see knetworkconf in hoary-updates
<HiddenWolf> nautilus should die. :P
<elmo> Riddell: check with lamont
<elmo> it's in hoary-updates as source
<fabbione> elmo: i think all the buildd are stopped atm
<elmo> that'd do it :)
<elmo> in any event, it's not kamions problem
<thom> elmo: please move firefox to main and ditch mozilla-firefox like the bitch it is ;-)
<fabbione> thom: firefox is already in main :)
<fabbione> elmo is FAST
<fabbione> elmo > concordia
<thom> oh? cool cool
<thom> it wasn't last time i checked, is all
<elmo> fabbione: concordia's no longer the daddy battlestar
<fabbione> elmo: uh?
<elmo> our latest batch of machines are something like 10-15% faster than concordia
<fabbione> which one is faster now?
<fabbione> ah
<thom> fabbione: you can't have them though ;-)
<fabbione> elmo: can i get a distcc cluster with them?
<fabbione> thom: i absolutely don't want access
<fabbione> just a nice distcc setup would make me more than happy
<fabbione> make -j 1024 :P
<Amaranth> anyone object to putting a notice in the #ubuntu topic about not upgrading in breezy for awhile?
<maswan> elmo: Ok, now we aren't mirroring mozilla as much anymore, and now the syncs work fine
<elmo> maswan: boggle
<maswan> elmo: Metadata operations are more complex in the clustered case, and if mozilla keep evicting ubuntu files from cache and generally taking up token management resources etc..
<elmo> maswan: btw, is memtest86+ slow for you on your opterons?
<maswan> elmo: some of the tests are really, really slow, yes. I think we take one or two out of the default just because they are too slow, I just don't remeber which offhand
<elmo> ok, that's cool, as long as it's generic
<torkel> maswan: I think we are running all default tests and some of the extra test, but not all of them.
<maswan> torkel: ah, that way around.
<dholbach> hellas
<lamont> Riddell: knetworkconf_0.6.1-3ubuntu3 (dist=hoary-updates)??
<lamont> FTBFS
<elmo> DOH
<Kamion> 3ubuntu4 should fix that
<lamont> even better
<Kamion> that was the one I just accepted
<lamont> that should just churn through then
<elmo> lamont: it dropped back to needs-build
<Riddell> lamont: amu uploaded an ubuntu4
<Riddell> ah, you're ahead of me
<trulux> fabbione: that would be great for all of us much like the OSDL distributed compiling and kernel benchmarking network
<trulux> I really love it
<Zomb> hi
<Zomb> does the Live-CD use Knoppix technology or some custom solution?
<mjg59> Custom
<maswan> elmo: btw, I did a check with the vfsstats thingie in gpfs, and during a normal, mostly empty, debian sync, there are about 3M lookups.
<elmo> sweet
<elmo> are you using --include/--exclude at all?
<maswan> hmm. we --exclude one file, yeah, the tracefile
<elmo> I've noticed rsync do some super retarded things with --include/--exclude, I'm not 100% sure yet tho
<maswan> yeah, I just thought that was cpu-wise, but I'll take a look.
<maswan> probably tomorrow during the day when it is more quiet. :)
<maswan> elmo: oh. right. the two-stage rsync is --exclude on Packages* & friends.
<maswan> on the first rsycn
<elmo> ah, right.  hum.
<maswan> yeah. can't really think of a good way around that one right now
<thom> dholbach: crashy bangy firefox?
<dholbach> thom: yep, but nautilus was even better: it started tearing the cpu apart :-)
<blueyed> The torrents are up again. Thanks!
<thom> np
<thom> dholbach: lovely
<dholbach> seb128: the backtraces that had like millions of empty entries, if i left gdb for an hour :)
<seb128> oh right
<Kamion> that's usually a corrupted stack
<Kamion> valgrind's a good tool to attack that with
<dholbach> ok
<seb128> anybody with an opinion on that?
<seb128> gnome-menus ships a simple python menu editor now
<seb128> I'm wondering if that's better to ship it with gnome-menus (which contains the menu definition and the translations)
<ogra> sounds good
<seb128> or to make a package with it?
<ogra> how does upstream handle it ? is it in the gnome-menus tarball ?
<seb128> yep
<dholbach> i'd make another package
<seb128> gnome-menus has the lib, the menus definition, the python binding and the editor
<ogra> i'd do what upstream does
<seb128> dholbach: an another package would mean to depends on gnome-menus
<seb128> or to make yet another package: -common with the translations
<dholbach> hrm
<seb128> ogra: upstream never split :)
<ogra> heh
<seb128> I'll make a python-gmenu even if they don't :p
<dholbach> does kde give you ONE big .tar.gz?
<dholbach> :-)
<seb128> k, I'll not split because the translations are not splited any case
<ogra> seb128, what about this one ? http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00268.html
<tseng> dholbach: close :)
<seb128> ogra: dunno what to do with that, I've fixed some build issues due to it for 2.10
<ogra> tseng, did you grok, there'll be a extra meeting for maintainer approval next week
<tseng> ogra: hm so where is the agenda for that?
<seb128> the CVS has a part of the code
<ogra> seb128, i have the task for a passwor changing tool 
<seb128> I say a part because there is no option to build it and some sources files were not here
<seb128> I had to grab them from bugzilla or to workaround
<seb128> ogra: let's wait on the thread on -desktop 
<ogra> seb128, and i may spec some bountys for GraphicalConfigTools, probably the guy could just finish it...
<ogra> i know mdz has a certain interest in password changing functionallity
<seb128> upstream too
<ogra> (via gui without sudo that is)
<seb128> let's wait what we do upstream
<ogra> okay
<dholbach> good night pals, i'm off to bed
<mvo> dholbach: night
<ajmitch> hi mvo 
<Surak> ogra: I got the chat from the middle. Are you interested in a password changing utility?
<dholbach> *wave*
<ogra> Surak, yes, but if gnome introduces one itself, its the preferred solution
<Surak> right
<Surak> only for password changing or something like windows' user accounts management?
<Surak> only a passwd myself?
<ogra> yep
<seb128> and it they don't the preferred solution is to work with them to make it working upstream
* mvo waves to ajmitch 
<ogra> yep
<Surak> right. one of our guys was doing something like that some time ago. Will let him know, maybe he can contribute
<ogra> amu ?
#ubuntu-devel 2005-05-25
<amu> ogra: jo?
<ogra> http://gnome-ppx.berlios.de/screenshots/?PHPSESSID=091040f0a95c082f113d54de15a59bf4
<ogra> :-D
<amu> ogra: *totalgrass* 
<ogra> amu, yeah, i stumbled across it today when i reviewed serpentine (CD burner) of this guy... this app is already quite old, should be stable
<amu> ogra: but still not good as knet :D
<mdke> looks pretty cool
<ogra> amu, i thought about it for the dialup spec
<ogra> it handles pppd, so normal dialup handling should be trivial to implement
<amu> ogra: http://www.kde-apps.org/content/show.php?content=10202
<mdke> it seems to do pppoa
<mdke> cool
<kent> ogra, I might be alone with this feeling, but shouldn't gnome trie to drop some of the hardcore-semantics?  I meen, for example, those screenshots use the word "superuser" and "root". Which normal people would understand those words? 
<amu> ogra: ^^ that's cool 
<ogra> kent, the wouldnt appear in ubuntu
<ogra> they even
<ogra> amu, thats KDE
<ogra> :)
<ogra> (would be cool if they used a real widget set *g*)
<amu> ogra: still good for plan B.) remove gnome as default desktop with kubuntu's one :)
<ogra> bah
<ogra> :)
<amu> i'm sure about it, another 12 month later, kubuntu has double downloads compared to ubuntu *ducks&runaway*  
<ogra> heh
<herzi> doko: ping
<doko> ?
<ogra> amu, gnome is too good, the normal ubuntu downloads will rise as well so no chance to catch us :)
<herzi> doko: remember the gdb on ppc bug with the broken stack traces?
<herzi> debian-powerpc seems to have solved this
<doko> herzi: on the lists?
<herzi> yes
<doko> thanks, I'll have a look tomorrow
<bluefoxicy> doko:  will you tell those bastards to fix their shit so you can get OOo working on amd64?  I'm really not liking being stuck with 1.1.3 but having 2.0-beta79 in a 32 bit install :/
* bluefoxicy wonders if OOo compiles on a SPARC64, considering Sun controls the hosting. . . .
<doko> I don't know any bastards
<ogra> doko, ? you dont ?
<bluefoxicy> ogra:  Evidently doko lives in a place where the divorce rate and teen pregnancy rate are quite low :)
<bluefoxicy> (you must use 'are' when referring to multiple subjects, unlike some of the descriptions for some packages)
* bluefoxicy sips his green tea
<schweeb> mako: dammit, keep missing each other
<schweeb> mako: just wanted to know if you ever found out if I had to sign the CoC again or what
<stuNNed> which is the old method, inotify or dnotify?
<tseng> dnotify could be considered "old"
<tseng> inotify in hoary smokes serious ammounts of crack
* stuNNed lights up
<stuNNed> can revert to dnotify in hoary?
<tseng> thats the default
<stuNNed> k i didn't have it installed for some odd reason
<stuNNed> that why having trouble with gamin i wonder
<tseng> huh?
<tseng> have what installed
<stuNNed> dnotify
<tseng> theres nothing to install
<tseng> they are both kernel bits
<stuNNed> dnotify_0.18.0-1_i386.deb  <-wuzzat?
<tseng> beats me
<tseng> maybe a userspace implementation of the same thing
<stuNNed> my Desktop has been smoking crack saving files to it they don't show up unless `killall -9 nautilus`
<floogy> I have now a heavily mixed system (pinning) with breezy libc6. What should I do during the transition? downgrading? I'm using also a lot of sid packages.
<stuNNed> smoke more crack?
<tseng> support in #ubuntu btw
<tseng> but thats a pretty cracked out setup
<floogy> Yes, I expect that it'll be hard to find help on #ubuntu. O.K. I will pin hoary to 1001.
<Burgundavia> floogy, why are you doing such crazy things?
<floogy> because I wanted to have transcode and hugin for example, and I was used to use a mixed sarge/sid system of debian. I forgot the process of transition in 2002, but I think I did also a downgrade then...
<Burgundavia> floogy, ok then. When you transition to Breezy, you should be able to get rid of most of that
<floogy> Burgundavia: You mean, I should pin breezy instead of hoary to 1001, to get all the sid and hoary packages to breezy, instead to hoary. And wait for breezy to complete the trabnsition before "downgrading"/forcing to breezy?  
<spo0nman> is there some way to have a "build env" so that i could run both hoary/breezy on the same box?
<floogy> spo0nman: chroot env? http://www.ubuntulinux.org/wiki/DebootstrapChroot
<spo0nman> floogy, hmm
<schweeb> spo0nman: pbuilder
<schweeb> if you're only wanting a build environment
<schweeb> if you're wanting to test apps, a chroot is probably the way to go
<schweeb> or user mode linux
<spo0nman> what is the standard ubuntu way of things?
<schweeb> if you're building packages, pbuilder
<TheMuso> There is also the classic dual boot.
<schweeb> if you're testing apps by actually running them, chroot
<schweeb> user mode linux is nice, but a bit difficult if you don't know what you're doing
<schweeb> there's also VMWare
<spo0nman> vmware would be slow...
<schweeb> VMWare isn't too bad
<HrdwrBoB> vmware isn't very slow
<HrdwrBoB> TheMuso: not terribly effecient
<schweeb> quite inefficient
<schweeb> eventually I want to have Xen set up, but I have a distinct lack of time
<schweeb> so pbuilder or chroot or u-m-l are my usual methods
<spo0nman> thanks schweeb.
<robertj> was there enough salacious conversation in #ubuntu-meeting to make it worth reading the logs ;)
<tseng> i told Amaranth his app sucked, and his stabbed me
<tseng> that was the hilight
<robertj> I'm sold
<robertj> i'll have to read it online until the paperback arrives though
<robertj> hehe, Ogra's express mockup looks a bit like Apples installer
<Lathiat> daniels: so i should wait a few hours before i update? :)
<daniels> it's all good if you like fun
<Lathiat> what kinda fun. :)
<fabbione> Lathiat: no, you must update now, break your system and cry :)
<Lathiat> ah but then you'll all get sick of me whinging :)
<fabbione> and we can ban you from the chan :)
<Lathiat> ah but i could go scr1pt k1dd1e stylez and join from like 100 h0st5
<Lathiat> i think the general solution is to just wait. :)
<Amaranth> jdub: ping?
<pitti> Good morning
<jdub> Amaranth: pong
<Amaranth> jdub: Could you add CarlK to the #ubuntu access list?
<pitti> Hi ogra/ogra_d (who is who?)
<jdub> Amaranth: done
<Amaranth> jdub: thanks
* fabbione starts the Colony 1 rsync dance
<NZheretic> Dial up access is a pig of a system in Ubuntu, even Fedora is easier! WHERE THE HELL is the modemlights applet in Hoary! As far as the Ubuntu "documentation" floating around the web . there are three conflicting solutions for the same problem which configure/front dial-up access :  pppconfig+pon+poff+gpppon , gnome-ppp+wvdial  and the curretly not working modem applet ( requires administrator password even if the user is in the
<NZheretic>  approprate groups  )+network monitor. 
<Lathiat> sigh someone complaining on ubuntu-users about prelink.
<daniels> NZheretic: try being less inflammatory and more constructive, ok?
<Lathiat> NZheretic: This is the wrong channel for these questions, please ask in #ubuntu
<Lathiat> NZheretic: If you are trying to get the problem solved and have a nice way to do this in ubuntu, in which case filing a bug in ubuntu bugzilla would be a good start. (and what daniels said)
<Lathiat> NZheretic: also, there is a modem monitor applet on the panel installed by default, but i have never used it.
<NZheretic> I am about to file a bug report for the curent  modem applet (   requires administrator password even if the user is in the group ),  I have just managed to get the combination of  pppconfig+pon+poff+gpppon with network monitor working, but not really well enough for the target newbe user ( she has a crappy POT phone service, needs live connection monitor )...
<fabbione> Kamion: can you please schedule http://people.ubuntu.com/~fabbione/sparc-no-usb.diff for the next d-i upload? our sparc64 doesn't have usb yet
<NZheretic> with warty it was possible to use pon+poff from modemlights. The choice to drop modemlights in favor of current applet was not a good choice.
<daniels> NZheretic: again, file a bug
<daniels> barging in here and rambling on is a good way to get forgotten very quickly
<NZheretic> daniels : consider it done tonight.
<NZheretic> daniels : I want to pull down the code to see if I can supply a patch.
<pitti> Hi seb128 
<seb128> hey pitti 
<fabbione> hey pitti
<jsgotangco> hey hey hey
<mvo> hey jsgotangco 
<jsgotangco> mvo, hey its been a while how have you been
<mvo> jsgotangco: very well :) how about you?
<jsgotangco> been busy for  a while, i have  new client for an oracle implementation just 45 day project though
<cartman> gcc on breezy changed targer from x86_64-linux to x86_64-linux-gnu (for amd64). Is this intended?
<fabbione> cartman: yes. we love to break more than required
<fabbione> :P
<cartman> yeah that sounds about right indeed...
* Lathiat grins
<cartman> anyway I guess this is the final decision?
<pitti> seb128: are you fine with my cdbs gnome.mk proposal?
<pitti> carlos: you as well?
<carlos> pitti, I think so, but let me read it again
<seb128> pitti: not tried it yet, on my list for this morning :)
<seb128> pitti: any hurry?
<carlos> pitti, yeah, looks ok for me
<pitti> seb128: no particular hurry, no
<pitti> carlos: okay, thanks
<seb128> pitti: just looked on it, looks fine (assuming than the DOMAIN regexp works as expected but I trust you on that, you have probably played with it) :)
<seb128> go go go
<pitti> seb128: it works for the three cases I tried it with :-)
<seb128> k, should be fine, upload, that's an unstable branch anyway
<pitti> seb128: in any case, even if it is wrong, the worst that can happen is that it doesn't generate a pot
<seb128> right
* pitti watches 2.6.12 boot on his laptop
* \sh checks why breezy morphes into hurd
<\sh> -rw-r--r--  1 shermann shermann  2688 May 18 08:08 libqssl-dev_2.0-1ubuntu1_hurd-i386.deb
<\sh> -rw-r--r--  1 shermann shermann  2154 May 18 08:08 libqssl2_2.0-1ubuntu1_hurd-i386.deb
<\sh> .oO(???)
* Lathiat wonders how that got thru
<pitti> \sh: ssh, that's a surprise, don't spoil it :-)
<Lathiat> i see a few hurd things try to autosync every so often
<\sh> pitti: yeah it is...after building it by myself, I can say: I have hurd running on my laptop ;)
<\sh> but any reason why this is happening? after considering that Q is not around and Guinan is not watching me, I don't see any reason why breezy is compiling things for i386 hurd ;)
<Kamion> fabbione: done (in a slightly different way, but close enough)
<Kamion> \sh: er ... it's not?
<Kamion> libqssl-dev |      2.0-1 | breezy/universe | amd64, i386, powerpc
<fabbione> Kamion: i am sure that it is good enough with your magic touhc :)
<Kamion> fabbione: (I poked the sparc-usb include file a bit instead)
<\sh> kamion: recompiled it for cxx trans
<fabbione> Kamion: sure.. it is enough that di doesn't try to pull in usb-modules
<fabbione> Kamion: it will be there sometimes with 2.6.12
<fabbione> but i am not going to get crazy for 2.6.10
<\sh> think I hit the button for the http://en.wikipedia.org/wiki/Infinite_Improbability_Drive
<Kamion> \sh: oh, you mean you just built it and got that? It probably checks DEB_*_GNU_SYSTEM and gets it wrong; dpkg's behaviour changed.
<\sh> Kamion: but how can I fix it??? 
<Kamion>     - dpkg-architecture outputs (mostly) correct GNU system names now,
<Kamion>       in particular this means that it will output "linux-gnu" instead
<Kamion>       of "linux".  You should use the new _ARCH_OS variables instead.
<seb128> mvo: thanks for taking the gksu bugs :)
<Kamion> although I don't see anything like that in qssl's debian/rules ...
<doko> $ dpkg-architecture | grep GNU_TYPE DEB_BUILD_GNU_TYPE=i386-linux-gnu
<doko> DEB_HOST_GNU_TYPE=i386-gnu
<doko> Keybuk: ^^^
<Kamion> doko: you've only set the environment variable for grep there, not for dpkg-architecture
<doko> wrong paste ...
<doko> $ dpkg-architecture | grep GNU_TYPE
<doko> DEB_BUILD_GNU_TYPE=i386-linux-gnu
<\sh> DEB_BUILD_GNU_TYPE=i386-linux-gnu
<\sh> DEB_HOST_GNU_TYPE=i386-gnu
<Kamion> \sh: try 'dpkg-architecture -qDEB_HOST_ARCH'?
<\sh> hmm
<\sh> hurd-i386 *g*
<Kamion> d'oh
<\sh> strange
<\sh> that's new
<Kamion> KEYBUK
<doko> scotttt !!!
<mvo> seb128: didn't you just assigned them to me ;) ?
<seb128> michael.vogt@ubuntu.com changed:
<seb128>            What    |Removed                     |Added
<seb128> ----------------------------------------------------------------------------
<seb128>          AssignedTo|debzilla@ubuntu.com         |michael.vogt@ubuntu.com
<seb128> nop
<seb128> you did :)
<\sh> Kamion: any idea how to fix it? or what caused thi problem?
<mvo> d'oh :)
<Kamion> \sh: be patient, I'm investigating
<\sh> Kamion: ok ;)
<\sh> I should rewatch the new hitchhickers guide, at least I can examine most of the bugs ;)
<Kamion> I imagine doko is investigating too
<doko> curently looking ...
<\sh> writing message to the.register and slashdot: "Hurd is not dead! Hurd is living and hurting us badly" ,-)
<Kamion> downgrading dpkg is painful, have to mess about with md5sum.textutils by hand and then use --force-overwrite-diverted
<Lathiat> downgrading dpkg or downgrading with dpkg?
<Kamion> the former
<daniels> downgrading dpkg
<Burgundavia> daniels, ping
<daniels> pong
<Kamion> Leaving `local diversion of /usr/bin/md5sum.textutils to /usr/bin/md5sum'
* Kamion points and laughs, scott doesn't know how to use dpkg-divert
<Burgundavia> daniels,  have you seen this? http://www.ubuntuforums.org/showthread.php?t=35143
* Burgundavia wishes forum people would just file bug reports
<daniels> Kamion: does anyone?
<jsgotangco> OT: who's into Gundam here, i'll give you a good blog link real life gundam heh
<daniels> Burgundavia: yes.  this is why people shouldn't use breezy unless they know what they're doing.
<Burgundavia> daniels, ok, figured I would give you the bug report via the forum, hope it is useful
<daniels> yeah, already caught it earlier, just need to finally get the transition done with so I can upload xfonts-core
<daniels> thanks though
<Kamion> \sh: is $CC set to anything?
<doko> Kamion: which gcc do you use?
<Kamion> doko: it's not me who has the problem
<Kamion> ah, but yes, it's the change in 'gcc -dumpmachine' output that did it
<Kamion> in 4.0
<elmo> ALL YOUR PKGS BELONG TO KATIE, KTHXBYE
<Lathiat> hai2u elmo 
<Kamion> ah, ordering ostable is probably sufficient
<Kamion> better
<Kamion> doko,\sh: try http://people.ubuntu.com/~cjwatson/tmp/dpkg-architecture.patch
<elmo> (err, sorry, that was meant to be: katie's been disabled till this dpkg thing is resolved )
<pitti> trulux: here?
<doko> kamion: better
<doko> $ dpkg-architecture DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux
<doko> DEB_BUILD_ARCH_CPU=i386
<doko> DEB_BUILD_GNU_CPU=i386
<doko> DEB_BUILD_GNU_SYSTEM=linux-gnu
<doko> DEB_BUILD_GNU_TYPE=i386-linux-gnu
<doko> DEB_HOST_ARCH=i386
<doko> DEB_HOST_ARCH_OS=linux
<doko> DEB_HOST_ARCH_CPU=i386
<doko> DEB_HOST_GNU_CPU=i386
<doko> DEB_HOST_GNU_SYSTEM=linux-gnu
<doko> DEB_HOST_GNU_TYPE=i386-linux-gnu
<doko> but gcc already picked up the -gnu, so I need to rebuild it
<Kamion> gcc picked it up? I thought dpkg-architecture got it from gcc
<Kamion> yay circularity
<Kamion> ostable's going to need reordering for kfreebsd and knetbsd too (not that Ubuntu cares)
<fabbione> is it only i386 affected?
<Kamion> ok, I can't get to scott's arch archive, but I'll upload dpkg with that fix and talk to him later
<Kamion> fabbione: no, powerpc too at least
<Kamion> probably all arches
<doko> changelog entry: "Revert Keybuk's strong committment to the Hurd" ;-)
<Kamion> # dpkg-architecture -qDEB_HOST_ARCH
<Kamion> hurd-powerpc
<Lathiat> doko: haha
<doko> Kamion: really?
<fabbione> it looks like that everything that has been uploaded after build-essential, is affected
<Kamion> yes, 'gcc -dumpmachine' says powerpc-linux-gnu
<Kamion> and dpkg-architecture matches that on /gnu[^-] */ because that happens to be the first thing it picks from the %ostable_re hash
<Kamion> my patch makes it go through ostable in order so that it always tries /linux[^-] *(-gnu.*)?/ first
<fabbione> that is around 31/32 pkgs
<fabbione> probably less
<Kamion> have they all built hurd-* binaries?
<fabbione> Kamion: i am checking for host architecture in the build logs
<fabbione> but we might as well reupload everything after dpkg to be 100% safe
<fabbione> it's only 60 pkgs
<fabbione> sorry.. less than that
<Kamion> I think it's only packages uploaded after the gcc-4.0 upload after dpkg 1.13.4
<Kamion> which was 4.0.0-7ubuntu4 I think
<fabbione> Kamion: no, it's before that
<fabbione> using -changes timeline:
<Kamion> that's odd, because it only breaks when you upgrade to that gcc as far as I can work out
<fabbione> build-essential 11.0ubuntu1 is ok (on i386 at least)
<fabbione> java-gcj-compat is not
<Kamion> since gcc versions before that said "i486-linux" etc. and didn't match /gnu[^-] */
<fabbione> and it was uploaded immediatly after
<Kamion> fabbione: ok, gcc 4.0.0-7ubuntu3 then - but that was uploaded before the gcc-defaults link was switched
<Kamion> fabbione: so yeah, after gcc-defaults/build-essential
<fabbione> Kamion: mind to /j u-toolchain so we can keep all in one chan :)
<mvo> hey dholbach 
<dholbach> hellas mvo :-)
<Burgundavia> mvo, thanks for all the great work in synaptic, btw
<pitti> Moin dholbach 
<dholbach> hi pitti :-)
<mvo> Burgundavia: thanks, I'm working through your buglist :)
<dholbach> hey jsgotangco :-)
<Burgundavia> mvo, I thinking about more to add, don;t worrry
<dholbach> Burgundavia: fix some universe packages instead ;-)
<jsgotangco> dholbach, hey
<jsgotangco> dholbach, got a minute?
<dholbach> jsgotangco: yes
<Burgundavia> dholbach, call me stupid, but I can't make heads or tails of deb packaging, in terms of adding .desktop files. I eagerly await tsengs intro
* mvo runs
<dholbach> Burgundavia: once i'm getting a bit out of work, i'll give you a hand
<chmj> bugzilla won't take my bug entry 
<seb128> whoever is putting .desktop files, try to get that upstream or from Debian too
<seb128> or that's going to be a lot of merge work
<Burgundavia> seb128, will do
<dholbach> hellas seb128 
<seb128> daniel :)
<dholbach> seb128: hrmbl, accent on your name doesnt work in irssi 
<dholbach> have to wait until x works again :-)
<seb128> you have broken your box?
<dholbach> no... X has :-)
<seb128> I've not upgraded yet
<seb128> no hurry :p
<dholbach> seb128: right... take your time :-)
<dholbach> i will do the laundry in the meantime
<seb128> dholbach: I'm breaking GNOME atm
<dholbach> ROCK! :-)
<seb128> so you have some fun after fixing xorg
<daniels> xorg is already fixed
<dholbach> i just wait for the archive to receive the good news :-)
<doko> gcc-4.0 (4.0.0-7ubuntu6) breezy; urgency=low
<doko>   * Don't trust dpkg-architecture, it hurds ...
<jsgotangco> wohooo
<dholbach> :-)
<seb128> jamesh: around?
<jamesh> seb128: yeah
<seb128> jamesh: any opinion on https://bugzilla.ubuntu.com/show_bug.cgi?id=10289 ?
* jamesh looks
<Burgundavia> mvo, fell free to mark my bugs as pure crack
<seb128> jamesh: tagtool has a such breakage (there a malone bug about it) and that's only a rebuild of the debian package which works fine if you want an example (not sure if that's this issue but seems to be)
<jamesh> seb128: I'll add a comment
<seb128> thanks
<sjmorgan> hi, can somebody help me with a problem that could quite possible be a serious bug?
<sjmorgan> i'd like it confirmed first before i file it as i'm not 100% sure
<pitti> sjmorgan: just describe the bug
<sjmorgan> i can't boot windows anymore
<sjmorgan> the partition is there and flagged as ntfs under cfdisk
<sjmorgan> but i can't boot off it
<sjmorgan> the best i can get is grub freezes and i have to reboot the machine
<sjmorgan> i've tried booting off the windows install cd and doing fixboot c: which made no difference
<sjmorgan> it mounts fine under linux
<sjmorgan> the partition, that is
<sjmorgan> it's also marked as bootable under cfdisk
<pitti> sjmorgan: does grub show any error message?
<sjmorgan> nope
<pitti> did that happen only recently and worked before? or did you just install Ubuntu the first time and it immediately killed the win boot?
<thom> check the drive is still marked as LBA in the bios?
<sjmorgan> i don't know if it's meant to "understand" ntfs but when i do tab completion in it to get a list of partitions, the windows one appears as an "unkown" type
<sjmorgan> it only happened recently and worked before
<pitti> sjmorgan: tab completion in grub?
<sjmorgan> you can tab complete a list of partitions
<sjmorgan> when specifying the root
<sjmorgan> it gives you a list of drives and then partitions on the one you select if you hit tab
<sjmorgan> thom: but it's using the same settings it's always used
<sjmorgan> the defaults
<sjmorgan> i've never had a problem like this before or had to mess with bios hard drive settings
<sjmorgan> also, the menu.lst uses "root" but i tried "rootnerify" which makes no difference
<sjmorgan> rootnoverify even
<pitti> sjmorgan: seriously, I have no idea. Could you please open a bug? Maybe somebody with more knowledge (and an actually installed Windows) knows better
<Kamion> there are a few bugs along those lines; I can basically do nothing with them
<Kamion> unfortunately
<sjmorgan> why not?
<Kamion> but search through the installer bugs and you'll probably find some information
<Kamion> because I know sod-all about booting Windows?
<sjmorgan> do you maintain the grub package?
<Kamion> yes
<Kamion> well, sort of
<Kamion> bugs tend to end up with me because installer =~ booting
<sjmorgan> seems like something that should be pretty high up a list of things somebody maintaining the grub package should know
<Kamion> as I say though, I think there's some useful information in the bugs that have been filed; you might want to take a look through them to see if they're helpful
<sjmorgan> ok
<Kamion> dude, the installer is my prioriuty
<Kamion> I only end up getting grub bugs 'cos nobody else wants them :)
<sjmorgan> heheh ok
<sjmorgan> i seriously wouldn't be suprised if it was windows that was throwing a hissy fit
<sjmorgan> just after grub hands over the reigns to the windows bootloader
<Kamion> it often is, but it's also often something finicky to do with partition table layout
<Kamion> but you said you hadn't changed that recently ...
<Kamion> is Windows on a second hard disk or anything?
<sjmorgan> i made a lot of hd changes a month or so ago, but i used partition magic to move stuff around which obviously means i was capable of booting windows
<sjmorgan> actually
<sjmorgan> good point!
<sjmorgan> not strictly, but it's on my primary sata drive
<sjmorgan> which could be interpreted as a second drive
<Kamion> there are various 'map' runes you can use ...
<sjmorgan> and grub has it flagges as hd2, which would back that up
<Kamion> try:
<Kamion> map (hd0) (hd2)
<Kamion> map (hd2) (hd0)
<Kamion> in the Windows booting stanza
<sjmorgan> cool i'll do that now
<Kamion> may not work, but worth a try
<sjmorgan> does it matter where it is in the list of commands for that section?
<Kamion> I'm not sure. I'd put it first I think.
<sjmorgan> k
<Kamion> and refer to the disk as (hd0) thereafter
<sjmorgan> i was just gonna ask that hehe
<sjmorgan> ok cool
<sjmorgan> should "root" be "rootnoverify" btw?
<sjmorgan> it is in the example menu.lst
<sjmorgan> or doesn't it really matter
<Kamion> uh, see the grub documentation for that command, it's a bit complicated
<Kamion> try with 'root' first
<jsgotangco> bye everyone
<sjmorgan> ok i'll go and try that now and report back whether it works
<sjmorgan> brb
<Kamion> rootnoverify is for when GRUB can't read the area of the disk containing the OS ... oh, he left
<thom> "project looking glass was distinctly absent from shuttleworth's talk"
<daniels> project looking glass is distinctly absent from reality
<thom> exactly
<Kamion> sjmorgan: 11:22 < Kamion> rootnoverify is for when GRUB can't read the area of the disk containing the OS ... oh, he left
<Burgundavia> thom, where is that quote from?
<sjmorgan> Kamion: thanks man, it worked
<Kamion> sjmorgan: yay!
<sjmorgan> although note: you don't change the old root hd*
<Kamion> sjmorgan: I wonder how it worked in the first place
<Kamion> sjmorgan: hmm?
<sjmorgan> it must dynamically map it to the new one when you boot
<Kamion> oh, you left it at hd2?
<sjmorgan> so say hd2 didn't work, you keep it as is and just add the map stuff
<Kamion> ok
<thom> Burgundavia: one of the sites linked on sounder this morning
<sjmorgan> well i changed it which didn't work so i changed it back and it did
<sjmorgan> but yeah apart from that it worked great
<sjmorgan> stupid windows
<Kamion> if I could figure out how to make grub-installer do that automatically, I would
<Kamion> actually ...
<Kamion> I guess I could figure out which one is the first disk from device.map?
<Kamion> or even just do it for anything ! hd0
<Kamion> sjmorgan: could you mail your current menu.lst to cjwatson@ubuntu.com, please? I'll see if I can make the installer do the right thing
<sjmorgan> cool
<sjmorgan> yeah sure
<Kamion> thanks
<Kamion> might get rid of a class of bugs I hate receiving :-)
<sjmorgan> hehehe
<sjmorgan> you could always make the installer delete all windows partitions and save everyone a lot of trouble
<pitti_> sjmorgan: then it breaks in a well defined way at least :-)
<sjmorgan> hahah
* Lathiat grins
<Kamion> ok, well, untested fix in my d-i working tree now, at least
<sjmorgan> excellent
<Lathiat> insert mr burns styles
<sjmorgan> eeeeexcellent smithers
<pitti_> elmo: please sync squid
<sjmorgan> gotta go, thanks a lot for your help guys
<Treenaks> Where does the installer get its hostname suggestion from?
<Lathiat> Treenaks: dhcp | "ubuntu"
<Treenaks> Lathiat: ah, dhcp :)
<Treenaks> Lathiat: cool
* thom sighs and boots i386
<Kamion> Treenaks: dhcp | dns | "ubuntu" actually
<tsume> thom: have the x86 blues? ;)
<Kamion> it does a reverse lookup on the IP address it's got (often from DHCP)
<Treenaks> Kamion: that's even cooler
<Treenaks> Kamion: especially if it works on ipv6 too (or would that be a good "get to know d-i" project?)
<Kamion> netcfg doesn't support IPv6
<Kamion> feel free to make it :)
<Kamion> netcfg is a rather strange and awkward bit of d-i, but it would be one interesting place to start, yes
<Lathiat> hmm that would be usefull
<Treenaks> Lathiat: autoconf | dhcpv6 | give up ?
<Lathiat> dhcpv6 doesnt exist *cough*
<Lathiat> autoconf | manual setup
<Lathiat> | give up
<Lathiat> imho
<Treenaks> Lathiat: that'd be better
<Treenaks> Lathiat: s/better/easier
<Lathiat> and then we can integrate avahi into d-i to get a dns server! :) heh.
<Lathiat> speaking of that i should do some hacking
<pitti> sjoerd: ping
<doko> Kamion: gcc -dumpmachine on powerpc did have the -gnu thing as well?
<Kamion> doko: yes
<tja> kamion: does grub-installer support seeding encrypted password nowadays?
<Kamion> tja: no
<tja> ok
<Kamion> in fact AFAIK it doesn't support preseeding a password at all
<tja> little bit of sed-magic in the late_command does the same, but anyway ;)
<Lathiat> daniels: http://bur.st/~lathiat/ubuntu-dbus-doc-suggests.patch
<Kamion> ooh, debconf progress bars *nearly* working ...
<tja> kamion: true, it doesn't support that
<tja> kamion: what is the best way to hack on d-i (or u-i)?
<tja> preseeding the grub-password is one thing, then there's the pivot_root-stuff I mailed you about some time ago
<tja> ..and those are features that I'd look into ;)
<Kamion> tja: how d'you mean? the individual source packages are in the archive
<tja> debian-installer and grub?
<Kamion> grub-installer in this case
<Kamion> d-i is modular
<tja> yes
<tja> ok
<Kamion> you need to know which piece you're going to work on. if you don't know, it's generally easier to start with the upstream tree from svn (http://www.debian.org/devel/debian-installer/svn)
<Riddell> elmo: upload to hoary-security "Rejected: kdelibs is a frozen package for the CXX transition."  will that sort itself out?
<tja> kamion: checkout done
<tja> I'll poke around and see what happens..
<dholbach> hey
<ogra_d> hi dholbach 
<dholbach> where's the new x? :-(
<Lathiat> maybe it ftbfs? :\
<dholbach> no
<ogra_d> who needs X anyway
<Lathiat> haha
<thom> by the way, american keyboards suck. that is all.#
<bob2> yeah
<bob2> htf do you type "logical not" on them?
<Lathiat> whats an 'american keyboard' ot significant?
<Treenaks> bob2: why would you want to type logical not?
<bob2> I don't know, ask whoever designed UK keyboards.
<Lathiat> whats a logical not?
<Lathiat> ! ?
<pitti> 
<Lathiat> wtf is that that cmes up as a unicodey block for me
<Treenaks> Dutch keyboards tend to be nicer.. they have "@" where "`" is on US keyboards
<pitti> Lathiat: /charset UTF-8?
<Treenaks> and / where \ is, and no \
<Lathiat> pitti: this is supposed to be utf-8
<Treenaks> Lathiat: paste it in mozilla then
<pitti> Lathiat: do you see umlauts? 
<Lathiat> irssi, screen and gnome-terminal all have utf8 on, humm
<Lathiat> and no
<pitti> Lathiat: if '' does not look like an 'a' with two dots on top, then your IRC client is screwed
<Lathiat> it used to work
<Treenaks> http://www.datacal.com/products/dutch-layout.htm
<Lathiat> wonder shy its stopped working
<bob2> Treenaks: how do windows users type paths?
<Treenaks> bob2: why do you think everyone uses US keyboards here?
<bob2> haha
<Lathiat> pizzathief: how bout now
<Lathiat> err
<Lathiat> pitti: 
<pitti> ?
<trulux> pitti: yup, back from school
<trulux> what's up fellows?
<pitti> trulux: hey
<Lathiat> pitti: type a unicodey character?
<bob2> 
<bob2> that is so weird
<Treenaks> 
<pitti> trulux: I tested the new kernel; works fine, but the sysctls should be on by default (which they aren't)
<bob2> in my entry window it looks like gibberish, but in the main irc window it's fine
<pitti> Lathiat:    ^
<Treenaks> bob2: irssi? :)
<Lathiat> blah still broken.
<pitti> Lathiat: and  is the logical not
<bob2> Treenaks: jah
<trulux> pitti: turned on by default? OK, will do later
<pitti> trulux: yes, otherwise it doesn't make much sense
<pitti> trulux: ideally the default is set with the kernel configuration
<trulux> I'm going to design a beige-like box for testing my home phone line, the cat was playing on the wires
<pitti> trulux: i. e. if I say "Y" in kconfig, I want to have it enabled by default
<pitti> trulux: otherwise we had to change all grub menus out there
<pitti> trulux: otherwise it works great!
<mvirkkil> Has anyone looked in to phonegaim as an alternative to Shtoom for breezy?
<Lathiat> mvirkkil: phonegaim?
<mvirkkil> Lathiat: Linspire put voip technology in to gaim.
* Lathiat google
<mvirkkil> Lathiat: http://www.phonegaim.com/
<Lathiat> is it gpl?
<mvirkkil> Lathiat: Yes.
<ogra_d> mvirkkil, put it on UniverseCandidates
<mvirkkil> Lathiat: Since it's integrated in to gaim, it might be preferred over another standalone app.
<trulux> pitti: well,I can set CONFIG_SECURITY_KRSEC_FEATURES_ENABLED to bool , and a static int into code, so, it enables the featurs on __init call
<koke> mvirkkil: it's a bit hidden but http://software.linspire.com/pool-src/p/phonegaim/
<pitti> trulux: however you do that, I only care about that it works :-)
<mvirkkil> koke: Thanks :-) I was just looking for that.
<Lathiat> well, it uses SIP
<Lathiat> so i like that part
<trulux> pitti: OK, just trying to make you understanding the underlying design
<pitti> trulux: yeah, that sounds fine
<Lathiat> if i twas another skype i would have shot them. :)
<Lathiat> the question is whether it will let you call non im users etc
<koke> Lathiat: it actually uses linphone
<trulux> skype rocks
<ogra_d> yep
<ogra_d> and its a native package *shudder*
<Lathiat> trulux: but its protocol is propietry, which sucks.
<Lathiat> theres a reason for it, but theres no reason they couldnt have adapted around that.
<Lathiat> i'd also kcare less if theyd provide a si pgateway
<mvirkkil> ogra_d: 'native package'?
<ogra> yep, no diff.gz
<dholbach> a new tarball for every 'debian' revision
<mvirkkil> ogra: Oh. Haven't heard the expression "native package" used that way before.
<thom> mvirkkil: "debian native package" it means; ie a package built specifically for debian from the ground up, rather than using source from elsewhere
<ogra_d> which is a PITA if you are not the upstream of this package and need to introduce changes
<dholbach> thom: those _should_ be the only cases
<thom> dholbach: yes
* dholbach found 48Mb native packages :-)
<mvirkkil> Oh, and it seems it branched off of Gaim 10/19/2004
<mvirkkil> Someone has made 'debian' packages http://people.debian.org/~smimram/ (probably by running make)
<ogra> nope
<ogra> he actually switched the native package to a cdbs package
<mvirkkil> I also found this: http://sourceforge.net/projects/sipdevel/
<ogra> uuuh, and patched Makefile.in instead of .am
<Kamion> it's common to produce a native package accidentally by forgetting to rename the upstream tarball to PACKAGE_VERSION.orig.tar.gz
<Kamion> PACKAGE_UPSTREAMVERSION that is
<Baby> it's quite usual to rename it to PACKAGE-VERSION.orig.tar.gz instead.. i've seen that in some lists
<tsume> what pacakge is fixed fonts for Xorg located in? Breezy is broken :)
<tsume> *package
* ogra suspects linspire to only produce native packages
<tsume> I looked at the log, and it said it couldn't find the fixed fonts
<tsume> does someone have a fix yet?
<ogra> tsume, just wait...
<dholbach> tsume: same here, i'm investigating and seem to hit the question: is /usr/X11R6/lib/X11/fonts/100dpi/* really meant to be?
<tsume> hmm
* tsume looks on his lappy
<dholbach> because it's not what i have in xorg.conf
<ogra> dholbach, we are going away from /usr/X11R6
<ogra> so that might be your prob
<tsume> orga: why?
<ogra> because this paths are insane....
<tsume> orga: X apps belong in /usr/X11R6
<mvirkkil> ogra: Someone might simply contact them and ask :-)
<ogra> mvirkkil, i'm         notafter this :)
<tsume> orga: no, it seperates X apps from command line apps
<ogra> oops
<dholbach> ogra: the fonts ARE in there (after the upgrade) and it's not the place that's mentioned in xorg.conf
<thom> tsume: no, they don't. there's no reason to do this
<tsume> thom: I disagree, seperation by catagory is a good thing(tm)
<ogra> dholbach, then they are in the wrong place.... what does xorg.conf show you ?
<tsume> thom: its difficult when you have 3000+ files in /usr/lib
<dholbach> ogra: /usr/share/X11/fonts/...
<tsume> seperation helps clear up sme of the "crap"
<mvirkkil> thom: Are you the voip boss for breezy?
<ogra> tsume, 90% of X app (gnome/KDE other stuff)  is in /usr/bin since ages
<thom> tsume: no, package management clears up the crap; besides, the seperation hasn't existed fully for a *long* time
<thom> mvirkkil: yes
<ogra> so it just doesnt make sense to have a special dir for xbase-clients
<dholbach> mvirkkil: thom rocks! :-)
<ogra> yeah
<thom> hahah
<mvirkkil> thom: :) Are you interested in phonegaim?
<mvirkkil> thom: Or is Shtoom the way to go?
<ogra> shtoom !!
<ogra> :)
<ogra> if its ever readsy
<mvirkkil> ogra: You just say that because you like the name ;-)
<ogra> mvirkkil, nope, i like the author ;)
<ogra> mvirkkil, and his ideas
<mvirkkil> ogra: And shouting shtoom every now and than, right?
<dholbach> tsume: changing the font directories works
<dholbach> brb
<ogra> mvirkkil, yeah, that too
<tsume> mmmm
<mvirkkil> :P
<mvirkkil> How about integrating contact information from gaim and shtoom all in to evolutions contact manager?
<mvirkkil> Worth a bounty proposal perhaps.
<ogra> and make it searchable by beagle ;)
<dholbach> re
<tsume> dholbach: you are the mon :)
<mvirkkil> I'll put it in to the wiki, so that it can drown in the noise.
* mjg59 continues to be amazed at just how long it takes to build kernels
<ogra> mjg59, dont build them on laptops ;-P
<dholbach> tsume: works for you again?
<ogra> (except you cluster them ;) )
<tsume> dholbach: yes
<dholbach> tsume: ROCK!
<mjg59> ogra: My laptops are (by far) the fastest machines I have...
<zul> mjg59: you arent building all of it are you?
<tsume> dholbach: should make a quick-fix script for the people who need thier machine running
<tsume> mjg59: 1.7 P-M 512MB :)
<tsume> mjg59: laptop power :)
<ogra> tsume, be sure it will change again during the next 24h, so a script wont help a lot
<mjg59> zul: Full 386 build
<zul> mjg59: ah
<mjg59> tsume: Yeah, that's what I'm using. It's still slow.
<mjg59> Ooh, there we go
<tsume> mjg59: its really fast here
<mjg59> It's on to building the source package now
<ogra> mjg59, cluster them ;)
<mjg59> ogra: Not a bad idea...
<tsume> mjg59: even my nvidia 5200 Go card.. I get 2230 fps
<thom> it's the kernel-patch package that really hurts
<mjg59> tsume: Oh, it's fast, but building stock kernel takes a long time
<zul> takes me about 45 minutes for 686
<mjg59> There's a *lot* of drivers
<tsume> mjg59: which lappie you have?
<mjg59> tsume: This is an HP6220
<ogra> mjg59, iirc there once was a beowulf koppix cd you just have to boot from  it and it attaches itself to the master you set up before on another knoppix
<tsume> are most of the drivers built in kernel?
<tsume> or are modules?
<zul> mdoules
<mjg59> tsume: No, mostly modules. 
<mjg59> Yay
<mjg59> "Building package linux-image-2.6.12-1-386"
<mjg59> Oh bugger off kernel-wedge
<tsume> I want 2.6.12.... :(
* tsume wants a kernel not gcc3 built :)
<pitti> sjoerd: here? (it's urgent)
<ogra> http://bofh.be/clusterknoppix/
<tsume> brb
<tsume> cant stand bosses computer, it runs windows
<tsume> heh, microsoft's patent recently is stupid
<chiefofthejojos> which one?
<tsume> like its going to stop me from using the features or placing them in my programs anyway :)
<tsume> chiefofthejojos: read troll.
<chiefofthejojos> sorry, I just got here
<tsume> chiefofthejojos: they've patented the features in email clients, like click to reply, copy email to clipboard, etc
<pitti> tsume: seriously????
<tsume> pitti: thats what the patent abstract says
<tsume> pitti: I never follow patents anyway, only the GPL :)
<chiefofthejojos> omg that's stupid
<pitti> tsume: and they got that approved?
<tsume> pitti: the troll dot story says so..
<trulux> pitti: patch finished
<pitti> trulux: nice, then I can build another version
<pitti> trulux: still against 2.6.11?
<trulux> pitti: I was about to do it in the hard way (using a helper function), but ifdef's are dirty but work fine
<tsume> patents can be revoked if its for the good of everybody
<trulux> pitti: yep, had no time to stack 2.6.12
<trulux> hand't time, sorry
<pitti> trulux: no worries
<pitti> trulux: I port it, that's easy
<pitti> trulux: where can I get it?
<trulux> pitti: dcc
<pitti> trulux: might not work, just try
<dholbach> tsume: do the normal ctrl-<something> short cuts work for you with the new xserver?
<tsume> dholbach: ctrl-alt-f1 works fine here
<tsume> http://yro.slashdot.org/yro/05/05/18/1222247.shtml?tid=155&tid=109&tid=95&tid=17
<trulux> pitti: seems not working
<dholbach> tsume: and stuff like ctrl-w (for close), ctrl-e (in evolution for expunge) or ctrl-a in gaim for accounts?
<trulux> pitti: .... I can't send it by email right now
<pitti> trulux: I didn't get anything... put it on a webpage?
<dholbach> tsume: every ctrl-something does the same (per application)
<trulux> pitti: just tuxedo-es.org, still recovering
<tsume> dholbach: ctrl-c,       ctrl-v work for me too
<dholbach> hrmhrmhrmhrmhrm
<tsume> ctrl-q for exiting kde apps, and ctrl-w for closing the ff tabs ;)
<tsume> dholbach: what is it doing on you machines?
<tsume> grief.. I swear AA is going to make me go blind
<tsume> sometimes I really dislike AA
<dholbach> ctrl-w (which would close a tab) fires up the connect-to-server dialog in xchat
<dholbach> ctrl-a (for accounts) behaves like ctrl-b in gaim
<tsume> dholbach: ctrl-w in xchat works here
<trulux> pitti: mail?
<pitti> trulux: martin@piware.de
<tsume> ..
<tsume> what in the world are wrong with my fonts, theres a shadow of grey beneath them
<tsume> makes them look all fuzzy
<thom> guys, this is thoroughly off topic for ubuntu-devel
<trulux> pitti: sent to ubuntu.com
<mvo> Riddell: does kde depend on libhal? or is it planed to depend on it in the future? (for media change events and stuff like that)
<ogra> mvo, probably for dbus ?
<pitti> trulux: didn't work. Did you use martin.pitt@ubuntu.com?
<pitti> trulux: ah, now I got it
<ogra> pitti, btw, ogra_d is ogra at the desktop :)
<ogra> you asked ...
<pitti> ah :-)
<Riddell> mvo: kdebase-kio-plugins depends libhal-storage0, libhal0
<pitti> Riddell: uh, btw, could you port that to the new dbus and hal API?
<mjg59> Oh cock
* mjg59 watches the entire kernel get rebuilt after adding some acpi patches
<trulux> pitti: bbl, class
<pitti> trulux: I rebuild a kernel and test it
<Riddell> pitti: already have done in breezy 
<pitti> cool
<Riddell> not well tested, suspect it doesn't work, will look again after c++ transition
<^rob^> hey ogra: have you played around with OS X's disk utility and volume selector widget/
* tsume thinks he'll make his own damn portable mail client :P
<ogra> ^rob^, nope, i have no OS X around....
<^rob^> ogra: ahh, I'll lend you a VNC session for a few days if you'd like ;)
<^rob^> although unfotunately I don't have an IPKVM so you couldn't step through the install
<ogra> ^rob^, ah, you mean for the GraphicalPartitioningTool ?
<^rob^> http://s87840517.onlinehome.us/pearpc.html has some good screenshots
<^rob^> also for Experss
<^rob^> err Express
<ogra> yep, thats what GraphicalPartitioningTool is for
<^rob^> In OS X you don't have to see all the extra options if you have a suitable volume you are willing to overwrite
* ogra sees the OS X installer for the first time....
<Dilago_> hi for all
<ogra> that thing is cool,  but asks way to many questions...
<Mithrandir> hi ogra
<^rob^> ogra: it only takes you to the disk tool selection if you don't have a suitable volum
<^rob^> actually it has a button at the bottom that says "options" i think and you click it and the disk tool opens
<^rob^> so if you have no usable options it just says No volumes found and you click the button
<ogra> hey Mithrandir 
<^rob^> ogra: it's the same disk utility that you get inside OS X too
<^rob^> although I had trouble with my 3.5 RAID
<^rob^> I wanted to try a mirroring floppy array over USB but it wouldn't work ;)
<ogra> ^rob^, its similar to what we plan to do http://udu.wiki.ubuntu.com/GraphicalPartitioningTool
<^rob^> more seriously I have a 5-drive SATA raid-enclosure + card + drives OTW
<^rob^> $1600 for TB aint a bad price!
<^rob^> gparted's gui is just nowhere as clear as OS X's
<ogra> read what we'll do ;)
<^rob^> "Device names shalt not appear unless it be in a tooltip"
<ogra> hmm, good suggestion
<dholbach> bbl
<mjg59> Grah. The upstream acpi patch still breaks various hotkey drivers.
<DanielN> has anybody tried to run qemu-launcher yet?
<luis_> seb128: let us try over here :)
<seb128> yep?
<luis_> would it be possible to package sabayon such that a sabayon client would not require xnest, etc.?
<seb128> sure
<seb128> any idea on what to split and how and why? :)
<maswan> elmo: Ok, what is really the issue is that we are hitting max memory limits for the token manager. We're working on it though.
<seb128> if there is a good reason and you have an idea on how/what to split let me know
<seb128> (away for a few min)
<luis_> seb128: well, not sure on the what/how; haven't played enough to be sure. But the why offhand is that installing sabayon installed (among other things) kernel headers onto my liveCD :) and I can imagine an admin seeing xnest as an extraneous tool that client boxes shouldn't have on it
<ogra> wohoo
<ogra> isolinux: Extremely broken BIOS detected .....
<DanielN> :>
<tsume> ogra: hey, that looks fun!
<ogra> hmm, 
<tsume> hmm I thought most linux devels were kids. I was expecting.. "Totally broken BIOS detected" :)
<ogra> nothing boots here....
<Kamion> tsume: hardly
<ogra> probably rather have kids ;)
<tsume> Kamion: I've seen some really childish people develop for linux
<tsume> Kamion: the linux userland tools developer(the maintainer of ps, etc)
<Kamion> tsume: the childish ones are noisy, hardly surprising
<seb128> luis_: yeah, I can imagine the reason, I just want to split it correctly :)
<luis_> <nod>
<seb128> luis_: and to split correctly I need to know what users are expecting from the split
<Kamion> and Andries has been around since at least the early 1990s so I rather doubt he's legally a minor any more
<Kamion> er, actually, the ps maintainer is Albert, not Andries, sorry - or at least one of the procps maintainers, the situation there is confusing
<luis_> seb128: I'm expecting that 'machine that I create policies on' and 'machine that I deploy policies on' are distinct entities which might be the same machine, but most likely are not (in any kind of large-scale deployment)
<tsume> Kamion: I don't care for his name. His replies are childish.
<seb128> luis_: and "xnest" is an issue for "clients"?
<seb128> they probably run xfree and GNOME, xnest is not a big deal imho :)
* luis_ ponders
<luis_> (given that the kernel headers were a false positive, I blame apt :)
<seb128> luis_: usually when I'm not convinced for a split I don't split and wait for bugs ... if somebody feel a bug with good arguements I split then :)
<Kamion> tsume: I was trying to work out who it was you were talking about, since the two descriptions you gave of him do not match. :-)
<Kamion> tsume: when you say things like "most linux devels", you should expect free software developers you're talking to to wonder who you're actually talking about. :-)
<ogra> especially in a linux channel ;)
<luis_> seb128: totally reasonable
<luis_> I'll play some more and get back to you
<seb128> ok, thanks
<tsume> Kamion: okay then, most of the noisy linux devels ;)
<zyga> hello
<zyga> is something going on with xorg ATM?
<Kamion> zyga: yes
<zyga> Kamion: it's being split?
<Kamion> zyga: right
* luis_ attempts to focus on finishign the liveCD with sabayon-based config
* zyga is addicted to updates
<zyga> I just broke my x stuff then, oh well - framebuffer looks good enough
<tsume> zyga: fonts are located elsewhere
<tsume> zyga: check xorg.conf, make sure you font paths are correct
<zyga> tsume: I've noticed that
<tsume> zyga: if you know the answer, why are you asking?
<zyga> tsume: what's really ugly are depentencies, I guess I'll wait
<zyga> tsume: I wanted to be sure
<zyga> dependencies even
<tja> is it 6.9 or 7.0 that's going to be in breezy?
<tja> x.org, that is..
<thom> tja: 7.0 when it's released
<tsume> Kamion: I must just have a habit of running into all the assholes of the world :)
<tja> nice
<tja> thom: it was the modular version?
<thom> yes
<zyga> thanks for information and all hard work :-)
<mkde> anyone ever used html2pot?
<doko> seb128: it looks like the build of tagtool is broken, it uses gcc for linking, not g++
<seb128> doko: weird, that's a C app ... it uses cpp libs?
<seb128> http://people.ubuntu.com/~lamont/buildLogs/t/tagtool/0.12.1-1ubuntu2/ 
<doko> id3libsomething
<seb128> builds are fine
<seb128> what is b0rked/where ?
<doko> obviously I missed to put it on the list of frozen apps. it's now linked against libstd++6, but the lib is built against 5.
<seb128> the lib??
<seb128> apt-cache showsrc tagtool
<seb128> Package: tagtool
<seb128> Binary: tagtool
<seb128> 
<seb128> what are you talking about?
<seb128> Depends: libc6 (>= 2.3.4-1), libglade2-0 (>= 1:2.5.1), libglib2.0-0 (>= 2.6.0), libgtk2.0-0 (>= 2.6.0), libogg0 (>= 1.1.2), libvorbis0a (>= 1.1.0), libvorbisfile3 (>= 1.1.0), libxml2 (>= 2.6.17
<seb128> 
<seb128> no cpp afaik
<seb128> hum, the new version has cpp, weird
<tarvid> stumbling through an ubuntu server install, it's up but what's next?
<tarvid> how do i run debconf?
<Kamion> for what?
<Kamion> debconf is a backend
<tarvid> in my mail, i get a message syaing debconf will set up the rest of the packages i want - apache - mysql - pgsql ...
<tarvid> what's the front end
<Kamion> what are you trying to do exactly?
<tarvid> set up a web server with apache2, mysql, postgresql, php
<Kamion> if you want to revisit the debconf configuration of a package that's already installed, use dpkg-reconfigure
<Kamion> but debconf is not a tool that will help you install new packages. use aptitude.
<tarvid> if there is a wizard, i want to run it, otherwise i'll just start banging apt-get
<Kamion> (#ubuntu is probably better for this, btw ...)
<Kamion> there is no wizard.
<tarvid> would be neat if there were a server section
<Kamion> http://udu.wiki.ubuntu.com/ServerInstallation is related
<mkde> i'm trying to port ubuntuguide to a pot file using html2pot so that it might be able to go into rosetta for translation. So far i'm getting a bizarre error. can anyone help? http://pastebin.ca/12056
<ogra_d> doko, seb128 seems to have objections aginst the verbiste lib renaming, do we want to discuss that before i upload ?
<carlos> mkde, that looks like a bug in the tool that prevents to use only one message instead of two when the same string appears twice
<mkde> carlos, hmm, i checked the line numbers in the html, there aren't that many lines!
<doko> seb128: what's wrong with it?
<seb128> I don't get the need to rename it, nothing use it
<seb128> out of verbiste which is the same source package
<carlos> mkde, it's not a problem with the .html file, but the tmp file used by the tool
<carlos> mkde, /tmp/html2pot.3
<mkde> carlos, oh yeah
<mkde> carlos, damn
<mkde> carlos, i'll see if I can get in touch with the person who maintains the tool, if there is one
<carlos> mkde, ok, is it based on the KDE tool or the one from GNOME?
<carlos> mkde, you can always contact the maitainers of the po2xml tool (whatever is it based on)
<pitti_> trulux: sorry, I busted the kernel build, have to start all over again
* hunger is exited to see the X-transition in breezy!
<mkde> carlos, gnome i suppose
<carlos> mkde, python or C++?
<carlos> that's the easier way to know it :-)
<mkde> carlos, i don't speak either ;) http://opensource.bureau-cornavin.com/html2pot-po2html/index.html
<seb128> carlos: what's the discussion about?
<carlos> seb128, html2pot command
<mkde> seb128, i'm trying to make a pot from the ubuntuguide html
<carlos> mkde, dude, that's not related to KDE or GNOME tools :-)
<carlos> mkde, it's done with shell!
<carlos> and awk
<mkde> yeah
<mkde> maybe i'll try another tool
<seb128> use gnome-doc-utils
<mkde> seb128, you know if it does html2pot?
<seb128> html? 
<seb128> xml yep
<mkde> is there a difference between xhtml and xml?
<seb128> xhtml should be correct xml
<sladen> mkde: XHTML is an application of XML
<sladen> mkde: bit like Ford is a make of Car
<mkde> so hopefully the tool will work...
<mkde> i tried the kde xml2pot tool that we use in the docteam, it didn't work... maybe i'll try the gnome one now ;)
<Riddell> mkde is a confusing nickname when you have a highlight set on 'kde'
<mkde> Riddell, sorry!
<Riddell> well, don't change it on my account :)
<mattheweast> Riddell, no problem, my main nick is mdke *points*
<Mithrandir> a friend of mine talked about how useful it would be if the live cd had "scan all partitions for viruses" as some kind of an option.
<Mithrandir> it doesn't really matter for Linux per se, but it could mean we'd be part of the default cd set to be handed out at computer parties and such and it would be a nice way to get people to at least boot the live cd.
<zul> but is there any good anti-virus software for linux?
<Treenaks> zul: clamav mostly
<mattheweast> seb128, i tried xml2po (i think that is the utility with gnome-doc-utils?) and it just said "segmentation fault"
<Treenaks> zul: there isn't really a need for "virus scanners" as the windows world knows them
<seb128> mattheweast: backtrace?
<mattheweast> ok
<Treenaks> zul: (because there ARE no viruses)
<seb128> mattheweast: please open a bug with the document you try to convert, the version and the backtrace
<mattheweast> seb128, is a backtrace obtained with "strace"? sorry, haven't done much of this before
<zyga> mattheweast: use gdb
<zyga> mattheweast: run the program via gdb, gdb --args ./foo-bar arg arg arg
<zyga> mattheweast: after it crashes just type: bt
<zyga> mattheweast: you may want to use tee as well 
<seb128> mattheweast: no, gdb
<mattheweast> hmm
<mattheweast> ok i'll try
<mattheweast> so something like this?
<mattheweast>  gdb --args xml2po index.html > testing.pot
<zyga> mattheweast: no
<mattheweast> :/
<zyga> mattheweast: without this redirect 
<mattheweast> the redirect is part of the command which is giving me the segfault
<zyga> mattheweast: it works okay without the redirect?
<mattheweast> i don't know
<zyga> mattheweast: anyway, you don't want to redirect gdb
<mattheweast> ok
<zyga> mattheweast: you can redirect that program but that's a bit more tricky
<mattheweast> zyga, This GDB was configured as "i386-linux"..."/usr/bin/xml2po": not in executable format: File format not recognized
<zyga> mattheweast: hmmm, is that a shell script?
<mattheweast> zyga, python
<zyga> mattheweast: argh..
<mattheweast> #!/usr/bin/python2.4
<zyga> mattheweast: then this will be more difficult ;] 
<jnc> z'oh.  good luck to you guys on a successful gcc4 migration
<zyga> mattheweast: does it use any external programs?
* jnc pets his down'd amd64 breezy box
<trulux> back from doing some lockpicking
<trulux> pitti: hey
<ogra_d> jnc, dont upgrade ;)
<mattheweast> zyga, i don't speak python, but i presume so, its pretty long
<zyga> mattheweast: you could try to fire up gdb and python
<mattheweast> zyga, i think i'll try and find an alternative program
<zyga> mattheweast: gdb --args `which python` /usr/bin/xml2po index.html
<mattheweast> zyga, ok will try that
<mattheweast> zyga, it seems better
<mattheweast> its taken me to a gdb prompt
<zyga> mattheweast: type: run
<mattheweast> ok cool its faulted
<mattheweast> bt?
<jnc> ogra_d: d'oh
<lu|away> seb128: BTW, the current packages + liveCD seem to work well, for minimal testcase
<zyga> mattheweast: yes
<mattheweast> zyga, how can i save the backtrace in a file do you know?
<jnc> ogra_d: it was all well and good until i thought "hey, let's like, reboot y'know and see what happens"
<lu|away> seb128: so thanks
<jnc> heh
<zyga> mattheweast: I use tee on the whole thing ;-)
<lu|away> seb128: will test more soon
<mattheweast> zyga, tee being?
<zyga> mattheweast: if it's not too long just select and paste
<ogra_d> jnc, lol
<mattheweast> zyga, k
<zyga> mattheweast: gdb --args .... | tee  foo.txt
<mattheweast> zyga, its not long at all
<zyga> mattheweast: then you have a backtrace, congratulations :-)
<mattheweast> zyga, thanks very much indeed
<zyga> mattheweast: you are welcome :)
<mattheweast> now to file this bug
<jnc> ogra_d: best guess to when X becomes usable again, less or more than a week?
<ogra_d> less
* jnc :)
<mattheweast> seb128, am i filing the html2po bug in gnome.b.o?
<mattheweast> not ubuntu.b.c right?
<Treenaks> b?
<mattheweast> i mean bugzilla.ubuntu.com
<Treenaks> seb128: "Thanks to the magical seb, it has now been packaged," [luis villa about sabayon, on his blog] 
<mattheweast> is that xchat-gnome?
<mattheweast> seb128, ok i filed it in ubuntu bugzilla at #10935
<seb128> mkde: thanks
<seb128> Treenaks: ah ah
<mkde> seb128, tY
* mvo is away for a bit
<elvirolo> hi all
<elvirolo> i'm currently using breezy (i386) and the X server is not starting up ... startx says it "could not open default font 'fixed'"
<elvirolo> could anyone help me?
<wasabi_> Did you install the server version?
<wasabi_> Err... how did you install it?
<wasabi_> You are missing x-window-system-core
<elvirolo> well, i've just installed it actually
<zyga> elvirolo: x server is being updated ATM, you're out of luck
<wasabi_> ahh.
<zyga> elvirolo: It's going to take some time to finish the transition
<elvirolo> zyga: oh, thanks :)
<wasabi_> What's happening to it?
<zyga> elvirolo: I'd use stable version for a moment if I were you
<zyga> wasabi_: It's being split 
<wasabi_> thought so.
* wasabi_ claps
<elvirolo> zyga: yeah, i've got a hoary installation too
<elvirolo> zyga : how long is it going to take ... hours, days ?
* zyga types via ssh from a currently windowless breezy box ;-)
<zyga> elvirolo: days
<elvirolo> zyga : ok thanks :)
<zyga> elvirolo: note though that I'm just a information proxy
<elvirolo> understood :-D
<elvirolo> thanks a lot, bye!
<wasabi_> hmm. i thought udev was not supposed to allow device names to change
<jnc> it shouldn't
<wasabi_> i added a new network card and my existing one became eth1 and new one became eth0
<jnc> that's not udev
<wasabi_> so network/interfaces was inaccurate
<jnc> that's nameif
<wasabi_> ?
<jnc> /etc/mactab
<wasabi_> /dev/eth0 and /dev/eth1.
<jnc> oh?
<jnc> i've never seen that before
<ogra> wasabi_, use /etc/iftab for this
<wasabi_> iftab has my old eth0 info in it
<zyga> wasabi_: you have /dev/ethX ?
<wasabi_> iftab is now inaccurate
<mjg59> wasabi_: /dev/eth* shouldn't exist
<wasabi_> oh sure nuff, you're right.
<mjg59> Not if you're running Linux, at least
<wasabi_> I had always thought they did. ;)
<wasabi_> anyways, for whatever reason, this ifwhatever system didn't work. ;)
<mjg59> iftab contains the MAC address and the interface name
<zyga> wasabi_: I thought the opposite ;-)
<mjg59> renameif should then ensure that the interfaces match that
<wasabi_> admin@vm:~$ cat /etc/iftab
<wasabi_> # This file assigns persistent names to network interfaces.  See iftab(5).
<wasabi_> eth0 mac 00:e0:4c:b5:31:c3
<wasabi_> admin@vm:~$ ifconfig eth0 | grep HW
<wasabi_> eth0      Link encap:Ethernet  HWaddr 00:0E:0C:76:39:6A
<mjg59> wasabi_: Run ifrename?
<wasabi_> interface busy....
<wasabi_> hmmm... isn't this supposed to run at boot?
<zyga> Warning: Interface name is `eth0' at line 2, can't be mapped reliably.
<mjg59> Yes
<zyga> why is this appearing, btw?
<wasabi_> i can only assume it didn't run at boot, and now it's in use. ;0
<zyga> it's this way for some time now
<jnc> zyga: i notice that too
<zyga> jnc: also this box has two nic's and /etc/iftab only show one 
<wasabi_> this is a hoary system btw
<jnc> zyga: have you configured the network devices using the GUI?
<zyga> one is a pci card second is built into the motherboard (also a 'pci card' of course)
<zyga> jnc: I don't remember really, is that important?
<zyga> jnc: I might have
<wasabi_> I certainly like the design of this ifrename system though. I was wondering if anything handled this.
<wasabi_> Too bad it's not working. ;)
<jnc> zyga: i found network configuration from installer to be wrong, and needed to do it myself again
<zyga> jnc: one is LAN other goes out, it's got some custom iptables stuff here and there but it works okay besides that
<wasabi_> interesting that I added this new interface and /etc/iftab didn't get it's mac
<surak> hi all
<zyga> how can I get the data from the {debian,ubuntu}-popularity-contest?
<dholbach> popcon.ubuntu.com
<dholbach> same for debian
<zyga> dholbach: thanks
<dholbach> de rien
<zyga> dholbach: french?
<zyga> hmm 
* zyga crashed google translator
<zyga> this is a very rainy and bad day indeed
<zyga> hmm does firefox understand .gz suffix and unzips automatically?
<zyga> the file has text/plain mimetype
<zyga> but is a gzipped txt in reality
* pitti bangs his head very, very hard
<zyga> dholbach: there are some 404 links there should I mail someone about it?
<pitti> I tried to build a kernel on davis' breezy dchroot for 2 hours and now I find out that the make-kpkg in there got busted today... *sigh*
<pitti> trulux: now the new kernel is finally building...
<trulux> pitti: great
<pitti> trulux: I'm building the kernel on Hoary now, I hope that this will work
* pitti -> dinner
<trulux> pitti: great
<hunger> Anyone working on the init scripts to not always return [ ok ]  yet?
<hunger> Not all do it, but powernowd and some other do and it is really annoying.
<ogra> hunger, unplug your network cable and at least two of them will say [fail] 
<ogra> ;)
<hunger> ogra: powernowd never does, I opened a bugreport for that (incl. a patch that fixes the issue here).
<ogra> great :)
<hunger> ogra: I am sure there are some more... but I can not name names right now:-(
<ogra> normally all services in main should use lsb by default....so for all main services you should see [ok/fail]  messages
<doko> ogra, seb127: libverbiste0 depends on libstdc++5, so we have to rename the package
<ogra> doko, thanks
<hunger> ogra: Right. I see [ ok ] .
<doko> oops, seb128: ^^^
<hunger> ogra: ... even though the service never started ... 
<hunger> ogra: Are there some guidelines on when to use which of the lsb-functions?
<hunger> ogra: The usage seems somewhat erratic... Is usage a log_success_msg, even though the exit code is != 0?
<wasabi_> i guess im the only one who things the use of system uids sucks.
<wasabi_> thinks
<mjg59> wasabi_: ?
<zyga> wasabi_: ?
<zyga> :-)
<wasabi_> oooh i love saying things that make people go "wtf"
<wasabi_> the uids actually chosen for the users are not established. References to them are done on the basis of user name. That's my complaint. ;0
<mjg59> Uhm.
<wasabi_> There is no established scoping for local system / remote uid allocation.
<mjg59> Oh, I see.
<mjg59> No, that's done at the application level
<wasabi_> Yeah, and, I think it sucks. ;0
<mjg59> The only case where it really makes things miserable is over NFS
<zyga> wasabi_: what I hate is different uid allocation across distros
<wasabi_> NFS is a massive case.
<mjg59> I think NFS4 makes this easier
<wasabi_> How?
<mjg59> By allowing user-level authentication
<wasabi_> NFS doesn't make the allocation standard. That's something the admin has to decide.
<wasabi_> ANd it's not just NFS. It's any large network that uses centralized 
<wasabi_> users has to go thru this.
<mjg59> No, it's not a problem with SMB
<wasabi_> I know. Because there is a scoping for NT domains. ;)
<mjg59> Well, no, it's not even that
<wasabi_> There are assigned SIDs (uids) for local system accounts and remote ranges and allocation policies.
<wasabi_> That every system on the network follows.
<mjg59> Once stuff is exported to the user rather than to the machine, you can negotiate uids
<wasabi_> And all the UI conforms.
<wasabi_> I've been thinking that a simple RFC defining masks on the 32 bit uid range would be all we'd need
<wasabi_> basically that's all ms did with their sid space
<wasabi_> It's like, just one more thing you have to think about when setting up a linux network vs a windows network
<wasabi_> Windows you just plug it in and make a new user and it's done.
<hunger> wasabi: Using which RFC mechanismn?
* wasabi_ shrugs.
<wasabi_> im just saying, as an administrator, it sucks.
<hunger> wasabi: You are right... but that there is no standard RFC mechanismn sucks just as much.
<wasabi_> We have the protocol level stuff standardized: LDAP + Kerberos... but there are a lot more considerations than just installing OpenLDAP to setting up a company's directory.
<wasabi_> It'd be neat to have the UID/Ldap/Kerberos LAYOUTS standardized, so all distros could just plug into a network and start working.
<hunger> wasabi: You could try for a freedesktop.org standard.
<hunger> wasabi: Even though that is somewhat out of scope.
<Treenaks> isn't there PosixAccount or something?
<wasabi_> Yeah.
<wasabi_> But that doesn't define uid allocation policies.
<Riddell> Kamion: no sign of knetworkconf in hoary-updates
<elmo> it won't build until the CXX transition is over
<Amaranth> that reminds me, how long do you suppose that will take?
<seb128> doko: why not just doing a rebuild?
<mdke> seb128, re that gnome-doc-utils bug, i noticed that the .html file is transitional xhtml, might that be the cause of the crash?
<doko> seb128: because it breaks partial upgrades
<seb128> in any case it should not crash
<seb128> doko: I don't get why but if you think that's needed
<seb128> that's like an app, nothing use it, we are not changing all the apps names
<doko> you're sure, that this remains the only package until we sync?
<seb128> I'm sure nothing use it yep
<seb128> but 1 package will not make a big difference
<seb128> rename it if you prefer
<doko> no, one package less to sync. I do care ;)
<doko> ogra: ^^^
<seb128> he he
<ogra> oki
<Kamion> Riddell: elmo did say yesterday it wasn't my problem any more, you know :)
<Riddell> right
<pitti> argh, new X.org's keyboard is totally b0rken
<seb128> yeah
<seb128> just 2 GNOME guys saying me than ctrl-<something> open a new epiphany window
<seb128> I've not updated yet but I'm just blaming xorg atm :)
<seb128> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=10937, feel free to comment/reassign :)
<pitti> seb128: really that bug? e. g. in gnome-terminal Alt+1 works for me, but not Alt+2, Alt+3 etc.
<pitti> seb128: in xchat, Ctrl+W behaves like Ctrl+S
<seb128> that's Alt
<seb128> Ctrl- are messed
<seb128> hum, nm
<seb128> I've not updated yet
<seb128> pitti: crevette is the guy who sent the epiphany bug
<crevette> hello 
<seb128> hey crevette 
<crevette> hey hey seb128 
<crevette> i'm using Xorg 6.8.2-14
<crevette> Do you need other informations?
<seb128> I don't think so, pitti has the issue too :)
<pitti> seb128: dholbach too
<seb128> I think everybody
<seb128> I've just not upgraded yet
<seb128> and I don't want to now :p
<luis_> hehe
<luis_> needs to be an applet, sort of like the terror alert applet
<luis_> 'breezy is green'
<crevette> the -15 ois affected by this bug too ?
<luis_> 'breezy is orange'
<luis_> 'breezy is red'
<crevette> :)
<crevette> like "plan vigipirate" for frenhies
<seb128> this week breezy is red for sure
<seb128> CXX transition :)
<crevette> arg
<crevette> nautilus is affected by this bug too
<pitti> doko: tiff is FTBFS
<pitti> doko: due to your transition patch, I suppose
<pitti> doko: since I have to add a security update, I'll care for it
<trulux> pitti: do you know how to convert an .avi video into clean mpeg2?
<pitti> trulux: mencoder?
<crevette> bye bye
<seb128> crevette: xorg is messed, no need to start counting how many apps will be screwed :)
<trulux> pitti: maybe, how can I make it doing that?
<crevette> seb128> ok
<crevette> :)
<pitti> trulux: no idea
<trulux> pitti: btw, does the new patch work as expected?
<doko> pitti: thanks, be sure to build it in an updated chroot ...
<pitti> trulux: sorry, the kernel pacakge doesn't like me
<trulux> any gui to rip files?
<trulux> pitti: why?
<crevette> I knew that when I decided to switch to breezy
<crevette> :)
<pitti> doko: why chroot? I have an up to date breezy
<trulux> pitti: what happens?
<pitti> trulux: all my attempts to build that ()$%/$)%/ kernel with that )$(%/$)% build system were screwed so far
<seb128> pitti: where is hidding dholbach?
<trulux> err, because of my patch?
<doko> pitti: ehh, it did build ok ...
<pitti> trulux: in a breezy chroot, make-kpkg claims that it isn't in a kernel source directory, in a hoary dchroot it fails for another reason *sigh*
<trulux> pitti: I hope it to work well :)
* trulux got pearls.tuxedo-es.org working again
<pitti> trulux: no, not because of your patch
<doko> pitti: an up to date breezy is not yet broken? interesting ...
<trulux> pitti: OK, fine :)
<Kamion> surak: hi - how goes it?
<dilinger> pitti: aww, kernel build <3 ;)
<pitti> doko: hmm, FTBFSses for me...
<pitti> dh_install -plibtiff-opengl
<pitti> cp: Aufruf von stat fr ./debian/tmp/usr/bin/tiffgt nicht mglich: Datei oder Verzeichnis nicht gefunden
<pitti> dh_install: command returned error code 256
<pitti> make: *** [binary-install/libtiff-opengl]  Fehler 1
<doko> pitti: http://people.ubuntu.com/~lamont/buildLogs/t/tiff/3.7.2-2ubuntu1/
<pitti> doko: yeah, I saw, and I ask myself which black magic you used
<pitti> doko: OTOH the kernel doesn't like me on davis today, too
<pitti> doko: so maybe I should just stop working for today...
<zul> pitti: something like Error I dont know where the kernel image goes to...blah blah
<surak> Kamion:
<pitti> zul: on breezy dchroot on davis make-kpkg claims that debian/build/build-*/ is not a kernel source directory
<surak> still being beated by a dead horse, which is fine :-)
<pitti> zul: OTOH that worked fine yesterday
<zul> yeah its doing the same for me
<Kamion> surak: any dead horse I can help (bring back to life|kill harder), whichever's appropriate? :)
<doko> pitti: that's really an up to date chroot from two hours ago? gcc --version? 
<pitti> zul: then I tried hoary dchroot and just to build one flavor, which failed as well ("cp: cannot stat /debian/firmware/[[:lower:] ] *")
<pitti> doko: it's my normal desktop system
<zul> meh...it bails on my when i do a fakeroot debian/rules clean in the kernel directory
<pitti> doko: anyway, I build the -ubuntu1 version now (for -ubuntu2 I only added a patch to debian/patches, but let's see)
* hunger wonders how often he updated X11 today.
<pitti> zul: becase the ABI files are missing?
<pitti> zul: I seriously hope that the kernel builds in the hoary dchroot
<surak> nothing that hard, just things that take time...
<zul> pitti: i dont think so
<Kamion> surak: ok, shout or mail cjwatson@ubuntu.com if you need help; I'm going to be out most of this evening, but will read scrollback
<pitti> doko: ubuntu1 fails for me as well *sigh*
<pitti> dilinger: hm, what do you mean?
<doko> davis/breezy?
<surak> thanks a lot, good night
<pitti> doko: no, my own box
<doko> pitti: gcc --version? 
<pitti> gcc (GCC) 4.0.1 20050517 (prerelease) (Debian 4.0.0-7ubuntu6)
<doko> hmm, i386?
<pitti> doko: but "cp: Aufruf von stat fr ./debian/tmp/usr/bin/tiffgt nicht mglich: Datei oder Verzeichnis nicht gefunden" doesn't sound like a compiler bug
<zul> doko: same here
<pitti> doko: yes
<doko> ok, then please blame keybuk ;-)
<pitti> doko: I rather think the buildd is outdated, not my box
<pitti> doko: alright :-)
<jnc> i guess font paths have changed in the most recent X11 pushes
<jnc> from /usr/lib/fonts now it is /usr/share/fonts
<jnc> also font server is not happy with me ;/
<jnc> :)
<pitti> broken badger
<hunger> jnc: I think that is a deliberate change:-)
<jnc> X11 is back and working for me at least, after a bit of tweaking in the xorg.conf
<seb128> good time to break GNOME, nobody will ever notice :p
<jnc> hehe
<hunger> jnc: Do you already have the latest round of updates?
<seb128> s/ever/even/
<jnc> i think so
<hunger> jnc: Good, I am just downloading that;-)
<pitti> seb128: I'm at the point to change to my laptop, which has still hoary (just newer kernel + libc) ...
<jnc> hunger: you'll want to modify your xorg.conf and change the references from /usr/lib/fonts  ->  /usr/share/fonts
<jnc> i'm still having trouble with this USB hub
<jnc> if i boot up from cold (no power)  and my keyboard is plugged into usb hub external, then it will not be recognized by the system
<seb128> pitti: :(
<jnc> if i have it plugged into a port on the front of this computer, it will work though from cold
<jnc> if during the boot process i unplug the hub, and after "hotplug" suceeds, i plug the hub in (with keyboard), it recognizes
<jnc> this was fixed briefly in hoary and then broke again when the release came
<jnc> i haven't the faintest idea of what's causing it
<jnc> it's a minor inconvenience though
<jnc> i don't know if it is a bug or what
<hunger> jnc: It does not sound like a feature to me.
* jnc grins
<pitti> trulux: kernel builds again, 1/6 flavors are done
<pitti> trulux: i. e. I'll try it tomorrow morning when this crackish thing hopefully built correctly
* pitti feels underloved today
<jnc> i've got 2.6.12-1-amd64-k8  
<jnc> my sata optical drive works again
<jnc> kind of happy about that
<jnc> pitti: is that the flavor you built?
<pitti> jnc: I'm building powerpc, with trulux' /tmp race protection patch
<hunger> What is the purpose of the xorg changes? Get rid of /usr/X11R6?
<jnc> ah
<pitti> seb128: interesting, in gnome-terminal Alt+n always behaves like Alt+1, but in firefox it works...
<seb128> have you restarted firefox?
<pitti> seb128: I restarted gdm after dist-upgrade
<seb128> ok
<seb128> weird
<seb128> no, iz not gtk bog
<pitti> but...
<pitti> seb128: it works in xchat, too!!!
<seb128> hum
<seb128> xfiles
<seb128> hum, anybody knows what are the /etc/passwd ",,," for?
<surak> Kamion: are you there?
<pitti> seb128: I think these are required for doing NIS lookups
<seb128> I don't get why ":Hardware abstraction layer,,,:" for hal
<pitti> ah, those, I thought you meant a completely "empty" line
<seb128> I understand the empty one :)
<seb128> I've a bug with sabayon
<seb128> it uses the field to display the username
<pitti> seb128: that's the GECOS field, the other parts are probably for room number, phone, etc.
<seb128> ok, some lines use that, some other don't
<seb128> >>> pw = pwd.getpwnam ("hal")
<seb128> >>> pw.pw_gecos
<seb128> 'Hardware abstraction layer,,,'
<seb128> that sucks :p
<pitti> seb128: split it at , and skip empty fields :-)
<seb128> yeah, I guess I'll do this
<seb128> I guess than "," is not a legal char for the name? :)
<pitti> seb128: see passwd(5)
<pitti> seb128: "Three additional values may be present in the comment field. ... These fields are separated from each other and from any other comment field by a comma."
<seb128> thanks
<Treenaks> pitti: what if my name contains a comma? :)
<seb128> b0rked name, change name :p
<pitti> Treenaks: I guess you are busted then and should sue your parents :-)
<tsume> hal reminds me of the computer from a space odyssey
<hunger> Treenaks: Then you have to get used to get manhandled by unix systems.
<tsume> is hal going to take over my computer?
<Treenaks> hunger: hm..
<pitti> tsume: too late, it already did
<tsume> pitti: nooo! ;)
<pitti> tsume: although I derooted it, so it actually can't any more
<tsume> pitti: what if hal gets the technology to reintegrate and destroy all mandkind? 
<pitti> tsume: look in debian/patches/ :-)
* tsume chuckles
<surak> tsume: This ony cannot say you "dave, I'm afraid"
<hunger> tsume: That is the good thing about open source: Nobody can sneak in instructions that will drive your computer mad without someone else noticing sooner or later.
<tsume> hunger: how much you wanna bet ;)
<hunger> tsume: Pretty much... since I did not specify "sooner or later";-)
<tsume> hunger: some people use CVS version of software, and compile it. CVS is the key to sneaking in trojans
<surak> This reminds me kernel-list about NSA releasing SELinux :-)
<pitti> hunger: just try breezy and watch your computer go mad :-)
<pitti> hunger: or look at my face, I'm already mad after the last hours
<hunger> pitti: So far it is behaving pretty well....
<hunger> pitti: and sooner or later breezy will be stable;-)
<pitti> doko: ah, I know the reason for the tiff FTBFS, of course it's an X.org bug
<pitti> doko: "tiffgt-tiffgt.o(.text+0x8a2):/home/martin/ubuntu/tiff/tiff-3.7.2/build-tree/tiff-3.7.2/tools/tiffgt.c:117: undefined reference to `glutInitDisplayMode'"
<pitti> doko: so its
<pitti> not Keybuk, but daniels
<doko> ok, add that to the build-dep instead of the xlibmesa-glut-dev: libglu-dev-xorg (>= 6.8.2-15)
<doko> pitti: ^^^
<pitti> "checking for GLUT library... no"
<pitti> ^^ from configure
<pitti> doko: yeah, will do
<pitti> argh
<pitti> why does libglu-dev-xorg depends on x-window-system-core??
<pitti> the buildds will have fun
<uniq> ok.. xorg tells me it cant find the fixed font.. any hints on how to get it back and rocking? 
<uniq> *reading back*
<fabbione> uniq: breezy?
<uniq> yup.
<uniq> fontpath.
<fabbione> than we know. please wait the next couple of days for things to be settled properly
<uniq> fabbione: no evilhack workaround around? 
<fabbione> no.
<fabbione> people have been told not to upgrade breezy for a few days
<fabbione> no time to work on workarounds
<fabbione> we need to get proper stuff done first
<uniq> ok.. pinning here i gome.
<uniq> come.
<pitti> doko: doesn't help
<fabbione> pitti: check the new x*-dev packages from xtrans and x11proto<something>
<seb128> luis_: sabayon 0.18 available
<luis_> seb128: danke
<seb128> luis_: but you probably don't want to update xorg or other stuff :)
<luis_> yeah
<luis_> I hear;)
<doko> pitti: wuhaaa...
<pitti> doko: anyway, I'll find out
<pitti> probably tomorrow, I'm falling asleep
<seb128> 'night pitti 
<pitti> night guys, sleep well everybody
<mvo> night pitti 
<Mithrandir> elmo: please sync pyblosxom, ok to override ubuntu changes.
* mvo goes to bed now
<KaiL> fabbione: still awake?
<surak> must the openoffice icons on live-cd change their default names according with the locale set at boot time?
<thom> surak: if their .desktop files have been translated to your language, yes
<surak> thom: It was a rethorical question :-) In fact, it seems it had stopped working on 5.10. Let me check on 5.04
<surak> thom: No... 5.04 also shows the .desktops not in native language.
<surak> thom: another question: is openoffice.org running from live english only?
<thom> surak: not sure how the sizes worked out; i think we were trying to get as many translations as possible
<surak> Are ooo .desktop files maintained by ooo people, debian people, ubuntu, gnome, who?
<thom> yes ;-)
<surak> ??
<thom> probably a combination  of ooo, debian and ubuntu folk
<surak> ah ok
<surak> So dunno who send the pt_BR translations for them :-(
<surak> the more I work, the worse my english gets
<surak> thom: is ok that I send the .desktop with corrected pt_BR translations for you?
<thom> absolutely; file a bug in bugzilla with them :-) (you never need to ask about translations; we desperately need them :-) )
<thom> (and dude, whenever i see non-native speakers say how bad their english appears to be, i always feel bad that i can't speak their language at all)
<surak> my english is not all that bad... even my portuguese gets work as long as the night comes :-)
<surak> worse!
<surak> not work!
<thom> heh :-)
<eruin> heh, I know non-native english speakers with better english skills than myself (norwegian/british citizen)
<surak> :-)
<surak> thom: no... only ooo-l10n-en is installed :-(
<eruin> what would cause keyboard shortcuts like ctrl+c, ctrl+v to get toasted in gnome?
* lamont tries to remember the correct process to have palo move from universe-> main for hppa.
<surak> thom: odd. there are two files .desktop files for each openoffice.org app - and none of them has names but in english. (but ooo645template.desktop and template.desktop
<fabbione> KaiL: more or less
<KaiL> ah ;)
<KaiL> is the wbsd driver in hoary compiled with SD support? (external patch..)
<Amaranth> sure, put out gnome 2.11.1 packages during the transition so it's like walking through a mine field to get them :P
<fabbione> KaiL: wbsd?
<fabbione> what driver is that?
<KaiL> http://projects.drzeus.cx/wbsd/
<eruin> Amaranth: haha
<KaiL> Winbond SDIO
<fabbione> KaiL: and is it part of the hoary kernel?
<fabbione> i386/386:CONFIG_MMC_WBSD=m
<KaiL> yes, but I don't know, if with that SD patch mentioned on that page
<fabbione> is this driver?
<surak> Does someone know about via 6410 PATA raid controller in 2.6.10?
<KaiL> yes
<KaiL> surak: use kernel raid ;)
<fabbione> KaiL: it's not an external patch. it's compiled as it is shipped from vanilla kernel
<KaiL> yes
<fabbione> surak: there is no driver for that controller in 2.6.10
<KaiL> but out of the box it only supports MMC, not SD (as I understood that...)
<KaiL> http://projects.drzeus.cx/wbsd/sd.php see this
<surak> Kail: That's not the problem, but recognizing the pata drives on mobos with via6410 (there are people selling msi 915g mobos with pata drivers attached on it - not for raid, but to reduce costs)
<fabbione> KaiL: when the SD patch will make its way upstream, it will be included :)
<surak> fabbione: I saw a patch somewhere to use the pata raid port without raid functions. Do you know something about it?
<fabbione> surak: it's in the breezy kernel
<KaiL> fabbione: so not yet?
<fabbione> anyway i am off
<fabbione> KaiL: no. the driver is upstream and they push patches there
<fabbione> better they keep going that way
<KaiL> this sd patch not...
<malte`> hi
<malte`> i'm waiting for the gcc4 packages transition to end... i want to upgrade to breezy :)
<malte`> go on with the good work guys!
<malte`> (i upgraded to hoary since the 4-5 test cd)
<surak> this is a silly question. Should I post a openoffice.org bug against ubuntu or ubuntu-universe?
<KaiL> surak: normal IDE driver can't even detect this devices?
<surak> no
<KaiL> OO.o is in main
#ubuntu-devel 2005-05-26
<stevenj> anyone have any information on totem-gstreamer and a mozilla plugin so I can stream movies?
<surak> kail: no, this motherboards have:
<surak> 1 pata port (this is detected by ide driver)
<surak> 4 stat ports (never tested)
<surak> 2 raid pata ports (this is via6410)
<surak> the patch seems to handle with those 2 pata ports
<KaiL> no "normal" second pata??
<surak> no
<surak> weird, isn't it?
<KaiL> yes
* KaiL has 2 PATA and 4+2 SATA
<KaiL> and 2+2 on a K7
<surak> it has one pata port for legacy cd. As people attach dvd-recorders on it, the raid port is used for pata hds.
<KaiL> silly
<KaiL> already installed over that legacy pata?
<surak> sata is still quite uncommon in brazil.
<surak> oh, it works. but don't try to record a dvd and use the hard drive at the same time :-)
<KaiL> here each board has, but normally they are unused ;)
<KaiL> lol
<KaiL> could you triy the kernel from breezy?
<KaiL> you only need to install 1 additional package
<surak> I'm trying breezy right now
<KaiL> kernel 2.6.12..?
<surak> no
<surak> its colony 1
<KaiL> ?
<surak> 2.6.10-5-i386
<KaiL> "msi 915g" is the board?
<KaiL> which CPU socket?
<surak> msi 915g combo
<surak> it is one of those new p4 sockets, where the processor no longer hold the contacts. forgot the name
<KaiL> wow, the first Socket 775 I hear about ;p
<KaiL> ah, yes, see it...
<surak> I cannot install a newer kernel - using live - the hard drives are attached at raid :-)
<KaiL> hmm
<KaiL> you could get a breezy CD, if you are silly enough :p
<KaiL> VERY strange configuration...
<surak> this is breezy-live-i386.iso
<luis_> the liveCD from yesterday actually works
<luis_> at least did yesterday
<KaiL> luis_: same board? ;)
<luis_> no
<KaiL> does it already have 2.6.12?
<surak> no
<surak> 2.6.10
<KaiL> ...damn
<surak> indeed - using live when there are 400gb waiting to be filled :-)
<KaiL> connect the HD to the normal port? :)
<surak> the case is,
<surak> I work for a computer manufacturer. they actually are selling machines with this bizarre hd / dvd layout. people say "hey, it works with nt, we don't care"
<KaiL> DDR+DDR2, no Firewire, useless PATA raid, Realtek LAN - am I allowed to say, this board sucks? ;)
<KaiL> Windows doesn't have problems with that?
<surak> they distribute together with it an linux distro which uses 2.4.25 with via proprietary driver - this way, the raid is recognized (needless to say via driver sucks - about 10mb/s)
<surak> no, if you use the driver floppy :-)
<KaiL> damn...
<KaiL> do you really want to use the raid as a raid?
<KaiL> (Mirror doesn't count, as we can do that later)
<surak> no
<surak> the driver from via is really really slow. it sucks at all.
<KaiL> then connect the hd to the normal controller and the cdrom too
<KaiL> install there, update kernel and then move the cdrom :)
<surak> :-)
<surak> My problem is, I need a distro which can actually see the hard drive out of box. Got to wait for live with 2.12
<surak> 2.6.12, sorry
<KaiL> for customers?
<surak> yes
<KaiL> ah
<KaiL> what's this VGA? intel one?
<surak> gnome item menus: https://bugzilla.ubuntu.com/show_bug.cgi?id=10943
<surak> They are selling with radeon x300 pciexpress
<surak> it IS an strange world :-)
<surak> gotta go. Bye!
<KaiL> alternate.de lists a "Media Accelerator 900" VGA chip..?
<KaiL> for now: recommend an AMD K8
<KaiL> they need less electrival power and are less problematic :p
<surak> it has some bad vga onboard - didn't even tried
<KaiL> if that's an intel, it's slow (~600fps in glxgears), but stable
<KaiL> ....that was mesured with i855, afaik the new is faster
<surak> night. i'll grab some wine and sleep.
<KaiL> lol
<KaiL> << sleep too, but no wine
<TheMuso> .ckear
<sjmorgan> can somebody using breezy try CTRL+SHIFT+T in gnome-terminal and see if it closes the current tab instead of opening a new one?
<tseng> try #ubuntu.
<sjmorgan> this is a potential bug
<sjmorgan> not tech support
<sjmorgan> i just want it confirming
<tseng> when you have a potential fix, this is the right place
<tseng> but confirmed and know better next time
<sjmorgan> well nobody else has complained whenever i've asked about potential bugs in here before so i think i'll keep on doing it seeing as it's development related
<sjmorgan> laters
<SEBest> anyone knows gamin:fam ?
<SEBest> gamin/fam ?
<g14> Are there debs out for sabayon 0.1.8 yet?
<Lathiat> cripes, that squid vuln has got to be the stupidest thing ever.
* Lathiat shoots squid developers
<jdub> Lathiat: next time you see lifeless about... :)
* lamont plays with ubuntu on a compaq nc6000
<lamont> 900MB RAM.  coolness
<lamont> heh.  1GB array
* lamont ponders why /proc/meminfo says 100MB less.
* lamont wonders if an AR5212 nic should "just work" on the livecd
<sladen> lamont: paging overhead.  what kernel do you have running?
<lamont> livecd
* lamont gets dragged off to dinner with the family.  back later
<lu|dinner> g14: yes
<lu|dinner> (wrt sabayon 0.18)
<lu|dinner> seb128 said he pushed them a few hours ago
<lu|dinner> thom: hey, is network-manager still planned for breezy?
* lu|dinner is wondering if he could go around pushing for apps to assume it is present or not
<bob2> I don't think you can do that in general, anyway
<bob2> NetworkMagic spec, iirc
<lu|dinner> ah, danke
<g14> lu|dinner: Can I get a link for the sabayon 0.1.8 debs?
<lu|dinner> they are in synaptic for me
<ajmitch> lu|paper: it's certainly planned, still
<g14> I'm gonna guess sabayon 0.1.8 is in the breezy apt repositories
<tseng> why do you have to guess
<tseng> look at breezy-changes list
<g14> tseng: I'm there thanks to the osnews article. I am just trying to find a link to download the 0.1.8 sabayon deb as it's not in universe for hoary
<jsgotangco> morning
<benplaut> 'morning
<benplaut> *afternoon
<jdub> uh oh
<benplaut> ?
<jdub> where's daniels?
<jdub> gah
<jsgotangco> oh
<jdub> STONER!
<tseng> stoner broke my xorg :(
<tseng> silly fonts
<jdub> it runs ok if you pass -fp to it
<tseng> yeah i fixed it
<cartel_> stoner?
<jdub> tseng: what did you change?
<jdub> cartel_: daniel stone
<tseng>  /usr/lib/fonts -> /usr/share/fonts
<cartel_> tseng: 420 smoke it up!
<cartel_> tseng: oh that stoner
<tseng> cartel_: ...
<cartel_> tseng: he cant handle his herb
<jdub> that didn't fix Xnest for me
<tseng> cartel_: straight edge to your face
<cartel_> tseng: hehehe
<tseng> jdub: worksforme
<jdub> i think Xnest makes more assumptions about locations
<tseng> or uses the running config?
<tseng> shrug
<jdub> yeah, funny
<jdub> a real display works
<jdub> but Xnest dosn't
<jdub> i'll try Xnest in a newly configured real display
<tseng> gr i need a mini pc w/ a pci slot
<jdub> yeah, that's weird
<jdub> it must use the running config
<minghua> Is there any reason libc6-dev not depending linux-kernel-headers anymore?
<minghua> can't see anything relevent in the upload changelog
<minghua> except some metioning on NPTL headers, but doesn't look like related
* lamont tries to remember what we have available for resizing an NTFS partition
<wasabi> ntfsresize. ;)
<lamont> ntfsprogs - tools for doing neat things in NTFS partitions from Linux
<lamont> feh
<lamont> the best part is that it's a virgin install. :-)
<jdub> hey lamont 
<lamont> morning jdub
<Burgundavia> jdub, would you mind taking a look at my recent comment on 10453 and see if it on-track?
<jdub> disagree with the specifics of the design, but the point of it is correct
<Burgundavia> I was more worried about the point, not the design specs
<Burgundavia> jdub, would you mind making a comment on how you would like to see it done, or any thoughts you have?
<jdub> commented
<Burgundavia> jdub, cheers, thanks
<ajmitch> hi
<tsume> breezy isn't very broken at all
<tsume> I'm running KDE ;) and X, font paths changed :)
<cartel_> does hoary upgrade to breezy cleanly?
<tsume> cartel_: not right now :)
<cartel_> where do the names come from?
<tsume> cartel_: it can later however ;)
<cartel_> where the wild things are?
<tsume> cartel_: lang creatures
<tsume> *land
<cartel_> what about the first names?
<tsume> the names are better than the crummy toystory characters ;)
<cartel_> yeah but not better than "Shit for Brains"
<cartel_> octopus-0.1 ("Shit for Brains")
<tsume> hehe
<tsume> I feel much better developing now. No GUI porting blues.
<lamont> tsume: give us a day or so... :-)
<tsume> lamont: hehe :)
<tsume> lamont: I know how the transition progresses. I'm waiting patiently
<lamont> cartel_: pretty  much random animals, although I think it might be trying to have an african-animals theme
<tsume> lamont: just make sure the topic has a "breezy temporarily working" so people like I can upgrade.
<tsume> lamont: is the african kid on the homepage supposed to be gangster-like?
<lamont> nah - it's only marked 'probably well broken'
<stuNNed> heh
* lamont doesn't do artwork.
<tsume> mdz: you're still a speciesist :) 
<tsume> mdz: :P
<lamont> OTOH, I expect that all 5 models are south african.  warty's 3 were.
<tsume> lamont: even the white people?
<lamont> duh
<tsume> lamont: okay.. :)
<tsume> that one kid still looks gangster-like
<tsume> I bet hes carrying a gun under his shirt
<jsgotangco> because of the hair?
<jsgotangco> that's not nice
<tsume> jsgotangco: watch the government buildings sometime. I watched a kid walk in the door like him, and walk back out. There were metal detectors after the entrance, and he needed to take his gun off before entering the building again.
<jsgotangco> heh
<jsgotangco> just like the big bad wolf in little red riding hood
<tsume> I'd of laughed if he pulled the gun and started shooting. All I needed to have to get in was a scan the first time, and I could walk in and out without them researching me. :P
<tsume> though, I always set off the metal detector, I carry throwing knives in my leg sheath, and pass it off as my steel toed boots :)
<jsgotangco> perimeter security hardware is overrated you still need people with brains to use them
<lamont> the court building here has a nice set of lockers where you can store whatever...
<lamont> right before the checkpoint
<tsume> jsgotangco: there are 5 gaurds at the entrance and checkpoints
<jsgotangco> gyah
<tsume> at the entrance alone
<jsgotangco> ninja skills pay off heh
<tsume> heck, I carry large wallets for my palm all the time. I slip my lock picking kit _under_ my wallet, and bring it in government buildings ;)
<jsgotangco> brb lunch
<tsume> you just have to watch security some day and realise how transparent they are with security.
<tsume> jsgotangco: brb, sleep time :P
<lamont> daniels: livecd was happy with my display... installed system has lots of cruft/shadows
<lamont> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 
<Lathiat> well i tried to upgrade. that was stupid.
<Lathiat> now apt is in a totally broken state :)
<Lathiat> hmm, seems by installing x11proto-core-dev manually, it fixed it.
<pitti> Good morning
<jsgotangco> pitti, hey :)
<pitti> Hi jsgotangco 
<pitti> thom, elmo: can I please have "xmlto" in davis' hoary dchroot?
<fabbione> pitti: for the kernel?
<pitti> fabbione: yes
<fabbione> it's in the breezy chroot at atleast
<pitti> fabbione: make-kpkg in the breezy dchroot is b0rken
<fabbione> uh?
<fabbione> since when?
<pitti> fabbione: I tried to build a kernel for an hour, and then I noticed that it works in hoary's dchroot
<pitti> fabbione: it worked at Tuesday
<fabbione> what error do you get?
<pitti> fabbione: yesterday it was broken
<fabbione> weird
<pitti> fabbione: when calling make-kpkg in e. g. debian/build/build-powerpc it insisted to claim that this wasn't a kernel source dir
<Amaranth> hey, vlc still works!
<fabbione> pitti: xmlto is needed only to build the documentation
<pitti> fabbione: that's why I spent an hour trying to fix patches/config/etc
<Amaranth> the GUI just got removed, the libs and python bindings work
<Amaranth> neat
<fabbione> pitti: if you only need the arch binaries use the build-debs target
<fabbione> pitti: and grab the debs from debian/build
<pitti> fabbione: ah, cool, I will do that
<fabbione> pitti: i need to figure the build-indep stuff in the kernel
<fabbione> pitti: i don't think you need udebs, do you?
<pitti> fabbione: no
<fabbione> ok
<pitti> fabbione: actually I only need the powerpc deb
<pitti> fabbione: but calling make-kpkg in debian/build/b-ppc fails as well
<fabbione> than use the above target
<pitti> fabbione: that's why I rebuilt the whole kernel during the night
<fabbione> oh right...
<fabbione> that's weird
<pitti> fabbione: you mean fakeroot debian/rules binary-arch?
<pitti> oh, there is binary-debs, now I see it
<pitti> thanks man
<fabbione> but that will still call make-kpkg
<pitti> erm, that reconfigures the kernels??? they are already built...
<fabbione> no don't worry.. let it do
<fabbione> it doesn't reconfigure
<pitti> ah, ok "Nothing to be done for build" :-)
* pitti kisses fabbione 
<pitti> fabbione: I can't believe it, I get debs :-)
<fabbione> no! really? :)
<pitti> fabbione: odd, this worked so nicely on Tuesday...
<fabbione> i will need to check on that
<fabbione> probably kernel-package has been updated
<fabbione> and it is broken
<pitti> fabbione: zul got the same
<pitti> fabbione: so I don't think that it is my stupidity only
<fabbione> pitti: yes i saw the message, but i didn't build kernels that way for a while
<pitti> "that way"? with debuild -us -uc -nc?
<fabbione> pitti: to do test kernels i usually use the binary-debs target
<pitti> fabbione: is there a special trick to build only one flavor?
<fabbione> pitti: yes.. rm debian/config/$arch/$not_needed_flavours
<pitti> ok, the hard way :-)
<fabbione> well mv them somewhere else :)
<pitti> yeah, of course
<tja> does ubuntu-kernel use pivot_root?
<fabbione> tja: what do you mean?
<tja> well.. how to put this..
<tja> when it boots.. I can't find anything of interest in the initrd-image
<tja> ;)
<tja> meaning, I don't undestand how it chroots to the filesystem
<fabbione> the initrd is meant to load the minimum it needs to pivot_root to the real root
<pitti> trulux: ?
<pitti> Hi mvo
<mvo> morning pitti, morning all
<fabbione> there is nothing interesting
<Burgundavia> morning mvo
<tja> fabbione: where is it done? I'm trying to find an example to use in d-i...
<mvo> hey Burgundavia 
<fabbione> tja: it's done in the initrd, but d-i is something slightly different. the initrd there is bigger and with more stuff
<tja> and the chroot is linked to busybox, which complicates things
<tja> but yeah, I'll continue digging
<tja> ah, blind me. it was sbin/init that does all that
<pitti> Hey hey seb128 
<seb128> morning pitti :)
<seb128> do you feel better?
<pitti> seb128: yeah, pretty good again now :-)
<seb128> cool
<jdub> hey seb128 
<seb128> morning jdub 
<seb128> what's up? :)
<jdub> my pants
<jdub> but only briefly
<seb128> ah ah
<seb128> how are these bug lists going? 
<seb128> nobody gets malone/GNOME bugs atm, would be nice to get a mailing list for these :)
<jdub> ok
<pitti> trulux: here?
<fabbione> pitti: did the kernel error showed also on !ppc ?
<fabbione> or is it ppc specific?
<pitti> fabbione: I only tried it on davis's breezy dchroot
<pitti> no idea
<fabbione> ok
<fabbione> i am gonna spin concordia a bit :)
<fabbione> is there something wrong with chinstrap?
<fabbione> i can't ssh anymore
<pitti> fabbione: I can't get to chinstrap, the wiki, bugzilla, etc
<fabbione> ahi ahi ahi
<pitti> meh, I just finished typing a bug report
<fabbione> thom: ???
<bob2> (me too)
<zyga> is archive.ubuntu.com down?
<pitti> zyga: all of our computers can't be reached atm
<zyga> pitti: ah, fine
<Kamion> tja: what are you trying to do in d-i?
<Kamion> tja: most things that need to run stuff from the target filesystem in d-i just do 'chroot /target whatever'
<pitti> crimsun_: here?
<tja> kamion: I'm trying the pivot_root && chroot -stuff, but I've hit the wall
<tja> I've changed lib/debian-installer/exit to run a script if debian-installer/exit/pivot_root boolean is true
<tja> but the main-menu just tells that something went wrong
<tja> at least pivot_root is done, verified from a console
<Kamion> you'd probably want to re-exec init after that, like the live CD does - check the casper source
<tja> exec chroot . /sbin/init <dev/console >dev/console 2>&1
<tja> that's what it _tries_ to run ;)
<Kamion> that won't be pid 1, and init won't like that
<tja> so just "exec /sbin/init"?
<Kamion> no, see casper :-)
<tja> ok, will do ->
<Kamion> it does a pivot_root and then (a bit later) 'kill -USR1 1'
<tja> the grub-installer thing seems "easy", only that the postinst-script is quite messy
<tja> ..to read
<Kamion> that was password preseeding? yeah, it's straightforward
<tja> yep
<Kamion> all the bootloader installers are a bit messy in one form or another ...
<tja> instant headache after reading that
<Kamion> you get used to them :)
<tja> sooo many ways to get one ;)
<Kamion> I've got some grub-installer stuff to commit after I finish the current bit of http://udu.wiki.ubuntu.com/InstallerStage2Progress; if you send me a patch by that point, I'll commit it at around the same time
<tja> cool
<fabbione> oh pitti... i think the chroots still have an old dpkg
<pitti> fabbione: wrt building the kernel?
<fabbione> pitti: yes
<pitti> fabbione: oh, ok. well, since it works fine on hoary, I'm happy so far :-)
<sladen> Kamion: out of interest, what type of message gets pushed through --status-fd?
<sladen> Kamion: never mind, found it
<thom> pitti: can you do a security review for me? http://people.ubuntu.com/~thom/dhcdbd-1.5.tar.gz; needs to be setuid root since it needs to be able to start and stop dhclient
<pitti> I take a look at it, how urgent is it?
<thom> it's for NetworkMagic, so not like OMG I NEED IT THIS MINUTE, but next week sometime would be good
<pitti> oh, I can do it today
<thom> rocking
<thom> i'm not really gonna be connected for much of the day, so email would be great :-)
<pitti> sure
<thom> cheers
<pitti> fabbione: dmix sucks.
<fabbione> pitti: cool!
<fabbione> fix it :)
<mjg59> dmix is getting less suck6
<ajmitch> hi pitti 
<pitti> Hi ajmitch 
<bob2> dmix will work automagically in the next release of alsa, apparently
<pitti> bob2: the problem is not getting it to work, that's easy
<bob2> yeah
<pitti> bob2: but on my internal sound card it outputs cracks and noise
<bob2> but it's one less thing to do
<pitti> bob2: and esd does not start on my external USB headset
<pitti> because it can't find an appropriate rate/format/whatever
<pitti> even if I force it in asound.conf *sigh*
<bob2> hah
<ajmitch> pitti: sorry I haven't been around, how's things going on the security front?
<pitti> ajmitch: I'm currently working with trulux to get SELinux packages in (maybe you can take over, I'm overloaded)
* ajmitch has briefly talked with trulux about selinux
<pitti> ajmitch: and I built a test kernel with /tmp race protection
<ajmitch> pitti: sure, I've been working with him
<ajmitch> I've looked over the patches as well 
<pitti> ajmitch: I have the SElinux patched packages on my box for a while, without any problems
* ajmitch also
<pitti> ajmitch: I think we should upload them ASAP
<ajmitch> apart from pam, which had config file changes :)
<ajmitch> preferably in the next week, imho
<pitti> ajmitch: well, I'm still misssing some packages, trulux does not have all of them on his page
<ajmitch> which ones are missing?
<ajmitch> I checked the dpkg patch against 1.13 by manoj
<pitti> dunno exactly
<ajmitch> it's quite small
<pitti> ajmitch: I think Keybuk is willing to apply it for Debian and for Ubuntu rsn
<ajmitch> yeah, I saw the conversation yesterday
<ajmitch> once packages are in I'll start working on policy & tools as well
<ajmitch> they can go into universe for now, then we can review for main-worthiness :)
<pitti> ajmitch: yeah
<pitti> ajmitch: having the patched packages in main already helps a lot, then it's a piece of cake to install the rest
<ajmitch> certainly
<ajmitch> gives me a good reason to apply for uploading to main
<ajmitch> :)
<ajmitch> pitti: what else can I help with for now?
<jsgotangco> bye all
<pitti> ajmitch: are you familiar with the ubuntu kernel packaging?
<ajmitch> pitti: I can learn, I've built modified kernels from it before
<pitti> ajmitch: it would be nice to get some more patches, as we talked about in the bof
<ajmitch> sure
<seb128> pitti: anything new with dmix to say that it sucks?
<pitti> seb128: well, first, you can't open /dev/dsp while another alsa client is running (that's not dmix' fault, however)
<pitti> seb128: so our original purpose of allowing people to run skype and friends is defeated by that
<seb128> not cool
<pitti> seb128: second, when I use dmix on my cheap card here, I get a lot of cracks and noise
<seb128> :(
<mjg59> pitti: skype supports alsa, doesn't it?
<mjg59> And is this you using dmix directly, or going via esd?
<mjg59> The /dev/dsp thing can be avoided by LD_PRELOADing the library which wraps OSS calls to alsa ones
<jordi> dmix is going to be a pain
<pitti> mjg59: I went through esd
<pitti> mjg59: because we decided to leave the esd interface a bit for transition
<pitti> mjg59: OTOH, lemme try to switch gstreamer to alsa...
<mjg59> pitti: There's known issues with esd and dmix
<mjg59> There's a patch in gnome bugzilla
<pitti> mjg59: indeed, no cracks with gstreamer -> alsa
<pitti> (with dmix)
<mjg59> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=140803
<mjg59> Try the last patch in there
<pitti> mjg59: oh, I still get cracks
<pitti> fewer, but on hd activity they are still noticeable
<mjg59> Ok, with hd activity that's likely to be a separate problem
<count0nz> sorry to bug you :), how whuld i force breezy to be installed ? it won't let me install it after i upgraded , downgraded and then upgraded again :)
<pitti> seb128: how much would break if we switched gstreamer output to alsa and entirely skip esd?
<pitti> and do you think that would be a good idea in the first place?
<tja> sound output of my totem is completely screwed if the audio_sink is esd
<tja> so it clearly has issues
<pitti> tja: do you use dmix?
<tja> no
<tja> this is a stinkpad T23
<count0nz> :( hates sme
<count0nz> sh-3.00# apt-get --ignore-hold dist-upgrade
<count0nz> Reading package lists... Done
<count0nz> Building dependency tree... Done
<count0nz> Calculating upgrade... Done
<count0nz> The following packages have been kept back:
<count0nz>   arts aspell-bin qt3-dev-tools x-window-system-core
<count0nz> 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
<\sh> hmm...jabber messages would also be nice for malone ;)
<seb128> pitti: let me ask on #gstreamer :)
<pitti> seb128: I mean, there shouldn't be many (any?) apps which use esound directly, right?
<seb128> pitti: imho that's worth trying
<doko> chmj: ping
<seb128> pitti: I don't think so
<pitti> seb128: I also try the gnome patch for esd now, but one api less is always nice
<seb128> yeah
<pitti> seb128: at least I can purge "esound" without any dependency issue
<seb128> pitti: but by using alsa directly you lock /dev/dsp, no?
<pitti> seb128: yeah, that's the problem, but it could be solved (as mjg59 says) with the alsa-oss wrapper
<pitti> seb128: right now esd uses oss, so we are already locking /dev/dsp
<seb128> oh, you want to switch to libesd-alsa?
<seb128> I thought you want to drop esd
<pitti> seb128: either libesd-alsa or gstreamer->alsa->dmix
<pitti> seb128: my patched esd is ready, lemme try
<seb128> according to a teuf (a rb/gnome-vfs guy) dmix should works better with alsa 1.0.9
<pitti> yeah, and automatically
<seb128> s/a teuf/teuf/
<pitti> seb128: so far I have sound black magic configuration
<seb128> if we push dmix now, that's easy to switch to esd-alsa later? 
<pitti> seb128: we should switch to esd-alsa in any case
<seb128> ok, so let's do that NOW :)
<pitti> seb128: i. e. *now*, regardless of what we do
<pitti> seb128: yeah, we need to change ubuntu-desktop for that
<pitti> Kamion: do you think changing the esd dependency of ubuntu-desktop is reserved to mdz?
<aj> anyone know when mdz's off holidays, btw?
<ogra> monday afaik
<pitti> mjg59: hmm, the patch doesn't help :-(
<pitti> mjg59: still cracks
<pitti> fuck, my Control key is totally broken
<Kamion> pitti: go ahead, I'll take responsibility if he objects and we can always switch back later
<aj> ogra: cheers
<Kamion> pitti: (as in go ahead and change the seed)
<Kamion> aj: yeah, Monday 23rd
<pitti> Kamion: the idea was to s/libesd0/libesd-alsa0/; does that have to happen in the seeds?
<Kamion> desktop: * libesd0 # so that esd actually works (as opposed to libesd-alsa0)
<mjg59> pitti: File a bug, then
<mjg59> (Or follow up to that one)
<pitti> Kamion: at that time -alsa0 had issues, but it works perfectly for weeks now at my boxes
<mjg59> esd maintenance is basically stalled. If we're going to depend on it, that needs to be fixed.
<pitti> we thought about switching to polypaudio anyway
<Kamion> pitti: right - but libesd0 is in the seed, so you'll have to change that to make it happen
<Kamion> ... just like hoary
<pitti> ok
<mjg59> Personally, I'd be inclined to get rid of the damn thing altogether. The only thing it really offers over dmix is network transparency, and we don't set that up.
<pitti> mjg59: ++
<mjg59> Does everything in main that produces sound use gstreamer?
<pitti> mjg59: everyting in our default desktop at least
<seb128> I don't think so
<tja> doesn't the desktop sounds depend on a running esd?
<pitti> mjg59: that's why <pitti> seb128: how much would break if we switched gstreamer output to alsa and entirely skip esd?
<mjg59> If so, that should really be fixed
<seb128> pitti: xchat, gaim by example don't use gstreamer afaik
<pitti> xchat uses any sound??
<seb128> sure
<pitti> I only get pc speaker beeps
<mjg59> xchat has support for playing samples, but not for automatically downloading them
<Mithrandir> gdm uses aplay.
<seb128> preferences
<seb128> sounds
<pitti> seb128: indeed, gaim uses esd by default 
<mjg59> Of course, there's no downside in continuing to offer esd
<Mithrandir> X doesn't use gstreamer either.
<seb128> pitti: no, gaim uses libao
<mjg59> X doesn't make sound
<Mithrandir> mjg59: xset +b and it does.
<pitti> seb128: my gaim is set to esd
<seb128> pitti: and I've patched it to use esd by default, easy to change
<pitti> seb128: can we make it use alsa?
<mjg59> Mithrandir: Ungk. That's through the system beeper though, isn't it?
<seb128> pitti: yes
<pitti> seb128: so far it offers me esd, artsd, automatic
<mjg59> I'd suggest the following:
<mjg59> a) change gstreamer to use alsa directly
<Mithrandir> mjg59: I'm actually not sure; it seems to be captured by esd and turned into more of a "boing" sound.
<mjg59> b) patch esd, set it to use alsa and leave it in desktop
<seb128> pitti: "automatic" uses libao IIRC
<mjg59> c) wrap any legacy OSS apps
<mjg59> That way everything works
<seb128> pitti: hum, which does esd/oss/polypaudio but not alsa apparently ...
<pitti> that's what I mean
<pitti> seb128: however, you can setup a custom command
<mjg59> libao ought to support alsa, shoudln't it?
<pitti> seb128: let's use "aplay" :-)
<seb128> mjg59: not according to the package description, not sure on how reliable that is :)
<seb128> pitti: hehe
<pitti> seb128: that works fine
<seb128> cool
<pitti> seb128: killing esd and setting it to automatic doesn't work
<mjg59> mpg321 uses libao - I thought that was how it got alsa support
<seb128> automatic is libao, which is set to esd
<mjg59> Ok. libao supports alsa.
<mjg59> (On checking the source)
<seb128> yep
<seb128> there is an alsa09
<seb128>    * OSS (Open Sound System)
<seb128>    * ESD (ESounD or Enlightened Sound Daemon)
<seb128>    * ALSA (Advanced Linux Sound Architecture)
<seb128>    * polypaudio (next generation GNOME sound server)
<seb128> from the README
<pitti> cool
<mjg59> So it's a minimal amount of change that's needed
<seb128> right
<seb128> go go go pitti :)
<pitti> argh, can I please have my Control key back?
<pitti> now that it doesn't work any more I notice how often I need it...
<seb128> downgrade xorg?
<thom> so firefox is fine (ctrl+t etc are fine) but ephy is utterly fucked
<thom> what's up with that?
<mjg59> gtk boog
<pitti> I tried to change something in the keyboard shortcuts and now it is even more broken
* mjg59 goes into town
<seb128> thom: xorg b0rkage
<thom> seb128: dude, i'm so blaming you
<seb128> why?
<thom> why not? ;-)
<Treenaks> thom: what's wrong with blaming daniels? :)
<seb128> because that's xorg bog
<Mithrandir> Treenaks: he's not around.  So seb is a convenient scapegoat.
<Burgundavia> Treenaks, daniels is currently not here
<Treenaks> Mithrandir: good point
<Treenaks> seb128: gtk should patch around it! :)
<thom> Treenaks: because firefox works and ephy doesn't
<thom> thus, i blame seb
<pitti> Kamion: seeds updated. since ubuntu-meta's update script pulls from your website, how often is that updated?
<thom> (this may be the only time i can ever say that)
<pitti> thom: it is broken in gnome-terminal, too, which makes it even more gtk-bug'ish
<seb128> thom: yeah, I was ready to reassign an epiphany bug about this to firefox yesterday :)
<seb128> and gedit
<seb128> and nautilus
<pitti> i. e. in all gnome apps :-)
<seb128> bah
<seb128> IZ NOT GTK BOG
<seb128> (let's try if that way can convince people :p)
<pitti> no, it's a damn x.org bug
* pitti tries to relogin
<pitti> brb
<pitti> hmm, no luck
<pitti> seb128: any idea which files I have to delete to reset my gnome keyboard settings?
<seb128> ~/.gconf/desktop/gnome/peripherals/keyboard/ I would say
<pitti> seb128: that didn't help, but removing my ~/.gconf* did :-) (of course I lost all my other settings, too...)
<seb128> bah
<seb128> never do this
<seb128> you trash your panels, desktop, mailer, etc settings
<pitti> I removed everything that sounded like keyboard, but it didn't help, sooo
<seb128> ~/.gconf/apps/gnome_settings_daemon/keybindings/ and ~/.gconf/desktop/gnome/peripherals/keyboard/ should have the keyboard stuff
<pitti> seb128: I removed them (and some more), didn't help
<seb128> restarted gconf?
<pitti> restarted my whole session
<seb128> bah, sucks
<Kamion> pitti: ubuntu-meta's only updated semi-automatically. I'll take care of it
<pitti> Kamion: it pulls the seeds from your webpage, right? this is updated in a cronjob?
<Kamion> pitti: oh, I see. maximum lag time there is 17 minutes; I've just done it manually
<pitti> ah, cool
<Kamion> pitti: do you want to upload u-m then?
<pitti> Kamion: I can do that
<Kamion> ok, thanks
<pitti> Kamion: should the many "Skipping unavailable package " messages worry me?
<pitti> at least it seems to have worked fine
<pitti> hey, it added "firefox" to desktop-*, how odd
<Kamion> pitti: don't worry about the skips
<Kamion> pitti: used to be mozilla-firefix
<pitti> ah, right
<Kamion> mozilla-firefox
<Kamion> should also have added dselect to standard ;)
<[g2] > lamont, your page http://www.ubuntulinux.org/wiki/BuildDaemons references a "final infrastructure" can you tell me the status or where I can learn more about the final infrastructure ?
<Kamion> [g2] : that would be Launchpad
<[g2] > Kamion, THX
<Kamion> a project being developed internally by Canonical to deal with all the mechanics of running distributions
<[g2] > I'm a core dev on an embedded linux distribution (nslu2-linux) 
<[g2] > so that project is of interest to me
<[g2] > :)
<tsume> which project?
<[g2] > Launcpad
<[g2] > with an h
<[g2] > heh... the "open source universe" :)
<Lathiat> mpt: chopped.
<tseng|work> is there somewhere I can see why a package was removed from debian?
<Mithrandir> tseng|work: http://ftp-master.debian.org/removals.txt
<crimsun_> pitti: pong (sorry, work has removed me)
<pitti> crimsun_: hi! do you happen to know about the progress in ALSA?
<pitti> crimsun_: so far I experimented with enabling dmix and switching gstreamer to alsa
<pitti> (killing esd)
<KaiL> fabbione: just got a question about captive-support in kernel - do we have that in .10 or .12?
<pitti> crimsun_: however, occasionally I get cracks on I/O activity
<tseng|work> "dead upstream" :(
<pitti> crimsun_: do you know if alsa 1.0.9 is any better?
<pitti> crimsun_: I have heard that it uses dmix by default, so far I had to whack asound.conf
<crimsun_> pitti: 1.0.9 should be much improved over stock Hoary (1.0.6, though universe's alsa-source is 1.0.8)
<pitti> crimsun_: I'm not sure about the version in 2.6.12-1
<pitti> in breezy
<crimsun_> oh, that should be synced with 1.0.9rc2
<crimsun_> pitti: does gstreamer allow one to specify alsa device(s), or does it use "default"? If it does allow specifying a device, any better luck with plughw:0
<KaiL> Advanced Linux Sound Architecture Driver Version 1.0.9rc2  (Thu Mar 24 10:33:39 2005 UTC)
<KaiL> (from breezy kernel)
<pitti> crimsun_: it uses the default, i. e. ~/.asoundrc
<pitti> crimsun_: our idea is to have a small daemon listening to hal soundcard hotplug events, and if a new card is attached, we can offer to change the default device
<pitti> crimsun_: (this would change ~/.asoundrc)
<crimsun_> pitti: ah, ok. So you'd redefine pcm.!default on each ~/.asoundrc update?
<pitti> yeah, that was the idea
<crimsun_> pitti: how simple is the dmixed definition that you're using?
<pitti> of course only if the user didn't do manual tweaks
<crimsun_> right
<pitti> crimsun_: basically I added a pcm.dmix0, pcm.dmix1, etc. for the first 8 or so cards
<pitti> that should be enough for most purposes
<pitti> then I can change !default to dmix0, dmix1, etc.
<pitti> I /msged you 
<pitti> crimsun_: right now it's very simple, I didn't add any resampling etc.
<crimsun_> yep, got it
<crimsun_> looks good, though mine has ctl. definitions, too
<pitti> crimsun_: adding "rate" is difficult since we don't know what the hw supports, so the apps should just try to open it with the frequency they want
<crimsun_> (http://pastebin.com/286499)
<crimsun_> pitti: yeah, resampling is problematic and still hasn't been addressed (fixed) for dmix
<pitti> but in your version it is more difficult to change the default device, right?
<henriquemaia> Can please someone tell if this is a bug? I have rebooted my machine today and my sound just went away. The only thing i chaged was choosing xfce instead of gnome.
<doko> elmo: please could I have access to an ia64/breezy chroot with binutils build-deps?
<henriquemaia> Now i have sound again, but the configuration just went nuts.
<crimsun_> pitti: I prefer your version, though you might want to put in ctl.dmix#
<pitti> crimsun_: yeah, in any case
<pitti> later we can also switch to dsnoop, but one step at a time
<crimsun_> yes
<pitti> crimsun_: still I'm not satisfied with dmix at this stage, the quality is too poor (crackles)
<pitti> crimsun_: once this works, we can base everything on alsa/dmix and throw out esound and crap
<crimsun_> pitti: which chipset?
<pitti> VIA 82C686A/B rev50, a cheap internal one
<pitti> I also have a Logitech USB headset
<crimsun_> ah, so no dxs_support parameters passed to snd-via82xx
<pitti> that is?
<crimsun_> dxs_support is via82xx-specific for resampling
<crimsun_> there's a link on the alsa wiki that references Takashi's explanation, if I can find it...
<pitti> crimsun_: ah, modinfo snd_via82xx explains the parameter
<pitti> crimsun_: I assume 0 (auto) is the default
<crimsun_> pitti: yep, also some info here in the "DXS channels" section: http://alsa.opensrc.org/index.php?page=via8233
<KaiL> btw, what is this DXS?
<KaiL> got informations, that disabling this helps about performance problems (that shitty think seams to be 90% software)
<crimsun_> KaiL: it's Via's cheap pcm multiplexing
<doko> elmo: do we have a version schema to mark an -ubuntu version as syncable again, maybe -ubuntu1 -zapit1
<KaiL> ah
<KaiL> somethingyou shouldn't even thing about using? ;)
<crimsun_> KaiL: it really depends on the motherboard, unfortunately
<KaiL> never saw a board, where this produces a sound quality, can call call such
<pitti> crimsun_: do you think dmix works nice in general, but has just poor quality on my particular motherboard?
<KaiL> esp. compared to intel or nVidia audiochips, which are also onboard!
<crimsun_> pitti: it's an adequate interim solution on most motherboards
<crimsun_> pitti: but it's far from optimised
<pitti> crimsun_: our original problem was that commercial and legacy apps which can only handle esd don't work ATM since esd is blocking the sound device
<pitti> crimsun_: however, even with dmix opening /dev/dsp doesn't work
<KaiL> pitti: if you have the possibility to add a real sound card, do that :p
<pitti> crimsun_: so I'm almost inclined to defer this a bit
<pitti> KaiL: I even have another one here (SoundBlaster 128)
<crimsun_> pitti: yeah, there are serious problems with dmix and alsa's oss emulation
<pitti> KaiL: but testing is better with cheap chips
<KaiL> pitti: your ears don't want that testing too long *g*
<crimsun_> pitti: try using aoss (in alsa-oss package) with the app, like ,,aoss $legacy_oss-only_app''
<Mithrandir> hi trygvebw 
<trygvebw> hi
<pitti> crimsun_: I know about this possibliity, but we hoped to make it work without the wrapper :-/
<trygvebw> xfonts is broken atm?
<crimsun_> pitti: ah, true
<crimsun_> I'll have more time to look this weekend (been very busy this week with new job and such)
* trulux strikes back
<trulux> heya fellows
<pitti> crimsun_: okay, I guess I will just throw "dmix by default" at the breezy people for more widespread testing
<pitti> Hi trulux 
<trulux> pitti: howdy!
<pitti> trulux: you have mail, we need another round :-/
<pitti> trulux: I think I know where the bug is (see mail)
<trulux> pitti: yep, stupid mistake: krsec_enabled statement must be removed from __init functions
<trulux> it's still not initialized
<trulux> so, you would get everytime a NULL or 0 value
<pitti> trulux: shouldn't C_K_S_DEFAULT_VALUE just control the value of krsec_default?
<crimsun_> pitti: great :)
<trulux> the point is that we can do it in the hard way, but there's no sense (I'm talking on having the int krsec_.... = CONFIG_SECURITY_......_DEFAULT)
<trulux> pitti: nope
<trulux> pitti: don't worry about the heck, I'll bake it for you
<trulux> ;)+
<pitti> trulux: cool, please ping me if you have it ready, then I build another kernel
<pitti> trulux: (I get better at it slowly :-) )
<trulux> pitti: won't take more than 5 min
<trulux> pitti: got uplaods back: http://pearls.tuxedo-es.org/misc/lock-picking/pict0010.avi <- opening video :)
<pitti> seb128: if I enable dmix by default, we need to change gstreamer to alsa, otherwise we'll get crappy sound with esd
<seb128> pitti: k
<pitti> seb128: I change the default sink in gstreamer?
<seb128> I'll do it
<seb128> I want to upload 0.8.10
<pitti> oh, great
<pitti> crimsun_: btw, where does this mixing etc. take place? in the kernel drivers or the userspace lib?
<pitti> crimsun_: if the latter, I can update alsa-lib to 1.0.9 easily
<pitti> crimsun_: but I don't want to bother fabbione with updating the kernel drivers
<crimsun_> pitti: libasound2
<pitti> crimsun_: great! then I update to 1.0.9rc3
<pitti> crimsun_: we have 1.0.8 right now
<crimsun_> pitti: ok
<pitti> Hey jordi! just saw that you are (one of) the alsa-lib maintainers :-)
<crimsun_> -> work, bye all :)
<pitti> thanks crimsun_, see you
<trygvebw> xfonts is broken atm, or is it another package?
<ogra> trygvebw, xorg is in a complete transition atm....
<trygvebw> ogra: ok :)
<ogra> will take some days..
<trygvebw> the c++ api change?
<ogra> thats something else
<trygvebw> okay
<Mithrandir> no, the "get rid of /usr/X11R6" change, I think.
<ogra> yep
<ogra> :)
<trygvebw> ah :)
<AndyFitz> so how broken are the c++ packages today ? :D 
<tseng|work> it wasnt bad yesterday
<tseng|work> only aspell and pspell were broken on my system
<tseng|work> broken as in, cant upgrade
<tseng|work> xorg was pretty broken
<AndyFitz> ouch
<AndyFitz> okay so dist-upgrade is out of the question still
<AndyFitz> package by package I'll walk this limbo of uncertainty :-P
<tsume> tseng: font path was broken, xorg wasnt
<Kamion> I think we need a symlink in the old font path location really; can't expect everyone to have dexconf-managed xorg.conf
<trulux> pitti: sent
<pitti> yay
<trulux> pitti: another one being sent
<trulux> pitti: I think I didn't refpatch the stack so you will get a semi-fized one without the _enable check
<trulux> one sec and I'll upload it
<pitti> go alsa 1.0.9, go!
<Kamion> ogra: you don't need to put "changed distribution to breezy" in the changelog
<Kamion> it's implicit
<pitti> trulux: I have one mail now
<Kamion> unless there was some actual change in the package that goes further than just adding a new changelog entry :)
<ogra> Kamion, yep, doko already told me, but i was to lazy to rip it out again, it does no harm :)
<trulux> pitti: now it will be on http://pearls.tuxedo-es.org/patches/security/kern-security-1.patch for all time
<AndyFitz> wait,  is evolution okay ?
<ogra> here it is
<AndyFitz> sweet,  thanks ogra
<tseng|work> hi ogra
<zyga> hello :-)
<pitti> trulux: okay, I downloaded the patch, I'll build a new kernel
<ogra> hey tseng|work 
<CarlK> Kamion - mind taking 30 seconds to look at https://bugzilla.ubuntu.com/show_bug.cgi?id=10974
<CarlK> If it takes more, I can wait till later
<Kamion> CarlK: I just coincidentally replied to it; I didn't see your IRC comment until afterwards
<Kamion> CarlK: looks to me like you're using a hoary initrd
<CarlK> yep.
<CarlK> my manual one was initrd=ubuntu-breezy/initrd.gz
<CarlK> thanks.
<Kamion> no, what URL
<Kamion> I'm not interested in the paths on your local filesystem. :)
<CarlK> nuf said.. the worng one.
<Kamion> oh, right :)
<Kamion> ok
<CarlK> I figured it was me
<CarlK> 1/2 figured I would see it just creating the bug report
<pitti> trulux: you are sure this is enabled by default now? 
<CarlK> Kamion - it is working now, just in case there was any doubt ;)
<tja> kamion: my grub-install patch is otherwise ready, but it uses sed to fiddle with the "# password .." line in menu.lst, and I'm unable to pass the variable inside the sed-script so that the actual password doesn't interfere (it has dollar signs most likely..)
<Kamion> CarlK: good :)
<Kamion> tja: um, why does it need to use sed? grub-installer generates menu.lst itself
<tja> no it doesnt ;)
<Kamion> note grub-installer != grub-install
<tja> it gets the barebone version from update-grub
<Kamion> oh, sorry, yeah, you're right
<tja> where the password line is at
<Kamion> confused with other *-installer packages
<tja> so yes, I could just cat the line to the end of it, but it's not beautiful ;)
<Kamion> you could pipe the password itself through sed to escape any metacharacters first
<Kamion> or you could do the whole thing with 'while read' and 'case'
<tja> ok, i'll experiment
<Kamion> or you could use sed's 'r' command
<Kamion> (read contents of file)
<Kamion> that's probably the best option actually, busybox supports it
<pitti> jordi: ping
<jordi> pitti: pong
<pitti> jordi: did you happen to take a look at alsa-lib 1.0.9rc3? I'm packaging it right now
<pitti> jordi: upstream splitted off the plugins into a separate upstream tarball
<pitti> jordi: for now I merged it back into the orig.tar.gz to not deviate from Debian too much, but in the end the source package should be split
<pitti> jordi: is this okay for you?
<jordi> pitti: hey hey hey
<jordi> pitti: experimental!
<jordi> oh, of course, we haven't uploaded plugins yet.
<pitti> jordi: oh fuck, I should have looked earlier...
<jordi> pitti: have a look at svn.d.o, it's all in there, but we haven't uploaded plugins yet.
<jordi> the rest is in experimental
<jordi> jdthood rocks
<pitti> jordi: I don't need the plugins
<pitti> elmo: please sync alsa-lib from experimental
<pitti> jordi: I'm glad that I finally caught you :-) otherwise I had wasted even more time now ...
<jordi> pitti: back in 10
<jordi> pitti: yeah. experimental is sometimes a treasure :)
<bluefoxicy> I need something to monitor my CPU temperature with
* pitti hands bluefoxicy a thermometer
<mkde> *grins*
<bluefoxicy> when I got my amd64 a year ago someone recommended I not use lm-sensors and instead use something else that didn't need a kernel module (lm-sensors needs an i2c driver for your mobo)
<bluefoxicy> so I had some program that was drawing graph lines around 39.5C for my CPU and 40C for my mobo
<mkde> bluefoxicy, did you try asking in #ubuntu? They should be able to help
<bluefoxicy> but nobody in like 5 channels on freenode knows wtf the program is
<bluefoxicy> mkde: nobody in #ubuntu knows :(
<bluefoxicy> I come in here because you people are sticking stuff in ubuntu so somebody here has to know if the package is in ubuntu :P
<mkde> you didn't try lm-sensors?
<ogra> bluefoxicy, /proc/acpi/thermal_zone/
<bluefoxicy> ogra:  empty
<bluefoxicy> mkde:  xsensors displays a blank screen, and crashes when i close it
<ogra> bluefoxicy, try to load "thermal"
<bluefoxicy> mdke:  lm-sensors. . .. I can't find the command for
<bluefoxicy> bluefox@icebox:~$ modprobe thermal
<bluefoxicy> bluefox@icebox:~$
<bluefoxicy> uh
<ogra> now look again
* JaneW thought today was friday - been a long week!
<JaneW> :/
<bluefoxicy> ogra:  nothing, and I just did that as non-root
<mkde> bluefoxicy, you can easily find a guide to lmsensors on the net i'm sure
<ogra> bluefoxicy, oh
<mkde> http://www.ubuntuforums.org/showthread.php?t=2780&highlight=lmsensors
<ogra> bluefoxicy, anyway, amd64 should support the thermal module (at least i havent seen one that doesnt until now)
<bluefoxicy> mkde:  I didn't have to have it before, didn't have to configur anything beyond right-click and pick "motherboard" from a list or anything; it's not that I can or can't do it, it's just that I don't think it's appropriate to not have to do work one day and then later have to do work to get the same damn thing.  :/
<Mithrandir> ogra: the opterons doesn't generally.
<ogra> ah, ok, i only know amd64's so far
<mkde> heh that lm-sensors guide is pretty good
<mkde> need to port that to the wiki
<Mithrandir> ogra: s/amd/athlon/ :P
<ogra> heh :)
<CarlK> Kamion - why did it change from /ubuntu-breezy/ to /ubuntu/?
<bluefoxicy> wow
<CarlK>  [19/May/2005:09:27:41 -0500]  "GET /ubuntu-breezy/pool/main/a/acpid/acpid_1.0.4-1ubuntu4_i386.deb
<bluefoxicy> that worked, but it was way too much work :/
<bluefoxicy> lokks much prettier than what I had before though
<CarlK>  [19/May/2005:09:28:52 -0500]  "GET /ubuntu/dists/breezy/Release.gpg HTTP/1.1" 404
<bluefoxicy> .  . .
<bluefoxicy> I believe it's broken
<bluefoxicy> as it seems to be refreshing every 500mS
<bluefoxicy> and my mobo temp seems to be going 43, 54, 68, 32. . . . . 
<mkde> bluefoxicy, way too much work was 2 minutes?
<bluefoxicy> I don't think motherboard temperature can jump that far in less than a second
<zyga> bluefoxicy: hello :-)
<bluefoxicy> mkde:  yes.  Put your stupid mom who can barely remember how to log into windows on it (typical computer user) and you'll see.
<zyga> bluefoxicy: insulting leads to dark side of open source
<bluefoxicy> CPU temperature reporting is useful if you've got a laptop.
<ogra> CarlK, ubuntu-breezy ?
<zyga> ;] 
<bluefoxicy> zyga:  have you seen my mom?
<bluefoxicy> she has a hard time saving files after like 10 years on the computer
<ogra> bluefoxicy, is sh around ?
<mkde> bluefoxicy, my mom doesn't use lm-sensors
<zyga> bluefoxicy: no
<bluefoxicy> she can never find them (Linux helps because they're all in the same place)
<ogra> she even
<zyga> bluefoxicy: but you said 'your' ;-)
<bluefoxicy> mkde:  mine doesn't either.
<mkde> cool
<zyga> bluefoxicy: I've made some modifications to malloc.suxx.pl
<bluefoxicy> heh
<zyga> bluefoxicy: I'm going out now but I'll be back in an hour
<CarlK> orga - I am doing a lan install CD is mounted under ubuntu-breezy
<bluefoxicy> well at least my CPU is a stable 35C
<bluefoxicy> what are these, 40mm fans?
<ogra> CarlK, ahh
<CarlK> orga - preseed has d-i     mirror/http/directory   string /ubuntu-breezy
* bluefoxicy needs 2 more case fans
<CarlK> which works for a while, then it 'forgets' that setting
<bluefoxicy> oh guys
<bluefoxicy> should my +3.3v vcore be reading +6.59v?
<bob2> yes, that's why it's called +3.3v
* ogra yays for logic
<Kamion> CarlK: erm ... it didn't change? /ubuntu-breezy/ was your setting, not ours
<CarlK> see the 2nd log line?
<bluefoxicy> http://i2.photobucket.com/albums/y10/bluefoxicy/sensors.png
<CarlK> no breezy
<Kamion> CarlK: oh, could be the second stage? is that after the first reboot?
<CarlK> um... yoy are asking me? ;)
<Kamion> CarlK: yes, I'm asking you what your machine is doing :-)
<HrdwrBoB> +3.3V:     +8.16 V  (min =  +0.00 V, max =  +8.16 V)   ALARM
<HrdwrBoB> ^ my 3.3V is stuffed
<Kamion> CarlK: you haven't preseeded base-config
<pitti> trulux: kernel is ready, cross your fingers...
<Kamion> CarlK: at least not the same way
<Kamion> base-config     apt-setup/directory     string /ubuntu
<Kamion> that's from your preseed file - make that /ubuntu-breezy
<CarlK> got it
<Kamion> CarlK: (I initially thought you meant that /ubuntu-breezy/ was a default setting or part of a URL or something, hence my brief confusion)
<CarlK> ok, I found it.  there wasn't a hoary near it, so my "look for hoary and change things to breezy" fell apart
<CarlK> and I figured out how to have pxeboot timeout and boot the hd, so I don't notice the reboot anymore
<Kamion> CarlK: (how, out of curiosity?)
<Kamion> we should document that
<CarlK> good Q ;)
<CarlK> I was going to try and figure out exactly what I DL from where
<CarlK> gime a sec.. I'll post the revelant lines and you can tell me if it looks familiar
<Kamion> it won't look familiar, I've never done this myself
<pitti> trulux: AAAAAARGH!
<pitti> trulux: it still doesn't work
<tja> kamion: I have the patch ready, how do you like to have it?
<Kamion> tja: bugzilla.ubuntu.com, component grub-installer, enhancement
<tja> ok
<CarlK> is the wiki "closed"?
<Kamion> if you can't stand bugzilla, mail to cjwatson@ubuntu.com works too, but I'm more liable to forget that :)
<CarlK> I am logged in, but can't find "edit"
<CarlK> nm.. had to bounce around
<dholbach> hellas!
<ogra> hey dholbach 
<dholbach> ogra: hey oliver! :-)
<mako> thom: did you get to those torrents?
<mvo> hey dholbach 
<dholbach> mvo: hey michael :-))
<CarlK> Kamion - find "ontimeout hdboot" on https://www.ubuntulinux.org/wiki/LocalNetInstall
<CarlK> which runs syslinux/chain.c32 hd0
<jdub> yo dholbach 
<dholbach> jdub: hey jeff, how are you?
<jdub> rocking, yourself?
<dholbach> i just introduced 20 people into the delights of keysigning parties - it was fun :-)
<ogra> heh
<jdub> ugh ;)
<dholbach> jdub: ha, i knew you'd like that :-)
<bluefox> is X broke in breezy
<dholbach> jdub: see it that way: if i make them motus next, they even come with a decent key :-)
<bluefox> particularly, cant find the font 'fixed'
<bluefox> and thus refuses to start
<jdub> bluefox: dpkg-reconfigure --priority=low xserver-xorg
<bluefox> jdub: trying
<jdub> and then restart X
<dholbach> bluefox: and tell us, if you run into ctrl-key funniness
<seb128> dholbach, jdub: so this bugs ml? :)
<jdub> seb128: ok, lets figure this out
<jdub> seb128: ubuntu-gnome-bugs@ ?
<dholbach> jdub, seb128: yeah :-)
<seb128> right, sorry to insist, but the sooner the better
<jdub> i can do it straight away, let's just work out the best way forward
<seb128> jdub: would be nice for the gnomish stuff out of the desktop yep
<jdub> seb128: or perhaps just gnome-bugs@ ?
<seb128> hum
<jdub> we have kernel-bugs@ atm
<seb128> we agree on the 2 lists?
<seb128> one for the desktop and one for motu-gnome stuff?
<dholbach> one for the gnome, i'd say
<dholbach> s/the//
<dholbach> and it'd have more traffic than most ubuntu-<country code> lists :-)
<seb128> dholbach: that doesn't work, I want to read all the desktop mails, I don't care reading mails about an obscur gnomish universe stuff
<dholbach> hrm
<Kamion> CarlK: ah, cool
<dholbach> jdub: your opinion?
<seb128> that's like the user list, you read the threads and flush
<jdub> seb128: are you interested in desktop infrastructure bugs, like, freedesktop stack stuff?
<seb128> jdub: yep, all desktopish I would say
<CarlK> Kamion - where are the docs for what is currently included?
<dholbach> seb128: we'd have to assign bugs to "gnome" for universe and "desktop" for main-stuff?
<seb128> dholbach: right
<dholbach> seb128: and we should tell the launchpad guys over and over again that we need mail adresses for teams
<jdub> seb128: ok, so if you're happy with desktop-bugs@ then i think we need to consider something a bit different for MOTU stuff
<seb128> dholbach: we can't be efficient on the universe traffic
<dholbach> i didnt figure out where to put it yet
<jdub> dholbach: yes, yes, yes - this is how i think we should handle MOTU stuff
<seb128> jdub: happy with desktop = all the desktop stuff - kde
<dholbach> dholbach, seb128: one for WHOLE UNIVERSE?
<seb128> dholbach: stop speaking to yourself, big freak :)
<Kamion> CarlK: what do you mean?
<jdub> dholbach: madness. :-)
<dholbach> would be good for a bug-bot though
<jdub> dholbach: launchpad team aliases for bugs
<dholbach> seb128: stop stopping me from something :-)
<jdub> so if there's a "universe gnome" team, it can have a bugs alias
<seb128> jdub: how the alias works?
<jdub> in launchpad, could be as easy as checking the "i am interested in this team's bugs" box :-)
<CarlK> Kamion - syslinux/chain.c32 was something I added, but maybe the current pxe "thing" has something similar
<dholbach> jdub: if we had that...
<Mithrandir> I wonder how many different kinds of drinks (coffee, tea, beer) launchpad will be able to make.
<jdub> seb128: team has a package on its list, bug mail sort through who needs to get each mail, etc.
<seb128> jdub: have you already tried malone? You can't even search for bugs or comment while closing a bug atm...
<seb128> not sure on how long it will take to get the nice features
<jdub> seb128: gotta get our use cases on their agenda :-)
<seb128> right
<jdub> brb, reading specs for a sec :)
<seb128> and figure a way to work now too :)
<seb128> k
<jdub> for now, i'm happy to do desktop-bugs@
<dholbach> tried it again: no way to add a mail adress to a team
<Kamion> CarlK: not aware of any documentation of what's there at the moment
<Kamion> CarlK: apart from whatever's in the syslinux package
<tja> kamion: "you got mail" ;)
<mkde> mako, got a moment?
<seb128> jdub: ok, let's do it
<seb128> jdub: what do we do for bugzilla? list as QA?
<jdub> seb128: yeah
<jdub> seb128: un momente :)
<seb128> feel free to give me admin rights I can do this
<seb128> there is also a couple of GNOME stuff assigned to debzilla atm
<Kamion> tja: yup, saw it, thanks
<tja> np
<tja> should it work if I just opened the g-i.udeb for hoary and applied the patch?
<jdub> seb128: you'll get an email in a sec about list creation - ignore it for the moment
<seb128> k
<Kamion> tja: yes, although if I were you I'd just rebuild it instead - grub-installer.udeb isn't hard to build, and it doesn't matter much what environment you build it in
<ogra> MOTU meeting starts now....
<jdub> seb128: you're set to go in bugzilla and mailman :)
<seb128> thanks :)
<mako> mdz: yes
<mako> sorry
<jdub> thom: http://www.livejournal.com/users/kernelslacker/12170.html
<mvo> mjg59: around? a friend of mine is asking for help with his evo laptop. it looks like it don't support s3 or s4
<tja> kamion: not so easy to test, because either way the mdsum is different so the installer won't accept the patched version ;)
<tja> but it should work, tried it with a test script
<jdub> ha ha ha
<jdub> "Something else that's been done in quite a few daemons on fc4 is not starting them by default."
<jdub> *tap*tap*tap* ... is this thing on?
<jdub> :-)
<Kamion> tja: yeah, you need to tweak the md5sum in Packages and Packages.gz, then regenerate Release, and probably remove Release.gpg. it's awkward
<CarlK> Kamion - looks like the "boot local drive" can be done without any new files... I'll let you know when I have it working
<tja> Kamion: sound like great fun
<Kamion> tja: in practice I tend to just edit bits of shell script on the fly during installation, but the chief case where that doesn't work is if you have new debconf templates (there's no easy way to tell cdebconf about them)
<tja> i've done that as well
<tja> but in this case it is close to impossible, because it is a postinst-script..
<Mithrandir> Kamion: hmm, is that something we want to be fixed?  I imagine it would be easy enough to fix?
<Kamion> tja: hardly impossible - /var/lib/dpkg/info/grub-installer.postinst
<Kamion> I edit postinsts all the time
<Thom_Holwerda> ah the topic is the answer to my question :)
<Thom_Holwerda> installed the breezy updates but it messed me system up, but the topic explains why :)
<Kamion> Mithrandir: yeah, I'd like to figure out exactly why it doesn't work - it's something to do with the exact times at which cdebconf loads and saves
<tja> kamion: ah, of course.. need to lower debconf-priority to catch that
<Kamion> tja: why so?
<trulux> back from class
<tja> now it just churns along until it tries to boot
<tja> ;)
<Kamion> tja: grub-installer is unpacked quite early on in the installation, at "retrieving installer components" - you've got *loads* and *loads* of time to edit it
<Mithrandir> Kamion: you'd need to send it USR1 to save, then edit, then USR2 to reload or something.
<Kamion> Mithrandir: the X_SAVE command is better ...
<Kamion> Mithrandir: anna uses X_LOADTEMPLATEFILE or similar - we should just provide a simple command-line interface to that and make it work properly
<Mithrandir> Kamion: you need to talk to the running cdebconf, though.
<Mithrandir> hmm
<Kamion> Mithrandir: yeah, true
* Mithrandir thinks of a nice^Wevil hack.
<Mithrandir> Kamion: cdebconf could have a fifo or unix socket it listened to for random commands.
<Kamion> I *knew* you were going to say that. :-)
<Mithrandir> I was actually going to suggest something far more evil.  Multiple simultaneous frontend support.
<Mithrandir> that's a lot harder to get right, though.
<Kamion> that would be better - there are use cases now for running full-screen cdebconf stuff on tty2
<Kamion> anna-install does that
<Mithrandir> it should be _possible_.
<Mithrandir> I just wonder how you'd handle the case where you had two frontends which are both interactive.
<Mithrandir> you might need to say "hey, refresh" to one of them.
<Mithrandir> but that's doable.
<jnc> does anyone else find troublesome the "Ctrl+X" shortcut in evolution is set up to send the message?
<Mithrandir> to a certain degree.
<jnc> like, the shortcuts are all changed.  what's going on, i wonder
<jnc> ctrl+L  no longer activates the location dialog as it used to, even though the shortcut is there in the menu
<Mithrandir> Kamion: hmm, that should be doable, shouldn't it?  Just call the frontends in a non-blocking loop and ask them "ARE WE THERE YET?" until you get a "yea" back.
<seb128> jnc: bugzilla usually knows about bugs
<seb128> this one is a xorg issue
<Kamion> Mithrandir: scares me though :)
<Kamion> somebody else can do that ...
<Mithrandir> Kamion: why?  Because it involves ripping apart cdebconf?
<Kamion> oh, yeah, only the most critical piece of code in the installer
<Mithrandir> well, cdebconf is easy.
<Kamion> and I have a *lot* of other things to do. :-)
<Mithrandir> and nice and fairly tidy.
<Mithrandir> but then, I should be writing my thesis.  And moving.
<jnc> seb128: 'k
<jnc> seb128: i was wondering, since the shortcuts are all crazy-like :0
<jnc> thanks
<jnc> i keep hitting ctrl+x today and sending emails before they're finished! :-P
<jnc> my co-workers are wondering what is wrong w/ me
* jnc :)
<trygvebw> what's freepascal called in Ubuntu?
<Mithrandir> fpk-*, I think (but it doesn't exist for amd64, so I'm not sure)
<trygvebw> okay :)
<trygvebw> thanks :)
<Mithrandir> apt-cache search free pascal ought to tell you.
<trygvebw> ok
<trygvebw> no results :/
<trygvebw> looks like there is no freepascal package in universe :/
<dholbach> you could put it on http://wiki.ubuntu.com/UniverseCandidates
<trygvebw> okay :)
<trygvebw> i'll do that
<dholbach> ROCK! :-)
<trygvebw> :p
<trygvebw> so i'll just add it to the list along with a small description?
<dholbach> and add the homepage
<dholbach> and maybe why you think it rocks and we really should have it
<trygvebw> ok
<tja> kamion: the patch doesn't work ;) there's at least one typo
<trygvebw> added
* mvo goes to play some hockey
<dholbach> bye mvo
<tja> oh what a difference one slash in a wrong place does..
<tja> kamion: it works now ;)
<svenl> Kamion: can it be that ubuntu-installer or liveCD has trouble with atkbd ?
<svenl> Kamion: i didn notice, but itr seems my at keyboard doesnt react on pegasos. USB does work though.
<Kamion> svenl: any particular version?
<svenl> Kamion: hoary live CD, as found on the DVD.
<svenl> Kamion: BTRW, i suppose the super-DVD does include the sources also ? 
<Kamion> svenl: weird, it's got the right versions of stuff to be able to deal with atkbd ...
<Kamion> svenl: no, it's a combined install/live DVD, I don't think sources fit
<Kamion> although I could be wrong there, I didn't try to bludgeon debian-cd into doing that
<Kamion> and atkbd is in input-modules too ...
<svenl> maybe my board isflakey.
<svenl> it keeps crashing, will have to try again.
<svenl> Kamion: do you want a forth script to emulate the yaboot stuff ?
<svenl> Kamion: there is 1.5 Gb free on the DVD on powerpc.
<Kamion> svenl: yes, and sources for just the normal install CD take up *four CDs*
<Kamion> so that suggests it won't fit
<svenl> Kamion: too bad it doesn fit.
<Kamion> svenl: forth> yeah, that would be cool, thanks
<svenl> remember me your email address.
<svenl> Kamion: (smoe routine on it is a of dubious freeness, since it was inspired from some code publicly posted on some japanese apple forum.
<svenl> ok, live CD is starting ubuntu.
<svenl> Kamion: also, what is the relationship between ubuntu and kubuntu CD/DVD wise ? 
<jdub> they are like sisters
<jdub> mostly the same, but one is shorter with a crooked nose
<svenl> jdub: :)
<svenl> jdub: the question being if kubuntu can also be installed from the combined DVD, and if so how ?
<haggai> jdub: yeah you really should get a proper nose job for gnome
<jdub> the kubuntu CDs have different packages on them
<jdub> i don't think you can install kubuntu directly from the DVD
<svenl> jdub: so you could fit kubuntu in the combined DVD also, and an additional kubuntu live image too ? 
<svenl> (having 1.5 GB free).
<svenl> Mmm. I think my board is having some stability problems, will try another one.
<jdub> unless i'm smoking really bad crack, the DVD already has all of the KDE stuff on it (being in main)
<jdub> but a kubuntu DVD would have a kubuntu live image and be set up to install kubuntu by default
<svenl> jdub: well, it would be set to propose both ubuntu and kubuntu, and the ability to use boath images.
* ogra wonders what a nose job might be
<Kamion> svenl: cjwatson@ubuntu.com
<jdub> ogra: plastic surgery
<Kamion> jdub: it's not all of main, it's only Ubuntu supported
<jdub> svenl: that would be ooky
<ogra> lol
<Kamion> we have a separate Kubuntu DVD
<jdub> Kamion: ahr, that is different
<jdub> ogra: it's not something sexual that involves noses (this is a common misconception)
<ogra> hehe
<svenl> Kamion: atkbd was wrong alarm, works fine on another board, i guess thefirmware test board is dying out.
<Kamion> ah, ok
<svenl> Kamion: would not both ubuntu and kubuntu fit on the same DVD ? 
<hunger> Why was mozilla-firefox renamed to firefox?
<jdub> hunger: trademark issues
<hunger> That's tricky of those mozilla guys!
<hunger> "Hey, firefox db people we will call it mozilla-firefox, no worry"
<hunger> and then they "force" people to drop the mozilla- later on.
<zyga> firefox package got renamed?
<Kamion> er, dude, it was the fire*bird* database
<Kamion> that's why firebird was renamed to firefox
<hunger> Kamion: Oh...
<Kamion> svenl: don't think so, although I haven't done the exact maths
<svenl> Kamion: bad.
<wasabi_> Man ya'll rock.
<wasabi_> It's like, everybody I talk to lately is like "oh I use Ubuntu!"
<svenl> Kamion: altough i guess if there is 1.5GB free, this is two CDs worth of stuff.
<wasabi_> Totally unrelated channels and things.
<svenl> Kamion: live cd worked on peg.
<svenl> Kamion: i just put the menu (modified for netboot) and the generated vmlinuz on my tftp server, put the DVD in the drive, and booted.
<CarlK> svenl - what is peg?
<svenl> CarlK: the pegasos computer : http://www.pegasosppc.com
<CarlK> svenl - got it.  
<CarlK> svenl - and you are running the live DVD over a lan?
<svenl> nope.
<svenl> only booting the kernel+initrd, altough i believe the lan would be faster than the shitty DVD drive i was using.
<svenl> (it died when i started openoffice).
<CarlK> svenl - ah, just as a way to boot the DVD?
<svenl> CarlK: yes, since we don quite support yaboot yet.
<CarlK> is that what knoppix uses?
<ogra> CarlK, yaboot is ppc's bootloader
<svenl> Kamion: do you have some kind of CD/DVD media label or whatever that graphic thing is called, which can be used to print such DVDs ? 
<svenl> (and are there any kind of legalese issues involved in it ?)
<ogra> CarlK, (and pegasos is not apple ;) thus it makes some problems)
<Kamion> svenl: I don't, no idea if we do
<svenl> Kamion: i mean, we are interested in giving out such a ubuntu DVD with each pegasos board we sell or something such.
<svenl> Kamion: i guess the ones you give out come with something, when you order them ? 
<Kamion> svenl: you might ask info@canonical.com, they might have a clue
<svenl> Kamion: who would be the best person to ask about this ? 
<svenl> ok.
<CarlK> ogra  thanks
<Kamion> svenl: er actually make that info@ubuntu.com, not sure if they're the same people
<svenl> ogra, CarlK : the pegasos is more akin to IBM rs6k chrp boxes than powermacs, all being chrp though, so the same code should work on all of them.
<ogra> shuld :)
<ogra> +o
<svenl> ogra, CarlK but the yaboot is sucha shity code base that it has ugly apple specific hacks. And we have some bug with reading from isos in our OF i am currently fixing.
<svenl> Kamion: cool.
<svenl> Kamion: who is behind info@ubuntu.com ?
<svenl> Kamion: can i use preseeding to make the install default to nobootloader ?
<Kamion> svenl: behind it> don't know the current set of people
<Kamion> svenl: preseeding> the only way I can think of is to use an early_command to 'ln -s /bin/false /var/lib/dpkg/info/yaboot-installer.isinstallable'
<svenl> I think i would need to fix the nobootloader package to install and call mkvmlinuz, and preseed u-i to call nobootloader instead of yaboot-installer, and it should work.
<svenl> apart from the gigabit ethernet driver, but that is something i don want to meddle with.
<\sh> svenl: what about the sponsorship with gentoo?
<svenl> \sh: what about it ? 
<svenl> \sh: i mean, the gentoo folk sell our machines from their web site, but the main distro running on the machines have always been debian, and will be as long as i am involved in it.
<svenl> \sh: but the current sorry state of debian/sarge X packages means that it is not possible for me to easily give out debian with the machine, if i don want to get into loads of problems.
<svenl> I will see if i can fix sarge once it is released and provide our own version, but ubuntu is nice to give out to the unsuspecting users out there.
<Kamion> svenl: r27729 should make the necessary preseeding less gory in the future
<svenl> Kamion: r27729 of what ? 
<Kamion> d-i
<svenl> Oh. Ok.
<\sh> svenl: wasn't it morphos as default?
<svenl> i mailed info@, let see what they reply.
<svenl> \sh: well.
<svenl> \sh: morphos is nice and all, but i am a linux guy, so ...
<\sh> svenl: so u r not directly connected to genesi?
<Kamion> svenl: do you think merging my yaboot-installer stuff for Pegasos back to Debian would be a good idea? The main concern I have is that it would be awkward if your Open Firmware revision is too old to support yaboot.
<svenl> \sh: also i think all the morphos guys are kind of interested in a working linux stuff.
<Kamion> I suppose if I could check the OF revision in some way from debian/isinstallable, that would be workable.
<svenl> Kamion: i would merge it but not enable it.
<svenl> Kamion: yes.
<Kamion> svenl: so leave out chrp_pegasos from the subarchitecture line, you mean?
<Kamion> can do
<svenl> Kamion: tomorrow or this WE, i will mail you with some info to check the OF revision. I was thinking about exact that this afternoon :)
<Kamion> or indeed I could let you boot with yaboot-installer/skip=false or similar on Pegasos
<svenl> \sh: nope.
<\sh> svenl: i was a bit concernced about the writings on morphos websites concerning payments from genesi...it's not a good PR work
<svenl> \sh: i have been working for genesi this past years to do linux/debian/open-source/whatever port and user support.
<svenl> \sh: well, the truth is that the morphos guys decided to commit collective suicide some month ago, and there where lot of internal disagreement.
<svenl> \sh: and the one guy behind those website you talk about, was doing so without the accortd of the rest of the team, and was not really honest about his claims anyway.
<svenl> \sh: who are you anyway ? 
<ogra> heh
<svenl> ogra: :)
<ogra> svenl, \sh is one of our upcoming MOTUs
<svenl> dict MOTUs ...
<ivoks> uh...
<ivoks> fight? :)
<\sh> svenl: just a critical reviewer of OSS universe ;)
<\sh> ivoks: no :) 
<svenl> \sh: morphos is all but OSS though.
<ogra> svenl, the guy you can poke for kubuntu-universe stuff in the future ;)
<svenl> ogra: oh.
<\sh> svenl: well...I just got in contact with this story, when gentoo started over with their pegasos selling things...
<svenl> ogra: what does the MOTU stand for ? 
<svenl> Master Of The Universe ?
<ogra> we are the MASTERS OF THE UNIVERSE !
<svenl> \sh: well.
<ogra> yeah
<svenl> i found it all by my self :)
<ogra> we expand the universe ;)
<ivoks> masters, masters... master of puppets...
<\sh> MOTU is everything...MOTU is the way of life...MOTU is the mother of all broken hearts and ex- and going to be ex- ISH employees
<svenl> \sh: well, it is old story, and well, if a closed group like the morphos guys start infighting, you get this kind of stuff.
<ivoks> herve: welcome :)
<ivoks> herve: i knew you will come
<\sh> svenl: that's the reason why I'm asking questions :)
<svenl> \sh: i think their discussion was open, but they kicked out their bad elements, and are sailing forward again.
<\sh> always trying to find the real truth behind all rumors
<\sh> btw...at least for one day, hurd was ready to run ;)
<svenl> \sh: still, they are a closed source OS, and of little interest to me :)
<\sh> svenl: but i'm interessted in this pegasos thingy...
<svenl> \sh: interestedin what ways ? And maybe we should go discuss this privately ? 
<surak> Kamion:
<surak> Some machines do not reboot correctly with ubuntu-live
<Kamion> surak: hi. bad timing I'm afraid, I've got to run - my fiancee just lost her engagement ring down the sink and I need to go and resolve the panic
<ogra> argh
<Kamion> surak: can you mail me with details? cjwatson@ubuntu.com - that way I can respond during my daytime, since we don't seem to be syncing up very well with timezones
<surak> This is due to old microcode.
<Kamion> check whether the various reboot= flags help
<Kamion> I know some laptops need reboot=b
<surak> if you update the microcode, it reboots correctly.
<CarlK> is there a command to "reboot now, don't unmount/shutdown anything" ?
<CarlK> if there is, I can stop pulling the power cord
<herve> carlK, try the power button!
<CarlK> herve - that runs some shutdown script
<CarlK> and pulling the plug is quicker than holding it down for 5-10 seconds
<ogra> disable the script ;)
<surak> Breezy does not run on sis videocards...
<zyga> surak: are you sure?
<zyga> surak: I've got a sis mobo with built in video card
<surak> at least the one I'm trying here
<zyga> surak: I run hoary though
<surak> hoary is ok
<zyga> surak: breezy does not run much stuff ATM :>
<surak> breezy is not
<zyga> s/run/run correctly on/
<CarlK> on the live cd, is sources.list RO or can it be edited?
<CarlK> apparently all my live CD's are somewhere safe
<surak> CarlK: it can be edited (i just erased it)
<CarlK> heh
<CarlK> thanks
<CarlK> so for a "tech", it is easy enough to add repos?
<CarlK> I should just burn one and see for myself...
<surak> you can add a repo. have in mind the fact that it puts everything on ram when running live (kinda oubvious though)
<CarlK> yeah - I did this:
<CarlK> http://dabodev.com/wiki/LiveCDDaboDemo
<CarlK> and on the topic of virus scanning using Captive NTFS was sugesting that it is easy enought to add repos (becase I thought I had) and some said " on live-cd  it is NOT easy to install any repo. "
<CarlK> but before I dispute that, "I" need to do it
<CarlK> not that I don't trust you, but I want to be able to list what I did, not what I heard
<CarlK> I suppose if you had said "No, you can't, it is RO" then I would have seen what the problem is
<ogra> but the synaptic way isnt hard at all...
<CarlK> even better
<CarlK> woo.. just got pxe to boot the local drive with no extra files
<herve> CarlK: keep the power button pushed for several seconds
<CarlK> herve - I don't have that many extra seconds, plug is quicker  ;)
<zyga> CarlK: why do you want to do that BTW?
<zyga> CarlK: not syncing drives can hurt alot ;] 
<ogra> liveCd testing
<CarlK> live CD and installing where I am goint to let the install wipe the HD clean
<herve> CarlK: you'll just burn you power supply... if you're lucky!
<CarlK> pulling the plug is bad for the PS?
<stuNNed> human icons seems buggy i'm guessing
<dholbach> hey bob2 
<dholbach> see you guys tomorrow
<dholbach> have a nice evening
<seb128> 'night dholbach 
<dholbach> bye seb128 :-)
<dholbach> *wave*
<surak> night
<seb128> see you tomorrow :)
<seb128> daniel :)
<lamont> Kamion: you around?
<surak> lamont: Kamion seems to be looking for his fianc engagement ring inside the plumbing :-)
<ogra> lamont, he's LOTR today
<Treenaks> ogra: Gollum?
<lamont> oh.  that's no fun./
<ogra> Treenaks, *g*
<herve> :)
<surak> ogra: LOTR?
<ogra> surak, lord of the ring
<surak> oh! :-)
* \sh 's darth vader today 
* Treenaks just got back from Ep3
* \sh saw it yesterday as preview :) 
* Treenaks hates you now
<\sh> Treenaks: in the "non-translated version" *phew*
<Treenaks> \sh: that;s the only one we get here in .nl
<Treenaks> \sh: maybe some subtitles.. but no dubbing
<\sh> 200 people in the cinema :) and sold out
<Treenaks> uh mine had ~80 places left :)
<\sh> Treenaks: official start for germany is today :)
<Treenaks> (but it was the 17:00-19:30 show.. so nobody came: everybody wanted dinner ;))
<\sh> woot?
<\sh> mvo: cud12k-01.ish.de ?
<\sh> wow
<mvo> hey \sh 
<\sh> mvo: u never said u our customer ;)
<\sh> +r
<mvo> \sh: I didn't knew that your work for ish
<\sh> mvo: ok..so i could bug u for a alpha test for new cable profiles :)
<mvo> \sh: interessting, what is this about :) ?
<\sh> I like it :) really...the ubuntu world is really small
<ogra> \sh, oh, didnt i tell you ?
<\sh> ogra: no :)
<\sh> ogra: but good to know where to find beta test candidates ;)
<ddaa> hey seb128
<ddaa> where is pygtk hosted nowaday? I see no pygtk module in the gnome.org viewcvs.
<seb128> it's on cvs.gnome.org
<seb128> gnome-python/pygtk IIRC
<ddaa> hu...
<ddaa> okay... gnome-python is just a placeholder...
<ddaa> another CVS perversion
<ddaa> seb128: thanks
<seb128> np
<ddaa> btw, any idea where is gdk-pixbuf?
<ddaa> and any idea WFT is gdk-engine in the gnome cvs? Is that used at all?
<svenl> Mm, is there somewhere to complain a bout bad translation or should i do a real bug report /
<jdub> ddaa: it's the old gdk pixbuf engine for gtk+ 1.x
<jdub> ddaa: it shouldn'
<jdub> ddaa: it shouldn't be on your priority list
<svenl> us keyboard without dead keys is translated in gnome keyboard choser as clavier us avec eliminee des cle mortes, which sucks.
<svenl> should be clavier us sans touches mortes.
<ddaa> jdub: I stumbled on it because it was the cvs module specified in the gdk-pixbuf info file.
<ddaa> My conscience told me something was wrong.
<ddaa> So, I still do not have a location for gdk-pixbuf
<jdub> don't worry about it
<jdub> it's old and irrelevant
* ddaa checks the list of love
<ddaa> jdub: gdk-pixbuf is on the priority list sent by mdz
<ddaa> as a package which has patches in ubuntu
<jdub> and you're not summarising the name there? you mean precisely the "gdk-pixbuf" *source* package?
<ddaa> yes
<ddaa> at least, in my understanding mdz sent us a list of source package (it contains "pygtk" and not "python-gtk")
<ddaa> "there is no CVS repository for that old piece of crap" is a valid answer
<CarlK> LiveCD - does c-a-bs restart X or reboot the whole box?
<surak> nice question - let me try
<CarlK> I just spent 10 min loading up the nvida drivers, and I really don't want to do that part again
<CarlK> trying to see if the Live CD can be used to debug an nv problme
<surak> booting it now.
<CarlK> plan B is init 1 && init 5 (i think)(
<surak> telinit 3 ; telinit 5 :-)
<CarlK> yeah, that
<surak> CarlK: just a minute
<CarlK> thanks
<surak> still booting..
<surak> btw, it took almost the same time another machine ran the installation :-)
<CarlK> hmm
<CarlK> I cold burn another CD and boot something...
<CarlK> or find my 3 other CDs that are somewhere safe
<surak> c-a-bs now
<CarlK> or read email while yours boots
<surak> only X
<CarlK> thanks
<surak> it went to gdm
<surak> wait
<CarlK> heh
<surak> yes, gdm
<surak> it logged in automatically (I thought it would stop there)
<CarlK> here we go...
<surak> Calk: what happened?
<surak> CarlK: sorry, typo
<CarlK> got the nv spash screen
<surak> and?
<CarlK> waiting for the 1/2x cd... ;)
<CarlK> P2-333, 128meg, no clue what the CD really is
<CarlK> know of a repoisatory that has a Captive NTFS packcage?
<surak> no
<CarlK> now opening term...
<CarlK> Zzzzz
<pitti> Good evening
<surak> hello
<ogra> hey pitti 
<\sh> holla pitti
<Riddell> is there a written policy for what goes in hoary-updates?
<CarlK> "yes" ;)
<CarlK> I saw something like that on a wiki
<CarlK> no clue where
<jdub> Riddell: major bugfixes
<jdub> Riddell: like "hardware destroyed by software", "plague and famine" and "erased disk when I clicked cancel"
<Riddell> jdub: I'm gettings lots of people complaining that MSN doesn't work since microsoft upgraded their servers and peole saying it should be fixed in hoary, would be useful to have something written to say that it's not going to happen
<\sh> Riddell: answer: use jabberme.net with psi and register to msn transport :)
<surak> Riddel: gaim seems to work fine (i'm on it right now)
<CarlK> does hoary-updates include other repositories?
<\sh> .oO(we should build a ubuntu jabber server)
<CarlK> asa in what does/doesn't go in
<Riddell> surak: yeah, seems to have only affected kopete 
<Riddell> https://bugzilla.ubuntu.com/show_bug.cgi?id=10993
<jdub> Riddell: that sounds like a pretty reasonable bug
<jdub> Riddell: you need approval from mdz or Kamion 
<\sh> Riddell: wasn't there an update to kopete cause of this behaviour?
<jdub> Riddell: and get some people to test your package, yada yada
* \sh doesn't like kopete
<moyogo> hi, i'd like to know more about the xhosa localization
<moyogo> i'm interested in doing something similar in lingala, a language of the RDC
<jdub> moyogo: Adi can answer questions for you -> adi@canonical.com
<jdub> moyogo: she managed the xhosa project
<moyogo> thanks
<moyogo> I've also done a keymap with lots of african specific characters, i dunno if they'd be interested
<jdub> cool, let adi know about that too :)
<moyogo> okay, i'm writing an email then
#ubuntu-devel 2005-05-27
<pitti> night everybody
<LinuxJones> can someone please come to #ubuntu and kick morgan ?
<LinuxJones> nm
<surak> is there any page discussing the fact that ubuntu suids root for all users? 
<Amaranth> it doesn't?
<tseng> does what?
<surak> it does. any user can screw the machine just typing sudo. this is default.
<Burgundavia> surak, only the first user in the admin group by default
<Burgundavia> everyother user has to be added to that group
<surak> oh thanks
<tseng> whats that have to do with suids
<surak> sorry, i used the wrong term.
<mdke> surak, http://www.ubuntulinux.org/wiki/RootSudo
<surak> tks
<ogra> we lost a user
<ogra> http://lists.ubuntu.com/archives/ubuntu-users/2005-May/035933.html
<Amaranth> o_O
<mdke> :(
* surak having trouble setting up grub for ubuntuexpress...
<Amaranth> hmm, it's impossible to compile a kernel module for the 2.6.11.92 kernel
<Amaranth> it was compiled with gcc 3.4, only 3.3 and 4.0.1 are provided
<surak> time to go home. this grub's driving me nuts.
<surak> night folks
<mdke> nite
<calc> does colin watson use irc?
<calc> i have some debconf questions to ask him
<calc> or anyone else that does debconf dev work
<mdke> calc, yeah
<mdke> calc, nick is Kamion
<calc> ah yea
<calc> Kamion: awake?
<mdke> calc, he is on europe time i think
<calc> debconf automation stuff seems totally broken
<calc> perhaps broken at a design level even, not completely sure yet
<mdke> calc, maybe email, or leave a message here, he'll get back to you
<calc> ok :)
<sladen> calc: it's 3am here!
<sladen> calc: or send an email to the -devel list and you'll probably have a reply from somebody else before he wakes up!
<count0nz> if i want to work on adding more packages is it better for me to work on breezy or hoary ? going to start packageing TV apps and some games and things
<abarbaccia> hey all - can somebody make a new firefox package for version 1.04?  because you cant access mozilla- extensions and themes until you have that version
<abarbaccia> currently we're running 1.03 i believe
<count0nz> abarbaccia, firefox 1.04 just hot backports for hoary or are you in breezy ?
<count0nz>  /s/hot/hit
<bob2_> *shudder* backports
<bob2_> hope you don't want to be able to update to breezy
<count0nz> shuld be non-trivial to uninstall all backports lol
<bob2_> maybe they could just produce working packages to begin with?
<count0nz> bob can i ask you something
<abarbaccia> breezy
<abarbaccia> count0nz, breezy
<abarbaccia> anybody here?
<bob2_> no oe
<abarbaccia> damn
<abarbaccia> lol
<abarbaccia> how should i get the new version of firefox in breezy
<bob2_> if you have a development question, just ask
<bob2_> if you're going to bug people about firefox, please don't
<abarbaccia> well, where should i ask then
<bob2_> no where
<bob2_> just what.  obviously people are looking at it.
<abarbaccia> well how can i help then
<zul> abarbaccia: sending an email to the -devel list the guy who looks after firefox is not available i think
<bob2_> pretty sure that's not the case
<tseng> firefox works fine, btw
<tseng> its added to ubuntu-meta in all the rigth places
<tseng> pretty special
<zul> oh hey tseng 
<tseng> hi.
<zul> how is it going?
<tseng> fine thanks
<jsgotangco> hi all
<ajmitch> hi jerome
<g14> I've got a new dev box that I can install the new breezy cd onto. If I install that and then update everything, will x still work?
<g14> And is the transition to gcc4 mostly complete?
<crimsun_> gcc4 is nearly complete, yes
<crimsun_> g++4, not by any stretch
<g14> ok thanks, do you know if x will break? I'm no stranger to the command line
<crimsun_> should be fixed now iirc. Haven't been able to update my Breezy box for about two weeks.
<g14> thanks again, I'm gonna try it out now
<robertj> is canonical going to sell individual support contracts anytime soon?
<jdub> robertj: we are
* lamont sleeps.  night all
<robertj> jdub: in a few weeks we are going to put in our requests for next fiscal-year's allowance, and the money is going to be spent, it's just a matter of on what
<robertj> and i'm impatient waiting for my ship-it cds and I want nice pretty pressed copies!
<pitti> Morning
<fabbione> hey pitti
<pitti> trulux: here?
<tja> kamion: where does grub-installer get the $user-params -variable? I'd like to patch it to preseed them
<Burgundavia> morning JaneW 
<jsgotangco> hi JaneW 
<JaneW> morning  Burgundavia and jsgotangco 
<Burgundavia> JaneW, your rant of day is not refreshed.
<Amaranth> mako: You're killing the planet. ;)
<jsgotangco> i love that unusual sex practices blog entry
<jsgotangco> heh
* Amaranth meant the flooding of entries and having them all be marked as new over and over in blam
<Amaranth> but yeah, i loved it too ;)
<jsgotangco> ahh
<jsgotangco> yeah
<jsgotangco> i just refereshed blam
<JaneW> Burgundavia: yes, I must update that asap, note it's the *NAG* of the day ;)
<jsgotangco> jeezz
<jsgotangco> planet mako
<trulux> pitti: about to go to school, in 10min
<trulux> pitti: what's up?
<pitti> trulux: your patch is still screwed
<pitti> trulux: it still doesn't get active by default
<pitti> trulux: can I send you the patch against 2.6.12 and a link to the orig.tar.gz, and can you work on 2.6.12 from now on?
<JaneW> fabbione: ping?
<trulux> pitti: what orig.tar.gz? on 2.6.12? when it's released maybe
<fabbione> JaneW: pong
<JaneW> fabbione: ok the 'affects kernel?' column of Breezy Goals is prety much complete.
<trulux> pitti: I will modify so we end up using the default setting neither when defined or undefined (set to 0)
<tja> should f-spot and beagle work?
<tja> on breezy
<fabbione> JaneW: ok. i will take a snapshot before the end of the day
<fabbione> JaneW: right now i am quite busy
<trulux> pitti: will work on it
<JaneW> fabbione: mdz wants it removed, can I send it to you as a spreadsheet, or have you mad e anote of the responces already?
<trulux> pitti: must go to school
<trulux> see you
<fabbione> JaneW: a spreadsheet is more than fine
<JaneW> fabbione: no problem, will do so soon. ciao
<fabbione> thanks
<trulux> pitti: send the patch for .12 to my email
<trulux> need to go
<pitti> trulux: will do, see you
<zyga> morning :-)
<Amaranth> tja: breezy doesn't work because of the move to dbus 0.30, dunno about f-spot
<Amaranth> err, beagle on breezy
<tja> i get the same error on startup
<Amaranth> which is?
<tja> "the assembly was not found in the Global Assembly Cache..."
<Amaranth> which assembly?
<tja> gnome-sharp
<Amaranth> ...
<Amaranth> you have libgnome-cil?
<Amaranth> you have to install the dependencies manually right now, mono things are broken like that
<tja> duh, no..
<tja> ok
<tja> sorry
<Amaranth> #ubuntu-motu topic (mono is in universe) says "Please dont complain about mono deps for next 2 weeks"
<tja> =)
<tja> i'll join that one
<pitti> elmo: please sync alsa-lib from experimental
<jsgotangco> chmj, hey
<chmj> hi jsgotangco 
<seb128> daniels: around? :)
<daniels> seb128: no! :P
<daniels> what's up?
<seb128> daniels: ah ah
<fabbione> hey seb
<seb128> daniels: you know about these keyboard issues? wondering if I should really blame xorg or gtk :)
<seb128> all the dups seems to be gnomish, but gtk didn't change...
<seb128> hi fabbione 
<fabbione> seb128:
<fabbione> <lamont> doko: what's the story with gnome-menus?
<fabbione> <lamont>   libgnome-menu-dev: Depends: libgnome-menu2 (= 2.11.1.1-0ubuntu1)
<fabbione>            but it is not installable
<fabbione> <lamont> fabbione: when seb128 is awake again and/or doko, wanna ping them wrt
<fabbione>           gnome-menus?  (see above)
<seb128> apt-get install libgnome-menu2 ?
<fabbione> seb128: that's on the buildd i think
<seb128> works for me (tm)
<daniels> seb128: keyboard issues -> xorg
<daniels> can't fix them right now, need to run away for a bit
<seb128> daniels: ok, thanks, I keep duping that so :)
<seb128> daniels: no pb, I've not updated my xorg yet :p
<fabbione> seb128: well.. i just reported what lamont told me to tell you :)
<fabbione> seb128: i didn't dig into it
<seb128> fabbione: right, do you know what arch/build log is that?
<fabbione> no clue
<seb128> I'll wait for lamont so, thanks
<pitti> thom: here?
<seb128> a bit early for thom :p
<pitti> thom: I looked at the dhcdbd code; it is written cautiously, but not very robust (the guy should learn how to use strdup() *sigh*). However, I did not find any obvious flaws, so I'm fine with it
<pitti> seb128: hm, right, but he'll read scrollback, I think
<pitti> anyway, good time for breakfast now, cu later
<seb128> enjoy your breakfast :)
<daniels> GAR FIREFOX CRASHING SO MUCH
<Treenaks> daniels: C++ b0rkage?
<bob2> BUT WE NEED 1.04 IN BREEZY OR OUR GENITALS WILL FALL OFF
<Treenaks> bob2: THEY WILL?? *gets the ducttape*
<daniels> Treenaks: no, it just crashes ALL. THE. TIME.
<Treenaks> daniels: that's a feature. it makes it more secure.
<chmj> lol 
<bob2> hm, are there any install cds with 2.6.12 out there?
<fabbione> no
<fabbione> it's not in main
<bob2> dang, apparently this sata controller should work with something more recent
<Treenaks> bob2: you could roll your own
<bob2> and build a new cd?  you massively underestimate my laziness.
<bob2> guess I'll wait for the first breezy thing
<fabbione> bob2: did you try to use the compatibility mode?
<bob2> fabbione: is that a bios or kernel option?
<fabbione> bios
<bob2> I shall have a look
<bob2> it's a shiny new ibm thing
<Lathiat> daniels: ping
<daniels> pong ... is this about xkb?
<Lathiat> heh i was just going to ask if you knew about two things
<Lathiat> first that xlibs-dev is empty and second that keyboard shortcuts are broken. :)
<Lathiat> if so, dont worry, continue on with whatever you were doing. :)
<daniels> uhm, xlibs-dev has been empty for years
<Lathiat> humm, what package are X headers in then?
<daniels> xlibs-dev depends on a whole bunch of other packages
<daniels> which contain headers
<Lathiat> oh i see
<daniels> and now that's turning into about a bajillion other packages :)
* Lathiat tries to figure out what he was having a header problem with
<Lathiat> daniels: are headers broken in some way?
<daniels> Lathiat: you want to add -I/usr/X11R6/include, if you haven't got it already
<pitti> daniels: btw, any idea about the recent keyboard breakage?
<pitti> daniels: i. e. can you reproduce it?
<daniels> pitti: yes
<daniels> haven't checked if I can reproduce it
<daniels> but adding /usr/lib/X11/xkb as a symlink to /etc/X11/xkb may work
<daniels> gotta run though, back in a few hours
<daniels> unphoneable
<pitti> see you
<Lathiat> bye, thanks 
* pitti ties the xkb fix
<Lathiat> didnt help me
<Lathiat> no idea if it was the same problem tho
<Lathiat> (all my keyboard shortcuts are foobared)
<Lathiat> also the X11 problem i had was libgdiplus not being able to find X11/Xlib.h
<daniels> Lathiat: yep, need -I/usr/X11R6/include
<daniels> so it only worked by accident before :)
<Lathiat> oh i see
<daniels> bbl
<Lathiat> cya
* Lathiat  figures out how to abuse libgdiplus to add that
<Kamion> tja: user-params takes stuff from /proc/cmdline
<fabbione> hey Kamion 
<Kamion> tja: there's zero point changing it to be preseedable - if you could preseed, you could equally well just pass the kernel parameters
<Kamion> morning fabio
<fabbione> Kamion: mind to review http://udu.wiki.ubuntu.com/ClusterFilesystems (bottom part)
<fabbione> Kamion: i am not sure if there is a better way to proceed
<Kamion> fabbione: you can only do kickstart integration if RH have defined the syntax
<Kamion> but which bit do you mean?
<fabbione> "Addition after Approval"
<Kamion> oh, ok. I don't see a problem there, but I don't know the background
<fabbione> not sure if we need to bring the specs back to Edited
<fabbione> Kamion: it's just another Cluster Filesystem
<fabbione> i was more concered about the way to handle the spec document itself
<Kamion> oh, I don't think so
<fabbione> ok thanks :)
<Kamion> same constraints about no rootfs etc.?
<Kamion> anyway I've noted the addition as approved
<fabbione> ok
<Kamion> since you've already done it there seems little point doing otherwise :-)
<fabbione> no no constrains
<Kamion> if d-i work is needed, that needs to be specced
<fabbione> no there is no d-i work for breezy
<Kamion> k
<fabbione> if there will be some reaction from users in terms of: "hey but i am installing in a cluster and i would like to mount my GFS/OCFS2 fs at install..."
<fabbione> we will figure that out at a later stage
<torkel> re ClusterFilesystems and Lustre, for us it would be a big win if it was possible to have their kernel-patches applied
<fabbione> torkel: lustre seems pretty dead upstream
<fabbione> that's why it has been deferred
<fabbione> and i am not too happy to bring in dead code
<tja> kamion: well, it doesn't add my "vga=.." options
<torkel> fabbione: they focus on the 1.4 branch (1.4.2.1 was released a week or two ago), which you need to have a support contract to get
<fabbione> torkel: this is free software dude...
<fabbione> so that brings lustre out of our scope
<torkel> fabbione: but they have expressed intrests in getting their kernel-patches in the stock kernels
<torkel> fabbione: I know
<fabbione> torkel: if and when they will put the code as GPL and available everywhere i will have no problem to include it
<fabbione> as it is, it's no no no
<Kamion> tja: did you put them after --?
<Kamion> tja: the default bootloader configuration should have a -- parameter, user-params copies parameters that appear after that
<tja> ah
<tja> documented anywhere?-)=
<tja> -=
<Kamion> possibly not, it just works for normal users, can be confusing for automaters
<seb128> elmo: galeon/experimental sync please
<tja> kamion: ok, thanks for that
<Kamion> kinda hard to grep the manual for though, let me see ...
<Kamion> no, not documented as far as I can see ... I'll file a bug and see if somebody in Debian can do it
<torkel> fabbione: when releasing a new major version they are releasing the old version under GPL. 
<fabbione> torkel: that makes lustre still useless for us, given that we can't backport fixes
<fabbione> either they get an open development model or it's no no
<Kamion> tja: bug filed
<tja> kamion: super
<JaneW> where can I send user support requests?
<JaneW> a user has found some bugs and a few other things that he needs help with, but doesn;t know how Bugzilla works
<JaneW> he has sent an e-mail to me.
<Burgundavia> JaneW, I can file them
<Burgundavia> and help him with his probs
<JaneW> Burgundavia: can I forward the e-mail to you then? Address please.
<Burgundavia> JaneW, corey.burger@gmail.com
<jsgotangco> JaneW, start nagging!
<JaneW> jsgotangco: oh so you like it do you?
<jsgotangco> its been a while
* JaneW takes out the wooden spoon
<\sh> there is no spoon ;)
<jsgotangco> haha
<jsgotangco> just like there is no JaneW 
<doko> good morning all
<JaneW> don;t you mean no one like JaneW ? ;)
<JaneW> hi doko
<JaneW> Burgundavia: message sent
<Burgundavia> JaneW, got it, parsing now
<jsgotangco> JaneW, are the UDU spec queues still supposed to take effect?
<JaneW> jsgotangco: er, I guess so yes, but I am not sure if anyone is still checking them... are you waiting on somebody? 
* JaneW checks queue quickly...
<\sh> the lovely request "file a bug in malone and attach the strace logs" is quite usual these days, but they're to frightened to do it ;)
<Nafallo> thom: you already know that firefox crashes on reload? :-P
<jsgotangco> JaneW, just wondering i think it still should take effect
<infinity> Nafallo : It's known, yeah.
<Nafallo> infinity: I thought so :-). irritates the hell out of me atm ;-).
<JaneW> jsgotangco: I agree, but I think if you do add something to somebody's queue you should give them a prod to let them know you have done so, else it may sit there indefinitely.
<JaneW> who can assist jeff ewlkner with edubuntu requests and questions?
<jsgotangco> i dont mind doing that
<Burgundavia> JaneW, replied
<jsgotangco> but does jeff elkner go on irc?
<JaneW> edubuntu is TOP priority for Breezy, yet they are flailing without input or hardware etc
<Burgundavia> I can assist edubuntu with spare hardware, etc.
<jsgotangco> Elkner/Applegate
<JaneW> jsgotangco: he can but doesn't really, as he hasn't had much luck so far
<JaneW> Burgundavia: thank-you :)
<jsgotangco> how about colin
<jsgotangco> (applegate)
<JaneW> jsgotangco, & Burgundavia can I forward Jeff's e-mail to you to evaluate?
<Burgundavia> JaneW, yes
<jsgotangco> no problem you can bug those people in Interested as well
<mdke> is there any sign of a firefox hoary update?
<Kamion> JaneW: mm, people doing top-priority work for breezy should be recommended to show up in this channel regularly, I think
<JaneW> Kamion: agreed, I get the impression that they are not sure how to get involved and what channels to follow, I'll send msg to you too
<JaneW> jsgotangco: what's your email address, I am battling to find it quickly...
<jsgotangco> JaneW, jgotangco@gmail.com
<jsgotangco> i think they don't know where to start
<seb128> pitti: the gstreamer sink change is to do whenever or you need to upload some stuff before?
<Treenaks> hey, it's the ogra daemon :)
<Burgundavia> JaneW, for edubuntu, on the technical end, I would talk to sabdfl
<Burgundavia> if this is a top priority thing that is floundering, a few words from above can make the difference
<Burgundavia> on the social end, hmm
<JaneW> Burgundavia: advice noted, thanks
<Kamion> JaneW: oh, he tried #ubuntu-dev, not #ubuntu-devel
<Kamion> trivial mistake, but ...
<Burgundavia> oops
<Burgundavia> can we get -dev pointed here?
<Kamion> I'm not sure IRC supports that usefully
<\sh> Burgundavia: no
<Burgundavia> freenode can do it
<Burgundavia> try joining #c
<Kamion> huh, ok
<\sh> but this is a split-up channel, right? 
<jsgotangco> hmm
<Kamion> that's #c and ##c though, seem a bit different?
<Treenaks> Kamion: try #python/#python2 then
<Burgundavia> I have seen #wikipedia redirected to ##britannica
<\sh> this article is really interessting...I read it this morning...http://www.tectonic.co.za/view.php?id=455
<pitti> Hey ogra
<Burgundavia> JaneW, looking at the breezy goals for edubuntu, I see some light dev work, followed by lots and lots of testing
<Burgundavia> oh, and did I mention testing?
<ogra> hey pitti....
<\sh> sorry to ask, but who is living in ZA and could provide me with a constant flow of biltong? game and beef are the favorites
<ogra> flaky dsl today for me :/
<Burgundavia> \sh, I thought I would never hear that on IRC
<\sh> ogra: upgrade to 25mbit/s 
<ogra> \sh, who offers _that_ ?
<jsgotangco> Burgundavia, it involves ltsp as well
<\sh> ogra: telekom will
<\sh> Burgundavia: why?
<\sh> Burgundavia: it's one of my favorite snacks :)
<ogra> \sh, i have to move houses soon.... i'll buy a leased line for my next house
<Burgundavia> \sh, gah, hate the stuff, too salty
<\sh> Burgundavia: tried the chilli spiced one?
<jsgotangco> ogra, we backport patches right?
<Burgundavia> \sh, nope
<\sh> Burgundavia: u should :) delicious
<\sh> Burgundavia: but it's hard to get it here in .de
<ogra> jsgotangco, to where ? to the stable version ? only if they fix very serious or security bugs
<Burgundavia> \sh, is next to impossible to get in .ca
<jsgotangco> ogra, say firefox update
<Burgundavia> but we occasionly get some from the family in .za
<ogra> yep
<jsgotangco> ogra, version stays the same, except patches are taken from source
<ogra> jsgotangco, yep
<Burgundavia> I remember when we used to have to get rooibos tea because of the sanctions
<\sh> Burgundavia: ah :) u know...i found a german wholesaler who is selling 100g biltong for 9.50 EUR
<Burgundavia> sent from za that is
<\sh> Burgundavia: i know rooibos tea :)
<\sh> my ex-wife had everything at home :)
<Burgundavia> the funny part is, people used to get it into .ca by calling it vita tea, and not mentioned where it was from
<\sh> Burgundavia: well, there is a lot of stuff, I used to like to eat when I was in .za, but I won't get it here in .de...there r really nice candy/chocolatebars from nestle...I never saw here in germany
<\sh> and it's not possible to buy it here in .de cause nestle doesn't want to produce it for .de :(
<\sh> but this is quite OT here ;) 
<Burgundavia> yes
<\sh> anyways...I need to find a support source for this...*noted*
<svenl> hi all.
<svenl> is there a known problem with X fonts right now ?
* svenl can't birng up X after having upgraded my powerbook to breezy, which sucks:)
<Burgundavia> svenl, yes there is
<svenl> Burgundavia: cool.
<pitti> seb128: gosh, how on earth can you live with bugzilla.gnome.org? I don't want to login five times to file a bug
<svenl> Burgundavia: any known workaround ?
<svenl> pitti: hehe.
<svenl> pitti: most people then don't fill bugs.
<seb128> pitti: ?
<tseng> what sucks is keeping track of all your bugzilla passwords
<tseng> or going back and chacnging them all
<svenl> Burgundavia: or description of the problem i can access from pure textmode ?
<seb128> pitti: I log 1 time and it's ok until an IP change 
<pitti> seb128: for me not, I have to relogin after _each_ page 
<seb128> pitti: now try malone, every time you close your browser you need to log again
<pitti> seb128: right
<seb128> blame firefox
<pitti> seb128: but usually I don't close my browser while filing a bug
<seb128> bugzilla works like a charm for years here
<pitti> seb128: b.ubuntu.com does, but not b.gnome.org
<seb128> b.g.o does here
<seb128> maybe that's a security stuff from firefox?
<seb128> it's not https
<Kamion> svenl: font path's changed
<svenl> Kamion: yeah.
<Kamion> suspect that's it
<svenl> Kamion: i got a message from defoma telling about it, but the fonts in the config file match that message.
<Kamion>    * Change default font paths from /usr/lib/X11/fonts to /usr/share/X11/fonts
<Kamion>      in default xorg.conf and also in update-fonts-*, which really need to move
<svenl> Kamion: and it seems to be a debian defoma message since it speaks about XFree86.0.log
<Kamion>      to another source package.
<Kamion> I imagine if you switch the font path in xorg.conf it'll work
<tseng> it surely does.
<Burgundavia> seb128, gnome-panel is ftfbs
<svenl> what about the defoma font paths ? 
<seb128> Burgundavia: you get mails about ftbfs?
<Burgundavia> seb128, no I check the page
<seb128> k
<seb128> HATE this bz2 stuff
<Burgundavia> so do I
<svenl> mmm, didn't help.
<seb128> Burgundavia: buildd issue, need lamont
<svenl> mmm, there is no /usr/share/X11
<tseng> its /usr/share/fonts/*
<Burgundavia> seb128, I was eagerly awaiting menu editing
<seb128> Burgundavia: that's because libgnome-menu2 is universe instead of main, needs elmo
<svenl> and the fonts are in /usr/X11R6/lib/X11/fonts
<tseng> no, they arent
<seb128> Burgundavia: that's gnome-menus which is built for a day now
<seb128> no need of the new panel
<tseng> Burgundavia: just run gmenu-simple-editor by hand
<svenl> tseng: /usr/share/fonts only has truetype and type1 fonts though.
<tseng> svenl: ...
<tseng> and actually works
<tseng> comeon dude, this is not a support channel
<tseng> try #ubuntu
<svenl> tseng: hehe.
<tseng> we told you where to look
<svenl> tseng: ok.
<tseng> thanks.
<Kamion> calc: so what's this about debconf?
<svenl> damn, the 2.6.12-rc kernel dies when waking up, and benh probably is sleeping now.
<svenl> mmm, sorry, wrong channel ... 
<svenl> tseng: i know it is no support channel, but i did an apt-gte upgrade today, and the fonts are in /usr/X11R6/lib/X11/fonts, not in /usr/share/fonts nor in /usr/lib/X11/fonts
<svenl> (powerpc packages though).
<svenl> and setting it to that in xorg.conf indeed fixes it.
<svenl> so i don't know what is going on here.
<tseng>          FontPath        "/usr/share/X11/fonts/100dpi"
<tseng>          FontPath        "/usr/share/X11/fonts/75dpi"
<tseng>          FontPath        "/usr/share/X11/fonts/Type1"
<tseng> i have those, it works fine for me
<tseng> thats about all i can tell you
<Kamion> X is still in the middle of a pretty major transition
<Kamion> yes, it may be broken
<jsgotangco> bye bye we're watching star wars *grin*
<pitti> jsgotangco: enjoy :-)
<\sh> it's already out as an dvdrip ;)
<svenl> Kamion: are you running 2.6.12 kernel on your powerbook ? When you have some time can you try it out and try to sleep ? I think it dies each time when you do that.
<Kamion> svenl: no, I'm not yet
<Kamion> still on a patched 2.6.9 *cough*
<svenl> not even running the hoary kernel ? 
<elmo> Kamion: dude
<svenl> Kamion: please do, and tell me your powerbook model.
<pitti> svenl: I have 2.6.12 running on my iBook G4, sleep works well
<svenl> Kamion: i need to investigate this with benh this evening.
<svenl> pitti: thanks for the info.
<koke> pitti: yesterday I tried 2.6.12 and crashed when resuming (ibook G4 too)
<Kamion> svenl: my powerbook runs Debian because it's also my Debian development system
<koke> I still use a patched 2.6.9 too :)
<svenl> Kamion: lasfckl;asdj
<Kamion> same to you
<svenl> Kamion: sorry.
<Kamion> :-)
<svenl> arg, no network anymore.
<zyga> does nfs need some tuning from default setup? I currently see tragic performance with 2.6.12 on amd64?
<svenl> Kamion: can you give it a try or something sometime ? 
<tseng> i can suggest you set rsize and wsize
<tseng> rsize=8192,wsize=8192 in your fstab
<tseng> see man nfs for more detail.
<tseng> i also see improvement by using tcp
<Kamion> svenl: sure, when I'm not too busy
<tseng> if you can.
<svenl> Kamion: please do.
<svenl> Kamion: preferable before the breezy release :)
<Kamion> breezy will be on 2.6.12 before the breezy release anyway
<Treenaks> maybe even .13?
<Kamion> so I'll be trying it out then at the latest
<zyga> tseng: I'll try 
* tseng is off for the day
<tseng> bye.
<svenl> Kamion: sure, but it would be nice if we fixed that bug before 2.6.12 is out :)
<JaneW> Someone has requested that Breezy include Beagle - comments?
<Burgundavia> JaneW, I thought that was already going to be default
<Burgundavia> JaneW, but don't quote me on it
<Kamion> JaneW: that's part of the Mono spec
<ogra> JaneW, it is ready to go in after all the transitions are done.... but i'm not sure if we want beagle in main or only its bindings (mono)
<Burgundavia> JaneW, http://udu.wiki.ubuntu.com/Mono
<JaneW> oic... thanks
<Burgundavia> JaneW, if you want to pass anything on to me, that is fine
<pitti> mvo: ping
<mvo> pitti: pong
<Mithrandir> elmo: thanks for the pyblosxom sync.
<calc> Kamion: when trying to use the DEBCONF_DB_FALLBACK or _OVERRIDE variables
<calc> libpaper1.config for example reads the value in /etc/papersize and then sets it. it somehow overwrites the setting in OVERRIDE file
<calc> then debconf checks the OVERRIDE file to see what you wanted the answer to be for automated installs which is no longer correct
<calc> also when it writes the updated config.dat it uses the file you provided in OVERRIDE instead of the system config.dat should that be happening?
<calc> iow DEBIAN_FRONTEND=noninteractive DEBCONF_DB_OVERRIDE=File{/root/config.dat} dpkg-reconfigure -plow -a  causes the config.dat in /root to be the up to date one /var/cache/debconf/config.dat is no longer up to date
<Kamion> ok, I've never used DEBCONF_DB_{FALLBACK,OVERRIDE} so I'm not used to them
<calc> ok
<Kamion> which are you saying takes precedence? the value the .config just set, or OVERRIDE?
<Kamion> it wouldn't surprise me if it were the former, OVERRIDE basically just stacks an extra named database on top of the ones in debconf.conf
<calc> OVERRIDE takes precedence over /var/cache/debconf/config.dat, however it is used for both reads and writes and since it is used for both reads and writes when something like libpaper sets up its initial value it can not use the value you want it to use
<calc> imho it should only be used for reads
<Kamion> you should be able to set it up that way
<Kamion> add Readonly{true} or whatever the syntax is
<calc> oh? hmm
<calc> it wasn't mentioned in debconf(7) i'll look around for the syntax of that once i get to work
<Kamion> File{/root/config.dat Readonly:true}
<Kamion> I think
<calc> too bad i have no net access at work :\
<calc> Kamion: ah ok :)
<Kamion> don't know if that's documented
<Kamion> you can sort of infer it from debconf(7) but it isn't clear
<calc> the examples in debconf(7) for automated installs should use that syntax otherwise you end up with an invalid system config.dat
<calc> well FALLBACK database are apparently readonly by default
<calc> doesn't say about OVERRIDE
<Kamion> FALLBACK is probably only readonly because debconf finds another writable database first
<calc> ah yea
<calc> thanks for the suggestions :) i have to leave for work now
<Kamion> debconf.conf(5) says writes go to the first writable database on the stack
<calc> ok
<Kamion> ok, let me know if it works and I can arrange for that to be documented
<Kamion> the Readonly:true thing
<calc> yea :)
<Kamion> is anyone working on getting a new OOo2 milestone into breezy?
<Kamion> doko? (I know you're busy with C++ ...)
<doko> Kamion: yes, it's on my list ;)
<Kamion> ok, anyone else who's unloaded and might be able to do it?
<doko> Kamion: I started on it, so give me the weekend ...
<Kamion> ok, cool
<JaneW> hi guys nag time
<JaneW> could all leads on Breezy Goals please makes sure there is at least a one sentance explaination of the state of their goal. i.e. Where the goals is now and the next required/planed step.
<JaneW> many thanks.
<JaneW> http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
* pitti tries to grab a lock
<\sh> we need an online webbased project management tool
<jdub> dotproject
<\sh> url?
<jdub> is an interesting option
<jdub> dotproject.org i think
<jdub> JaneW: you might want to check it out
<jdub> JaneW: was pretty rad last time i used it
<\sh> ah jdub...ogra reminded me to give u my blog rss feed ;)
<ogra> yeah
<jdub> \sh: you're a member?
<ogra> yep
<ogra> since last CC
<\sh> jdub: jep
<jdub> your whois info says you're saint hermann ;)
<ogra> hehe
<\sh> st. == stephan :)
<\sh> but saint is also right ,-)
<ogra> lol
<jdub> ;-)
<jdub> aha
* jdub links nick to person now :)
<jdub> \sh: what's the url?
<JaneW> jdub: ok thanks
<seb128> graah, what are the gal guys doing
<\sh> jdub: only a ubuntu category feed or complete blog feed?
<ogra> seb128, what are they doing ?
<\sh> rss2 or atom?
<\sh> rss2 is better
<\sh> http://linux.blogweb.de/feeds/index.rss2
<seb128> the tarball doesn't even build, they have not put new .h files here ... they don't even try to build before pushing a tarball?
<jdub> \sh: whatever your preference - planet is all abuot getting to know the people, as well as what they're hacking on :)
<ogra> seb128, crazy
<seb128> that, and gal-2.5 has a libgal-2.4 instead of libgal-2.6, so conflicts with -2.4
<seb128> I spoke about that 2 weeks ago for 2.5.1, they said that's fixed with the CVS
<ogra> seb128, even more crazy
<seb128> and 2.5.2 still have it
<ogra> hmm, overwritten by a merge .... ?
<seb128> what?
<\sh> jdub: nice thing that is...
<seb128> upstream bug, they are versionned the lib incorrectly
<seb128> s/are/have/
<\sh> ogra: check out dotproject.net
<jdub> \sh: got a hackergotchi?
<\sh> jdub: a what?
<jdub> \sh: a little floating head icon :)
<ogra> \sh, send me a photo, i'll make one for you
<jdub> \sh: planet.gnome.org/heads/
<\sh> ogra: take it from shermann.blogweb.de ;) this is the only digital photo i have of myself ;)
<ogra> \sh, oki
<\sh> ogra: cut out the face..the rest is lycos stuff ;-)
<ogra> jdub, i'll send it to you over the wekend
<JaneW> jdub: was that URL correct?
<jdub> JaneW: dotproject.net
<\sh> ogra: thx :)
<jdub> ogra: thanks!
<ogra> :)
<jdub> JaneW: do you have a blog?
* \sh can provide blogs under blogweb.de if anyone needs one :) serendipity blogs of course :)
<JaneW> jdub: nope, not yet, I send out random mass mailings though
<jdub> JaneW: if you're keen, you could set one up on blogspot or advogato - i'll put you on planet
<JaneW> jdub: I have just not compiled them in one place, it;s easier for me to dodge accountability this way ;)
<JaneW> jdub: I have been pondering the idea for a while, so yeah it could be cool, thanks.
<JaneW> jdub: on and happy belated one month anniversary for Tuesday.
<jdub> JaneW: :-)
<JaneW> jdub: dotproject.net looks better....
<\sh> ogra: w8 a moment with the picture ... i think I have more pics of me...better ones ;)
<ogra> \sh, mail me one...
<\sh> ogra: jepp
<\sh> jdub: size of the picture should be?
<jdub> \sh: give ogra a nice photo, whatever size :)
<jdub> the hackergotchi will end up being around 70-80px squard
<jdub> square
<ogra> i'll scale it down the
<ogra> then even
<\sh> jdub: k...drop shadow?
<jdub> nice translucent one
<ogra> \sh, i'll do it, just send the pic
<jdub> see planet.gnome.org/heads/ for examples
<jdub> drop shadow is best when it's not black
<JaneW> how hard is it to make those cut outs?
<ogra> JaneW, depends how good you are with gimp ;)
<JaneW> ogra: well I tried today, I was not that good, I am more used to PhotoShop
<trulux> back
<trulux> pitti: heya
<pitti> hey trulux 
<pitti> trulux: can I get new crack? :-)
<trulux> pitti: sure
<trulux> pitti: one sec
<trulux> pitti: need to do some stuff
<trulux> ;)
<pitti> take your time
<ogra> JaneW, http://www.grep.be/blog/lj/21322
<ogra> JaneW, but your haircut could make it an advanced task ;)
<JaneW> ogra: *LOL*
<JaneW> ogra: i't amazing, there's a how-to for everything on the net ;)
<ogra> :)
* JaneW books haircut immediatly
<Treenaks> JaneW: you didn't know that yet? :)
<ogra> lol
<JaneW> ogra: my haircut makes drawing for my son very easy, he just has to scribble, and hey presto a perfect likeness to mommy!
<trulux> pitti: could you tell hwt you have when you boot up the kernel with krsec=1 ( dmesg | grep krsec)
<JaneW> Treenaks: well yes I do, but it's still sometimes amazing just how pervasive it is
<\sh> ogra: i have time .. so I'm learning to create hackergotchis now ;)
<pitti> trulux: lemme reboot...
<ogra> JaneW, and you are recognizeable in a crowd as well ;)
<ogra> \sh, ok :)
<JaneW> ogra: I am not sure if that is a good or bad thing!
<ogra> JaneW, for your son its a good thing i guess
<JaneW> ogra: good diplomatic answer!
<jdub> haha
<ogra> *g*
<pitti> trulux: odd
* JaneW must go out for a bit 
<pitti> trulux: first message: "krsec: enabled (after init)"
<pitti> trulux: a little later "krsec: Could not init"
<pitti> trulux: all sysctls are off
<seb128> mvo, pitti: what does the gksuui bug do? :)
<pitti> seb128: uncle Vogt fixed it
<trulux> pitti: right, stupid bug
<trulux> pitti: seems fixed here
<seb128> pitti: I ask what is the bug :p
<seb128> I just read the changelog on -changes
<seb128>    * debian/patches/02_fix_gksu_ask_pass.diff:
<seb128>      - fix a bug in the gksu_ask_password code (thanks to pitti
<seb128>        for finding it)
<trulux> pitti: will uplaod new patch for 2.6.11 (just came back from school)
<pitti> seb128: it didn't give a rat's ass about the arguments you gave it :-)
<seb128> that doesn't really inform
<pitti> seb128: it completely ignored the title and text arguments
<seb128> just push you to ask what the bug is :p
<seb128> k
<seb128> thanks :)
<seb128> (right, I'm curious)
<pitti> trulux: any chance to work on 2.6.12? would be way faster for me
<ogra> seb128, i think its the "crash xscreensaver caused by time-admin" bug, that turned out to be a gksu bug
<seb128> how does it stop xscreensaver?
<ogra> seb128, by rewriting the uid in a auth file... i'll look up the bug for you, wait a sec
<seb128> don't bother
<trulux> pitti: yes, bbl, lunch time
<mvo> ogra: that "xscreensaver thing is not restarted" should be fixed now
<ogra> mvo, thanks :) thats what i suspected fter reading the changelog :)
<Kamion> oh, eek, I think the debconf passthrough frontend has some very fundamental localisation issues
<ogra> seb128, https://bugzilla.ubuntu.com/show_bug.cgi?id=8684
<\sh> ogra: transparent png?
<ogra> \sh, yep
<\sh> ogra: http://linux.blogweb.de/images/hackergotchi.png something like this?
<seb128> ogra: thanks
<ogra> \sh, soften the edges before you cut out the head
<\sh> oh yes...
<ogra> \sh, and if possible, try to get the neck a bit more rounded at the bottom...
<ogra> (its cut off)
<ogra> \sh, probably its enough to check the resize option in the drop shadow function...
<trulux> back
<\sh> i will cut out the neck...i don't need a neck ;9
<ogra> yeah, who needs a neck anyway, lets all look in the same direction and we dont need necks anymore :)
<\sh> ehe...no i have it now
<\sh> now the edges..how can i soften them
<\sh> ogra: check again pls :)
<ogra> \sh, hmm, the edges are still satairstepping....
<seb128> http://gentoo.ovibes.net/nautilus-share/mediawiki-1.4.4/index.php/Accueil
<mdke> nice
<\sh> ogra: well...it's coming from and bad jpeg..so forget about the edges...i'm running a blur over it now ;)
<ogra> \sh, argh.. no, dont, rather leave the steps in...
<\sh> ogra: hehe...just joking :)
<ogra> seb128, so we are missing some automatic setup of smb.conf now :)
<mdke> yeah
<\sh> ogra: and now?
<ogra> \sh, ?
<\sh> ogra: check again ;)
<\sh> it's ok now...
<ogra> hmm, blurry
<\sh> doesn't matter...if somebody wants to meet me ;)
<ogra> heh
<trulux> pitti: going to try some stuff
<pitti> trulux: can you please test it locally?
<pitti> trulux: changing a bit in an already compiled tree and recompile is fast
<pitti> trulux: but that's difficult when I have to port the patch and generate a deb
<trulux> pitti: uploading a new one which is a little bit enhanced
<pitti> trulux: does it work?
<pitti> tested?
<ogra> \sh, www.grawert.net/sh.png
<Treenaks> he has a neck!
<trulux> pitti: it will
<seb128> pitti: you ignored me this morning, so I ask again :p Should I change gstreamer now, or that's waiting or some others changes from you first?
<trulux> pitti: when you habe been doing something for some time on somehow way that makes you able to make it even blindly, you can assess the risk of saying "it will" ;)
<pitti> seb128: I didn't see that message, sorry
<seb128> I guessed so, no need to be sorry :)
<pitti> seb128: it's waiting for the sync of alsa-lib
<seb128> k
<pitti> seb128: I asked elmo twice, but he didn't have time yet
<trulux> pitti: uploading refreshed patch
<trulux> pitti: http://pearls.tuxedo-es.org/patches/security/kern-security-1.patch
<trulux> pitti: haven't tested it, going to transit to 2.6.12 now
<pitti> trulux: which file did you change, compared to the last patch?
<trulux> security.c and Kconfig from security/*
<pitti> trulux: can you please just give me the changed file? then I bang it into the compiled tree, then it's a matter of minutes
<pitti> KERN_SECURITY_BOOT_PARAM_VALUE
<pitti> NOOOO
<pitti> not another config parameter
<pitti> trulux: adding another parameter *really*, *REALLY* hurts
<trulux> that's for sanity, man
<trulux> check the other settings, and nom, it doesn't hurt. I'm doing it same way as SELinux does
<pitti> trulux: but that's the purpose of KERN_SECURITY_DEFAULT_SETTING
<trulux> nope
<pitti> trulux: why have two parameters for the same thing?
<trulux> pitti: it's not for the same thing....
<pitti> +config KERN_SECURITY_DEFAULT_SETTING
<pitti> +	bool "Enable all options by default"
<pitti> +	depends on KERN_SECURITY
<pitti> +	help
<pitti> +	  This option defines the default availability of all the features
<pitti> +	  provided by krsec. If it's selected, all features will be enabled at
<pitti> +	  boot time, instead of leaving them disabled until they get enabled
<pitti> +	  manually by the sysctl.
<pitti> this very much sounds like the thing I ask for
<trulux> listen
* pitti listens
<trulux> you still don't get how it works
<trulux> I'll explain
<trulux> and apologize of being an asshole with it
<trulux> first we have a boot kernel parameter
<trulux> append="selinux=0"
<trulux> that would disable aselinux at boot time
<trulux> krsec does same thing
<trulux> provides a generalized krsec= option
<trulux> the point is that we can choose the default value it can take if nothing is appended to kenrel command line
<trulux> KERN_SECURITY_BOOT_PARAM_VALUE
<trulux> so
<trulux> on the __setup thing, we check if the __init call has been already called
<trulux> if it does, the krsec_enable thing re-checks so we have krsec_enable set either to 0 or 1
<trulux> ALL checks and helpers functions will check first for that krsec_enabled
<trulux> which can be changed at boot and runtime
<trulux> at boot you'll get it off by default, on runtime you can do it dynamically
<trulux> if (krsec_enabled && security_fs_linking_enabled && current->fsuid != inode->i_uid &&
<trulux> got it?
<trulux> it will default to 1 though
<trulux> pitti: fixing the entry for default sysctl setting on Kconfig
<trulux> should be an int and not a stupid bool
<trulux> range 0 1
<trulux> 	default 1
<trulux> that makes the user either selecting 0 or 1 and nothing more, defaulting to 1
<trulux> is it OK for you now?
<trulux> you need to read *all the context*, not only certain code blocks. need to have a perspective on how it works
<trulux> it's like women
* trulux grins
<\sh> ogra: u r right...it's nicer then my try ;)
<ogra> \sh, take it or leave it ;) i wont delete it :)
<pitti> trulux: it still looks somewhat redundant to me, but if you think that's the way to go, then for my sake...
<\sh> ogra: send it to jdub ;)
<ogra> \sh, oki
<pitti> trulux: wouldn't a bool be more appropriate?
<trulux> pitti: it's just the way I like to do it. making it a bool would be simplier, but who cares. I can change it, it will work same way. just less completeness
<Kamion> elmo: please sync fdutils 5.4-20040228-4 from unstable; OK to override Ubuntu changes
<trulux> pitti: same location, refreshed (http://pearls.tuxedo-es.org/patches/security/kern-security-1.patch)
<pitti> trulux: okay, this requires a completely new build and to completely redo the packaging changes *sigh*
<trulux> pitti: will change into 2.6.12, I apologize
<trulux> doing it right now
<pitti> trulux: oh, so shall I wait until you have the 2.6.12 patch?
<pitti> trulux: you only need to change the sysctl from 68 to 69 and adapt the kernel/Makefile
<trulux> pitti: OK
<trulux> pitti: thanks
<trulux> pitti: what do you want? rc4? git? (snapshot)
<pitti> trulux: see your mail
<pitti> trulux: our breezy version
<pitti> 2.6.12rc4
<Kamion> elmo: please sync docbook-xml 4.4-4 from unstable; OK to override Ubuntu changes
<trulux> pitti: 2.6.12-rc4, sure? (I need a stackable patch, not a whole sources tarball)
<daniels> morning kamion
<pitti> elmo: if you are at it, please sync alsa-lib, too ; TIA
<pitti> trulux: yeah, sure
<Kamion> hi daniels
<trulux> pitti: thanks
<trulux> pitti: I need to fix a bug in andrew morton's patch-scripts, will send him a patch and then re-refresh the patch for 2.6.12
<trulux> pitti: will take a short while
<trulux> BTW, anyone has seen The Exorcist: The Beginning?
<Simira> who is the laptop compability guy?
<Kamion> mjg59
<Simira> ok, thanks
<Simira> hm, he's asleep
<Simira> enrico_ :)
<enrico> Hi!
<Simira> Kamion: you know some laptop stuff too, don't you? bjorninge her has a problem with the battery state indication on his Toshiba
<mdke> hi enrico 
<Simira> s/her/here
<Kamion> Simira: me? no
<bjorninge> :(
<Simira> anyone else?
<lamont> seb128: libwnck has nonPIC in shlibs
<lamont> libwnck_2.11.1-0ubuntu1 to be precise... maybe I already told you that
<elmo> kamion/pitti: syncs done
<pitti> thanks
<elmo> pitti: xmlto installed
<pitti> great
<elmo> doko: breezy/ia64 has binutils' build-deps
<pitti> seb128: now you can upload the gstreamer :-)
<elmo> seb128: galeon is still in the sync blacklist
<Kamion> ta
<pitti> seb128: ... so let's prepare for a long weekend's worth of furious bug reports about breaking sound :-)
<doko> elmo: cool
<doko> elmo: hmm, which host?
<elmo> doko: halley
<elmo> hmm, help if I gave people passwd entries tho
* lamont tries to remember the official process for requesting that a package move from universe to main
<Kamion> elmo: can mountfloppy get synced, despite being new?
<doko> seb128: hmm, but galeon depends on mozilla-dev, which thom did not update yet ..., so this has to be done first
<elmo> Kamion: it's not in NEW?
<Kamion> elmo: sorry, I mean lower-case new to Ubuntu
<Kamion> it's in Debian as of recently
<elmo> Kamion: if it's not C++, I don't see why not
<Kamion> it's not
<jdub> elmo: planet sync please :)
<pitti> jdub: you mean "main"?
<daniels> elmo: if you could make sure x11proto-* gets NEWed tonight (your time), that'd be great, thanks
<daniels> elmo: (* -> {bigreqs,composite,damage,evie,fixes})
<jdub> pitti: (planet ubuntu)
<elmo> Kamion: synced
<elmo> jdub: done
<Goshawk> lp
<Goshawk> ops sory
<Goshawk> sorry
<jdub> elmo: thanks
<bluefoxicy> bluefox@icebox:~$ ldd /usr/bin/gnome-session | awk ' {print $3}' | grep ^\/ | sort | uniq | readahead-fileordering
<bluefoxicy> bluefox@icebox:~$
<bluefoxicy> does this program even do anything?
<bluefoxicy> I'm trying to write a script that reads all of gnome ahead into memory
<zyga> bluefoxicy: hello
<bluefoxicy> hi
<zyga> bluefoxicy: reads all of gnome into memory?
<daniels> elmo: thanks a lot
<zyga> bluefoxicy: like prelink + cat $foo > /dev/null
<bluefoxicy> wow this takes forever.
<bluefoxicy> zyga:  readahead running against everything ldd returns for gnome-session gnome-panel and nautilus
<zyga> bluefoxicy: I wonder what windows does to get up so fast
<bluefoxicy> oh nm I had an infinite loop
<ozamosi> zyga, when windows has "loaded up", half of the loading is still to go. After one minute it start to do something, and then it keeps doing things for about half an hour...
<zyga> ozamosi: I know but it still has UI stuff for the user to look at alot faster
<zyga> ozamosi: one thing FOSS can't do easily is preload window manager
<zyga> ozamosi: unless this is a one-wm box
<seb128> lamont: yep, that's not NEW, but I need to learn how to fix such bugs, that's on my list :)
<seb128> pitti: cool :)
<lamont> ah, ok.
<seb128> elmo: oh, k, thanks
<bluefoxicy> ok what the FUCK
<lamont> seb128: the answer is, of course, to use -fPIC and/or link shared libs against shared objects... :-)
<seb128> s/NEW/new/ ...
<bluefoxicy> shift control T
<bluefoxicy> closes gnome-terminal
<zyga> bluefoxicy: mind the s/F.../Frell/
<bluefoxicy> now cookie goes to anyone who knows why I have a problem with this
<seb128> lamont: yeah, that I know ... that's rather the autofoo stuff that are an issue for me atm :p
<Kamion> it's a frequently reported bug at the moment
<daniels> bluefoxicy: are you using breezy?
<bluefoxicy> daniels:  yes
<bluefoxicy> daniels:  you want some of my weed?  :/
* bluefoxicy doesn't know what he was smoking when he switched to breezy but it must've been good stuff
<zyga> btw, does anyone know how to probe for the right framebufer device?
<zyga> (by right I mean for relevant graphics card)
<daniels> bluefoxicy: known bug.  welcome to breezy ...
<chmj> bluefoxicy: sure enough 
<daniels> zyga: define 'right'
<bluefoxicy> daniels:  then I won't bother making a bug report
<zyga> daniels: for example I have neomagic chip so I modprobe neofb
<daniels> bluefoxicy: please don't, because there are already about 50
<zyga> daniels: I could have modprobed for vesafb but that's suboptimal
<Hatred> I keep getting these strange errors every time i try to use apt-get... ---> E: Dynamic MMap ran out of room || E: Error occured while processing libhdf4g-doc (NewVersion1)
<Hatred> can anyone help??
<daniels> zyga: there's no real good way of doing this, and half of the framebuffer drivers are broken in various ways anyway
<zyga> daniels: I see :/
<daniels> zyga: (including really bad interactions with xorg)
<bluefoxicy> daniels: do you have a good way for me to derive the executable to run from an icon?
<zyga> daniels: I've got a bunch of really old laptops that I use from time to time ;] 
<daniels> bluefoxicy: uhm, no.  why would I have that?
<bluefoxicy> dunno
<bluefoxicy> this is painful though.  A lot of these things run scripts that load the actual program
<zyga> daniels: they got a few different chips and the tiny script I have just checks for hostname but that's poo
<zyga> poor
<bluefoxicy> I want nifty readahead tricks like on mouse over, readahead the app
<daniels> um
<zyga> bluefoxicy: you could do that for .desktop files
<daniels> you know how to do that?  it doesn't involve getting the icon
<daniels> it involves hacking nautilus/the panel or whatever to have a custom mouseover handler.
<daniels> but this is offtopic for #ubuntu-devel, methinks
<bluefoxicy> daniels: bluefox@icebox:~$ file /usr/lib/mozilla-firefox/firefox
<bluefoxicy> /usr/lib/mozilla-firefox/firefox: Bourne shell script text executable
<daniels> bluefoxicy: dude, SO WHAT?
<bluefoxicy> daniels: script I wrote runs ldd on an app and readaheads its entire first level list of libraries
<daniels> ... look at the shell script, this isn't a bug
<bluefoxicy> I know
<daniels> please stop spamming #ubuntu-devel
<Kamion> yeah, so change the .desktop files to have a mouseover handler that readaheads the real executable
<bluefoxicy> oh
<daniels> Kamion: you'd need to extend the .desktop spec
<doko> elmo: please sync libunwind from experimental
<Kamion> daniels: yeah
<Hatred> I keep getting these strange errors every time i try to use apt-get... ---> E: Dynamic MMap ran out of room || E: Error occured while processing libhdf4g-doc (NewVersion1)
<Hatred> can anyone help??
<Kamion> do you have a very old version of apt?
<Kamion> or an incredibly large number of entries in /etc/apt/sources.list?
<Kamion> (http://bugs.debian.org/178623)
<jordi> ah, the memories
<Hatred> no niether
<Hatred> 8 in my sources.list
<Hatred> ' apt 0.5.28.6 for linux i386 '
<Kamion> that's the version from Debian testing/unstable, not the one in the current version of Ubuntu
<Hatred> aah i see :s
<Kamion> we recommend against mixing Debian and Ubuntu repositories; our apt hackers say that it confuses apt
<Kamion> or at least mdz did
<daniels> elmo: having x11proto-dmx too would be great
<Hatred> so what do i do Kamion ?
<Kamion> Hatred: ask for help in #ubuntu rather than #ubuntu-devel? :-) I don't have any more information beyond what I've said so far ...
<abarbaccia> hey all - im running breezy and thought it would be good to point out that the whole thing broke today because of x not being able to find the font 'default'
<cartman> abarbaccia: breezy is not supposed to used until cxx transition is over
<daniels> the lesson here is 'don't run breezy unless you're confident fixing it when it breaks'
<mdke> even then, think twice
<abarbaccia> daniels - well, usually little things i can fix - i just dont know how to adjust the font path
<daniels> abarbaccia: xorg.conf
<cartman> daniels: xkb still foobared here btw but no new X.org hit to archive 
<abarbaccia> thank you all!  i appreciate it
<daniels> cartman: nope, I was asked not to upload, so I'm not
<daniels> also, I'm going to sleep now since it's 0223 and my eyes are bleeding
<cartman> daniels: -16 didn't hit either
<cartman> but its uploaded
<cartman> and logs says sucessfully built
<cartman> must be a transition thing, nm
<daniels> cartman: er, -16 is only on my hard drive at the moment
<cartman> oh I am daydreaming then which is quite possible
<daniels> http://people.ubuntu.com/~lamont/buildLogs/x/xorg/6.8.2-16/ -> 404
<Kamion>       xorg |   6.8.2-15 |        breezy | source
<cartman> was checking 6.8.1
<cartman> :/
<daniels> night
<cartman> nighty night
<Lathiat> woo x uploads
<zyga> hello
<zyga> could anyone confirm that 'http://dean.edwards.name/my/misbehaviors/#noIE-popup' sigsegv's their firefox?
<zyga> it works on current ubuntu's ff on amd64
<Treenaks> zyga: yes.
<Treenaks> (i386)
<g14> zyga: Does the same to mine
<Lathiat> my firefox crsahed on that after a bit. :)
<zyga> I'll try that on vainlla 1.0.4 and file a bug, thanks guys
<Lathiat> glad not to be of help.. or something. :)
<zyga> vanilla even :-)
<cartman> doesn't crash here
<zyga> err... no official for amd64?
<cartman> 1.0.4 amd64 build from somewhere =)
<cartman> zyga: right
<zyga> cartman: interesting
<cartman> http://www.srijith.net/firefox/index.shtml
<cartman> I use those builds
<zyga> tested again with -safe-mode, dies as well
<zyga> d'oh.. I've got to build firefox *again*
<Treenaks> zyga: <3 ccache
<zyga> Treenaks: ?
<zyga> Treenaks: ah :>
<zyga> Treenaks: I'm more angry because I don't remember how to build it exactly ;] 
<Treenaks> zyga: dpkg-buildpackage
<zyga> thanks!
<zyga> thom said a few days ago that security subdir is somewhat broken with regards to build process
<dholbach> hellas!
<zyga> firefox depends on cairo? does that mean I get nifty svg stuff :> ?
<thom> zyga: possibly
<zyga> thom: hey I'm trying to build firefox ATM
<JaneW> jdub: ping
<zyga> thom: but I cannot remember how to enable debug, do I have to do anything explicitly?
<JaneW> can anybody remeber what happened with FindingPackages after UDU?
<JaneW> it's not explicitly part of the Breezy Goals now, and I can't remember what if anything was decided there...
<cartman> thom: did have time to look at https://bugzilla.ubuntu.com/show_bug.cgi?id=10679 ?
<thom> zyga: DEB_BUILD_OPTIONS="nostrip debug"
<thom> cartman: no, i've been offline the last couple of days
<jdub> JaneW: it's a high priority goal
<thom> you'll know when i've looked at it, because i'll do something with it
<cartman> thom: ok
<jdub> JaneW: it needs further specification though
<doko> thom: do we need a new mozilla upload?
<jdub> JaneW: (feedback from ISVs, our requirements, etc)
<doko> (or is this already built with 3.4?)
<thom> doko: istr building moz with 4.0
<ogra> JaneW, mvo held it iirc
<doko> thom: fine, you trust it? ;)
<ogra> thom, your debug packages didnt crash :(
<thom> ogra: i know, sucks much huh?
<ogra> heh
<dholbach> thom, ogra: where is the debug package? :-)
<ogra> yeah, its a bit pointless to run a debug binary if it doesnt crash
<zyga> thom: maybe you can tell me if fresh firefox crashes on the URL pasted above?
<ogra> dholbach, got a i386 now ?
<dholbach> no, i thought you referred to the debug package NOT crashing on AMD64
<dholbach> then i'd given it a spin
<ogra> dholbach, i reverted to mozilla-firefox for now.... it just costed me half of the mono stuff i'm just playing with
<dholbach> (and even if it didn't crash, it'd be useful ;-))
<thom> zyga: doesn't crash here
<JaneW> jdub, ogra: but it doesn't even feature on the BreezyGoals page, and I can't rember why...
<ogra> hmm
<zyga> thom: good, I'll build it here anyway just to be sure
<jdub> JaneW: dunno, we'll have to ask :)
<JaneW> jdub: ok
<jdub> JaneW: please stick it in high though, we need it on the agenda :)
* JaneW must go, dinner time
<JaneW> jdub: will do
<jdub> ciao
<zyga> is there any wiki page that tracks xorg's transition? I could not find any
<thom> cartman: i think you didn't read ther Changes file that NEWS.debian tells you to
<thom> remove /etc/apache2/mods-enabled/perl.conf
<cartman> thom: uhm shouldn't post install take of that?
<Kamion> zyga: I think it's a "just do it" thing
<thom> cartman: not so much, given it's a user modifiable file
<seb128> elmo: can you fix libgnome-menu2 beeing universe instead of main? 
<ogra> zyga, there is a roadmap page in the udu wiki
<cartman> thom: ok but will I still have mod_perl ? /me goes to read the README
<zyga> Kamion: the wiki page? I'd love to do it as long as I don't have to break my box
<thom> cartman: yes
<zyga> Kamion: (by installing halfway thru xorg)
<cartman> thom: rocks thanks. Will you close the bug or shall I?
<ogra> zyga, http://udu.wiki.ubuntu.com/XRoadmap
* dholbach points to the topic, reads "breezy probably well broken" and wonders what "probably" is doing there :-)
<cartman> dholbach: its definitely broken :)
<Treenaks> dholbach: it still Works For Me
<Treenaks> but I don't dare logout ;)
<zyga> ogra: thanks
* ogra has no problems.... just dont upgrade ;)
<zyga> ogra: I did upgrade two days ago
<zyga> ogra: but that was on a box far far away 
<ogra> heh
<trulux> oh, pitti is gone ;(
<ogra> it weekend :=
<cartman> thom: I closed the bug with an explanation, thanks
<ogra> its even ;)
<zyga> ogra: I'd love to update it further to check if it works now but I cannot do that to my last box :-)
<ogra> zyga, i wouldnt :)
<ogra> as long as you need something that half way works
* lamont lunches
<Kamion> zyga: (what I originally meant was that daniels was just doing it all, but then I got distracted by the phone - XRoadmap was a good answer)
<doko> Kamion: what is dpkg-architecture supposed to print for DEB_BUILD_GNU_SYSTEMon the Hurd?
<Kamion> doko: it's been a long time, but I think 'gnu'
<Kamion> that's certainly what my reading of current Debian unstable dpkg-architecture says
<doko> Kamion: yes, but breezy's dpkg-architecture ...
<Kamion> doko: same
<doko> one bit that didn't change? amazing :)
<Kamion> heh
<Kamion> Keybuk had already fixed dpkg-architecture upstream BTW, he just forgot to upload it ;)
<nxvl> hi
<Riddell> Kamion: any opinion on letting a Kopete package into hoary-updates so Kopete users can use MSN?
<nxvl> im looking in the web page if there is some point in i can help, but i can't found how is the proces to become an Ubuntu Developer
<Riddell> nxvl: MOTU
<dholbach> nxvl: you may want to join #ubuntu-motu :-)
<nxvl> Riddell: !?
<nxvl> Riddell: and this is??
<Riddell> https://www.ubuntu.com/wiki/MOTU
<nxvl> ok
<nxvl> thnk u
<Riddell> nxvl: universe maintainers, help them out somehow then go through the membership process http://www.ubuntulinux.org/community/processes/newmember
<Kamion> Riddell: I saw something about that earlier, and thought I'd replied, but I can't remember now what channel it was on
<trulux> tseng: heya folk
<Kamion> Riddell: jdub said he thought it was a good idea, and I agree
<trulux> going to rebuild some packages
<trulux> wanna write some on PSC 1350
<trulux> we need some scripts around to get this all working
* trulux sets weekend-hackathon mode ON
<Riddell> Kamion: cool, want to check before I upload?
<Kamion> Riddell: yeah, put the diff somewhere and give me the URL?
<Riddell> it's not trivial  http://dev.kubuntu.org.uk/~jr/kubuntu/kdenetwork/kdenetwork.diff
<Kamion> you're not kidding - ok, let me read through all this
<Riddell> it's mostly just adding a file sslloginhandler.cpp,h which is taken from KMail I think
<cartman> Riddell: taken from KMess
<cartman> which is an msn client for KDE
<Riddell> cartman: ah, interesting
<cartman> it looks cool :)
<dholbach> KMess is a bit unlucky name :-)
<cartman> dholbach: heh indeed
<cartman> they meant KMessenger possibly
<Kamion> +  // Get everything between "DLLogin=" and to the comma.
<Kamion> +  serverData = serverData.right( serverData.length() - serverData.find( "DALogin=" ) - 8 );
<Kamion> I assume it's the comment that's wrong rather than the code? :)
<Kamion> OK, well, er, yuck, I'm glad I don't write IM code
<Kamion> but it seems a reasonable update
<Kamion> that's directly backported from a new upstream release?
<Kamion> and tested?
<cartman> Kamion: yes
<Riddell> fixes it for me
<cartman> its tested <-- yes to this
<Kamion> ok, go ahead and upload to hoary-updates
<Riddell> Kamion: yes, directly taken from 3.4.1 SVN
<Riddell> Kamion: do you know if the c++ blocks will reject it?
<Kamion> nothing in hoary-updates is actually being built at the moment AFAIK; you'll probably have to be patient until next week
<Riddell> Kamion: if I upload will it keep it there until next week or should I just upload later?
<mako> Kamion: i'll have a few things for that :)
<Kamion> Riddell: upload it now, if it doesn't build it'll sit there as source, like knetworkconf
<Riddell> ok
<Riddell> Kamion: what's the version number to use for hoary-updates?  2.1 or 3?
<Kamion> it doesn't really matter, but if you use 3 then you won't be able to use that for breezy, which might be confusing - so I'd be inclined to use 2.1
<zyga> thom: ping
<Riddell> uploaded, thanks for your help Kamion 
<zyga> thom: http://pastebin.com/287067
<Kamion> Riddell: kdenetwork | 4:3.4.0-0ubuntu2.1 | hoary-updates | source
<surak> Kamion:
<surak> having some trouble with initrd from live
<Kamion> hm?
<surak> When it's copied to hard drive, it panics the kernel. Replacing it with install initrd fixes this.
<Kamion> er ... they're the same initrd
<Kamion> that was a design goal
<Kamion> cjwatson@little:~/cdimage/www/simple/hoary$ isoinfo -i ubuntu-5.04-install-i386.iso -x /install/initrd.gz | md5sum
<Kamion> d41d8cd98f00b204e9800998ecf8427e  -
<Kamion> cjwatson@little:~/cdimage/www/simple/hoary$ isoinfo -i ubuntu-5.04-live-i386.iso -x /install/initrd.gz | md5sum
<Kamion> d41d8cd98f00b204e9800998ecf8427e  -
<surak> Odd.
<Kamion> when you say "install initrd", do you mean the one that's on a normal installed system, or the one that's on the install CD?
<surak> installed system.
<surak> this is the same md5sum I have with the initrd which panics
<Kamion> oh, right. You certainly shouldn't use the initrd from the CD on the installed system; it's not at all designed for that.
<Kamion> Run mkinitrd after copying /.
<Kamion> see the linux-image postinst
<surak> ok
<Kamion> you might be able to dpkg-reconfigure linux-image-<whatever>
<Kamion> (to get it to run mkinitrd for you)
<surak> This and a fully functional /dev are which is bothering me today.
<Kamion> you may have some complications because the live CD uses some devfs-style paths for historical reasons
<surak> yes
<Kamion> what problems does it cause for you?
<surak> No, is not devfs, but finding a way to correctly create a /dev on installed system.
<Kamion> mount udev?
<Kamion> or rather start it
<surak> udevstart works
<Kamion> that's probably overkill though
<Kamion> there'll be a /dev in the installed system once you reboot, because udevstart will happen
<surak> ?
<Kamion> until then, why not 'mount --bind /dev /target/dev'?
<camilotelles> Kamion: can you explain the casper to us?
<Kamion> camilotelles: what do you want to know about it in particular?
<Kamion> (I can, but I'm not sure where you want me to start)
<Amaranth> what's up with planet mako?
<camilotelles> what is the casper's purpose, this is not clear to me. 
<dilinger> 800 channels of all mako, all the time
<g14> Casper is the livecd / installer if I'm not mistaken
<Kamion> camilotelles: casper is the component that mounts, prepares, and starts up the live filesystem
<Kamion> it hooks into the installation system
<camilotelles> especially because of this part of the UbuntuExpress Wiki " If the modified filesystem is copied, some of the modifications made to it by casper must be reversed"
<Kamion> camilotelles: look in casper/pre.d/ and casper/post.d/ in the casper source package; you'll find a number of hooks which make various changes to the live filesystem before and after pivoting into it
<Kamion> like setting up /etc/fstab, adding the 'ubuntu' user, setting up autologin, ...
<Kamion> all clearly things that need to be undone when producing a regular installation
<Kamion> and there are some things that casper currently removes, where we'll need to change casper to just move them aside instead so that UbuntuExpress can move them back
<camilotelles> kamion: beetween the pre.d and post.d of the casper is the copy?
<Kamion> no, pre.d -> pivot_root -> post.d
<Kamion> no copy
<Kamion> see debian/casper-udeb.postinst for the main control flow
<camilotelles> thats ok. it's more clear to me now. will take a look.
<camilotelles> thanks.
<Kamion> you'll probably need to go through all of casper's hook scripts (and note that not all of them are in the casper source package itself - there are some in other installer components, in order to reuse code) and work out a strategy for dealing with each of them
<Kamion> we'll be happy to help make those hooks more UE-friendly if necessary
<camilotelles> UE-friendly?
<surak> ubuntuexpress
<Kamion> what he said
<camilotelles> :)
<camilotelles> ok. back to work.
<camilotelles> Kamion: thanks one more time.
<Kamion> no problem, here to help
* lamont delunches
<lamont> seb128: gnome-libs_1.4.2-20 is ftbfs with current xorg.
<seb128> I don't care about old GNOME1 craps :p
<lamont> but it's in main.....
<lamont> :-)
<seb128> ok ok ... :)
<seb128> anyway about gnome-menus
<Kamion> how come it's in main, anyway? it's blacklisted
<seb128> that's due to soname change to universe instead of main
<seb128> need elmo to fix that?
<lamont> yues
<ogra> huh ? gnome1 is in main ? 
<lamont> archive placement is elmo
<seb128> k
<Kamion> hmm
<lamont> jbailey: ping
<Kamion> openoffice.org2 build-depends unixodbc-dev depends gtkodbcconfig0 depends libgnome32
<seb128> lamont: any idea of what's wrong with nautilus-cd-burner?
* lamont hands kamion a lolly
<seb128> hate hate hate bz2 logs
<seb128> somebody is working to fix this?
<lamont>   libnautilus-extension-dev: Depends: libeel2-dev (>= 2.9.91) but it is not going to be installed
<lamont> seb128: on my list of things to do is (1) figure out how to tell apache to tell ffox that it's a gzip/bzip2 file, and therefore get the right answer.
<Kamion> no doubt there are other reasons it's in main, but I don't really want to bother tracking them down
<lamont> for autounpack
<seb128> seriously, instead of clicking on the file now you have to click, use file-roller, select an app and then you get the log
<seb128> lamont: I've read the log, any idea of why the buildd refuse to install that?
<seb128> works fine here..
<lamont> from the eel2 log:
<lamont>   libgnome-menu-dev: Depends: libgnome-menu2 (= 2.11.1.1-0ubuntu1) but it is not installable
<lamont> so, about gnome-menu
<lamont> ...
<seb128> grrr
<seb128> that's breaking all the GNOME builds
<seb128> where is elmo nowadays? :)
<lamont> ah, looks like eel2 might maybe be buildable...
<Kamion> so we need libgnome-menu2 -> main?
<lamont> libgnome-menu2->main
<lamont> fix that, kthxbye
<lamont> and tell me, so I can kick things
<Kamion> moment while I figure out how to run teri
<surak> What requires /mnt to exist on live?
<Kamion> lamont: done for the next cron.daily
<lamont> Kamion: woot!
<Kamion> surak: I didn't know anything did
<lamont> and that's even soon...
<seb128> Kamion: thanks, that's breaking GNOME for 2 days now
<surak> Kamion: I'm asking because I don't know why it's still there.
<Kamion> surak: just an empty directory?
* lamont wonders if there's a reason upload.ubuntu.com is refusing ftp connections
<surak> y
<lamont> Kamion: not sure which package install creates /mn t
<Kamion> surak: it's shipped by base-files - nothing to worry about
<lamont> ah. ok
<Kamion> if something's mounted on it, that would be stranger
<Kamion> it's basically meant for users to mount things on temporarily
<surak> I'm using /media for this. Am I wrong?
<Kamion> surak: I wouldn't mount things on the top level of /media; stuff gets mounted in subdirectories of /media by pmount
<Kamion> anything else that desperately needs promotion to main, before I run away for the evening? preferably binaries whose source packages are already in main, so they're just renames or whatever
<Kamion> there aren't many on that part of the list, none look desperately critical
<Mithrandir> hmm, I should stuff guifications on desktop.
<Mithrandir> that is, the desktopseedproposals
<Kamion> seb128: will python-gmenu still being in universe break GNOME builds?
<surak> Kamion: pmount is meant for stuff which is not at fstab - guess I'm fine with /media
<lamont> Kamion: dunno.
<Kamion> surak: pmount and other things
<Simira> Treenaks: are you awake?
<lamont> Mithrandir: while you're hacking the seed proposals... could you add palo to base for me?
<seb128> Kamion: no
<Kamion> if you want to use /media, I'd create a subdirectory if I were you
<lamont> hppa needs it
<Kamion> s/base/minimal/
<seb128> Kamion: only libgnome-menu2
<lamont> Kamion: doh
<lamont> thanks
<Mithrandir> lamont: willdo
<lamont> ftp upload.ubuntu.com
<lamont> ftp: connect: Connection refused
<lamont> ftp> 
<Kamion> Mithrandir: stick palo-installer in installer as well
<lamont> am I just hated?
<Kamion> lamont: are we moving hppa stuff to main, then?
<Mithrandir> lamont: it hates me too, if it makes you happy.
<lamont> Kamion: I'm proposing that.
<Simira> lamont: we all love you 
* Simira poures some Ubuntu-love on lamont
<lamont> Kamion: is kdelibs4c2 stuck in universe?
<lamont> Simira: ew... sticky
<lamont> Kamion: the other option for hppa is to teach d-i to build hppa bits using universe as well.....
<Kamion> lamont: no, it's been in main for a while
<Simira> lamont: it's well meant ;)
<Kamion> I mentioned that on -toolchain when doko asked the same
<lamont> Simira: sometimes sticky is good... :-)
* lamont needs to wakeup
<Simira> mm...
* Simira sticks to LoCo-work
<Simira> smurfix: are you awake, then?
* ogra curses C++
<Mithrandir> Kamion: uhm, where's the installerseed again?
<smurfix> Simira: Yeah
<Simira> yay! The LoCo guy!
<smurfix> heh
<Kamion> Mithrandir: same place as all the other seeds
* doko doesn't see anything why ogra should curse .. *duck*
<ogra> ../sigcx/tunnel.h:223: error: no matching function for call to 'pack(SigC::Slot1<bool, const std::string&>&, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
<ogra> doko ^^^
<willis> just trying to get a handle of the build process, i see that gnome-menus built on the 18th succesfully but eel2 failed today because it's missing lib-gnome-menu-dev, which as built on the 18th?
<Kamion> willis: I only just moved libgnome-menu2 into main twenty minutes ago
<Kamion> the lack of that would have stymied libgnome-menu-dev somewhat
<willis> ah so if it's building a package from main, it only pulls from main?
<ogra> willis, sure
<willis> ok thanks
<lamont> seb128: libao_0.8.6-1ubuntu1: cp: cannot stat `debian/tmp/usr/lib/ao/plugins-2/libnas.so': No such file or directory
<seb128> lamont: k
<seb128> doko: what should be done for apps like evince? be updated now?
<doko> seb128: looking at the build deps, they can be built and I'll upload them as -buildN, when all C++ libs are built in main.
<seb128> doko: k, because I want to try some stuff with the new poppler and evince is removed because of poppler name change
<seb128> so just wondering if I can upload a evince rebuild now
<Kamion> well, you can't upload anything *right* now ...
<seb128> bah
<doko> seb128: if you upload it, it will be rejected ;)
<Kamion> doko: wasn't what I was thinking of
<seb128> if I can contact the ftp first :p
<Kamion> poppy's fallen over inexplicably, so upload.ubuntu.com is refusing connections - I can't restart it, it'll have to wait 'til elmo gets back
<seb128> doko: any idea on how long it will take before getting uploads accepted again?
<seb128> (supposing than upload.u.c is fixed :p)
<doko> waiting, that dbus, libtunepimp are built, don't know, why they are not built, they are accepted. maybe lamont or Kamion do know more?
<lamont> if they're accepted, then they should be just waiting for cron.daily.
<lamont> but given that no uploads are happening right now........
<Kamion> they were accepted a few cron.dailies ago
<Kamion> devel/dbus_0.33-0ubuntu3: Dep-Wait by buildd+terranova [optional:out-of-date] 
<Kamion>   Dependencies: kdelibs-dev (>= 4:3.4.0-0ubuntu6)
<Kamion> that d-w can be cleared now, can't it?
<Kamion> seeing as it's on a nonexistent package
<lamont> yeah - is virtual package.
<lamont> damn virtual dep-waits
<lamont> kicked
<lamont> or rather, kicking
<doko> yes, I fixed it in ubuntu3
<jordi> doko: hey
<Kamion> libs/libtunepimp_0.3.0-2ubuntu7: Dep-Wait by buildd+vernadsky [optional:out-of-date] 
<Kamion>   Dependencies: libid3tag0-dev (>= 3.8.3-4.1ubuntu1)
<Kamion> there are two packages that could be
<Kamion> libid3-3.8.3-dev | 3.8.3-4.1ubuntu1 |        breezy | amd64, i386, ia64, powerpc
<doko> should be cleared, was a wrong version
<Kamion> libid3tag0-dev |  0.15.1b-6 |        breezy | amd64, i386, ia64, powerpc, sparc
<Kamion> pick one
<doko> jordi, hey, how was the triatlon without training?
<jordi> doko: tomorrow. I'm totally worried about it.
<lamont> clearing
<doko> lamont: libgnomeuimm2.6 ?
<lamont> libs/libgnomeuimm2.6_2.10.0-0ubuntu2: Installed by buildd+terranova [optional:out-of-date] 
<jordi> lamont: hey, I'll try to have a look at the wireless card thing next week
<jordi> I totally forgot because I haven't used it much yet, I'm not at home that much during nights now
<lamont> doko: installed on ppc as well, building on amd64,ia64
<lamont> which is to say, waiting for libgconfmm-2.6-1
<doko> and unixodbc on powerpc cannot be built due to some inconsistent gnome deps, but I cannot see why.
<doko> libgconfmm-2.6-1 is now libgconfmm-2.6-1c2
<surak> dumb question: does ubuntu runs on ibm powerpcs?
* lamont tries giving back on ia64/amd64
<jordi> surak: should, afaik
<Mithrandir> jordi: you maintain alsa stuff, don't you?
<Mithrandir> jordi: do you know the udev dev.d model and do you have any great ideas wrt how to keep the alsa packaging in ubuntu as close to debian's as possible while still going for dev.d scripts?
<jordi> Mithrandir: what do you need in dev.d?
* jordi curses mako as he plays Street Fighter 3
<Mithrandir> jordi: the point is to start alsa when the alsa driver is loaded.
<jordi> sddddddddddsdgssaasab
<jordi> Mithrandir: is there a bug number for this?
<Mithrandir> jordi: there's a spec for it.  UdevRaces.
<jordi> oh, I saw it in Sydney spec wall, and though "hmmm, alsa" :)
* Kamion -> evening, see you
<surak> night
<dholbach> night Kamion 
<g14> Has anyone considered porting redhat's native eclipse efforts to ubuntu? eclipse is the only thing stopping me from moving several devs here over to ubuntu
<Amaranth> redhat pushes java, novell pushes mono, ubuntu pushes python ;)
<dholbach> g14: http://udu.wiki.ubuntu.com/JavaRoadmap :-)
<g14> Amaranth: I use eclipse for Python development. pydev is the only gpl python ide that I know of supporting autocomplete and it is an eclipse plugin
<Amaranth> does it do real autocomplete?
<Amaranth> like if i import foo it'll autocomplete foo.<stuff here>?
<g14> Amaranth: For the most part, yes, but autocomplete was just added http://pydev.sourceforge.net/index.html
<g14> dholbach: That says eclipse will be in multiverse? Redhat made native eclipse that doesn't require a jvm and using 100% oss software. Why couldn't that be ported to ubuntu?
<dholbach> g14: multiverse generally is for stuff with problematic licenses
<dholbach> g14: i'm not quite sure, but i recall one of its dependencies to be problematic, right?
<dholbach> g14: that lucene stuff maybe?
* dholbach shrugs
<g14> dholbach: I don't think you fully understood me. Redhat modified eclipse so it compiles with gcj into an elf executable as in no license encumbered jvm required
* ajmitch waves
<dholbach> hey ajmitch 
<dholbach> g14: what apart from gcj does it need?
<g14> dholbach: They made some changes to the eclipse code, libgcj, and I think it gcj itsself. This might help http://blog.gmane.org/gmane.comp.ide.eclipse.gcj
<jordi> Mithrandir: ok
<jordi> Mithrandir: first, I guess we'd need a check in the init.d script to not run if udev is found to be running, right?
<g14> dholbach: I can yum install the whole eclipse environment in fedora or rhel and it is fully gpl. If someone were to work on that for ubuntu, do you think it would be accepted, to universe?
<jordi> and if it's running, alsa would be run from dev.d
<Mithrandir> jordi: yeah, I'm considering that.
<Mithrandir> jordi: yup, I think that's a sane way to start
<dholbach> g14: if none of the depends or build-depends are critical license-wise - sure!
<jordi> Mithrandir: Probably jdthood's input will be very useful here, he's the one who has been in contact with md about our udev troubles
<dholbach> g14: you might want to talk to the folks in #ubuntu-java
<Mithrandir> jordi: I'll ask him, then
<jordi> once we included some udev stuff in our package and we got rid of it after md complained
<dholbach> g14: because i'm no expert at all
<g14> dholbach: Didn
<jordi> dunno if that would include dev.d stuff
<g14> dholbach: didn't realize that channel existed. I'd love to switch over my devs to ubuntu. Even if I have to compile and package native eclipse myself. Thanks
<jordi> alsa-driver (1.0.6a-8) unstable; urgency=medium
<jordi>     - /etc/dev.d/sound/alsa-base.dev
<jordi>       + Add.  Runs "alsactl restore" after control
<jordi>         device is created  (Closes: #273090)
<jordi>     - /etc/udev/permissions.d/alsa-base.permissions
<jordi>       + Add.  Sets permissions on ALSA snd devices.
<dholbach> g14: anytime, if you can help them, they'll be happy :-)
<jordi>     - alsa-base.permissions:
<jordi>       + Eliminate at the request of the udev maintainer
<jordi> but apparently we were ok with dev.d
<g14> dholbach: One of my friends used to be one of the python coding grunts for canonical and he used pydev under eclipse so I'm sure alot of people would be happy
<dholbach> g14: i know lots of people who like it, so i'd love to see it in as well
<Mithrandir> jordi: ok, yay, I'll investigate further then.
<ogra> \sh, hey, you landed on the planet :)
<surak> what gcj-eclipse from redhat depends on?
<surak> I mean, in terms of packages.
<ogra> Treenaks, around ?
<seb128> ogra: when you reply to bugs on a list not made for bugs could you mention than the right place is bugzilla?
<seb128> you just encourage people to keep using it for bugs
<ogra> seb128, err, i told him thats it a known issue....not a bug...
<seb128> what is the difference with an issue and a bug?
<seb128> afaik the list is not for issues neither... :)
<seb128> there is a number of bugzilla bugs about this
<ogra> seb128, oki, i'll point to bugzilla next time :)
<seb128> thanks
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=11012
<seb128> weird
<\sh> ogra: hi :) 
<\sh> ogra: thx for your artwork and thx to jdub :)
<ogra> :)
<ogra> seb128, hmm, i'm wondering if he probably ran out of diskspace during the upgrade
<\sh> ogra: u read about my server crash?
<Amaranth> seb128: someone has a similar problem with breezy
<seb128> I know, I read the lists
<dholbach> good night pals, i'm off to bed
<ogra> its a bit weird that he says that dpkg didnt show the files...
<ogra> since they are in the package
<ogra> night dholbach 
<dholbach> night ogra
<Pupeno> Hello
<Pupeno> you are moving towards gcc4 ? awesome.
#ubuntu-devel 2005-05-28
<robertj> are there any plans for a step-by-step testing how-to for laptop compatability?
<Pupeno> I work with Lisp, so, for me, it is important to have recent versions of sbcl, slime, and lots of other packages related to Lisp. Ubuntu packages are outdated so I'm planning to make new packages whenever is possible. I notice for example, that there are some newer Lisp-related packages on Debian. So, what do you recomend me to do ?
<\sh> Pupeno: kde guy right?
<Pupeno> \sh: not anymore as I used to.
<Pupeno> \sh: KDE is still my prefeered desktop, but I don't do KDE dev anymore.
<\sh> Pupeno: but i think we had nice chats when I was coding kmyirc ;) 
<Pupeno> \sh: yes... I remember your 'weird' nick (no offense meant).
<\sh> so, nice to meet u again :)
* Pupeno too!
<Pupeno> \sh: did you continue doing kmyirc ? how are you doing ?
<\sh> Pupeno: well, no..konversation had more devs then kmyirc :)
<\sh> Pupeno: now kmyirc is only a source for koders ;) (the new source code search engine) 
<Pupeno> It is awesome how you keep encountering people... I used to hang a lot on #kde-devel and then I encounter people from there on #kubuntu, #ubuntu-devel, and the people I know from #lisp appear on #dylan and so on... like a true net.
<robertj> Pupeno: file a bug?
<robertj> Pupeno: if its in Debian it should find it's way into Breezy automatically
<seb128> what package?
<ogra> ???
<Pupeno> robertj: I like to file bug reports with some back up (like the package).
<Pupeno> robertj: oh... but I'm not using Breezy.
<robertj> <bother who='seb128'>Is Places Integration speced out yet on the wiki?</bother>
<robertj> Pupeno: check breezy, if it's not there, then file a bug
<Pupeno> seb128: sbcl, slime, cl-iterate and some others.
<robertj> if it is there, wait for Breezy
<seb128> robertj: not, it's supposd?
<calc> Kamion: readonly fixed debconf but in a bad way
<Pupeno> robertj: that's not an option for me, in that case, I'd start some backports or something like that.
<calc> Kamion: it doesn't fall back to the underlying system config.dat in that case and just throws away the choices
<seb128> pool/universe/s/sbcl/sbcl_0.8.17.4-1_i386.deb
<Pupeno> seb128: that's too old.
<Pupeno> sbcl 0.9.0 was released, and even in the 0.8 series, 0.8.21 was the latest.
<calc> Kamion: also the documentation on how to use it is faulty. It says to use DEBCONF_DB_OVERRIDE='File{Filename:/foo Readonly:true}' but Filename and Readonly are invalid, filename doesn't exist at all as a keyword apparently and readonly has to be lowercase
<robertj> seb128: kinda lost me on that last one though
<seb128> Pupeno: you should become a MOTU and help to maintain the packages
<seb128> Pupeno: breezy has 1:0.9.0.19-1
<Pupeno> seb128: I'll do it if necesary... but before puting a label "MOTU" on my chest, I'd like to produce some packages.
<robertj> what do you use LISP for?
<g14> robertj: Artificial intelligence. Mostly robotics programming
<robertj> gl4: ahh, academic, industrial, or *other* ;)
<g14> robertj: Well my best friend used lisp olmost exclusively for his BA in Artificial Intelligence. Not sure about industrial usage though
<robertj> ohh
<robertj> why bother with a BA in AI?
<g14> I asked him the same question :)
<robertj> All the real good stuff requires too much math to cram into a 4 year degree
<g14> Hes going for a masters, but is taking a break
<KaiL_> Not sure about industrial usage though << in industry the arguments to select a tool are "the salesman said, it's good" and "evenybody uses it" - so why should they use lisp? ;)
<robertj> I enjoyed my ARTI class, I whipped up on the grad-students
<robertj> KaIL: because LISP was used when the first robotic arm was brought in 20 years ago?
<KaiL_> ok, that could be an argument 
<KaiL_> ..until some salesman with some useless MS-Tool comes around the corner...
<surak> who brings the /dev/shm/network to /dev? it's not udev...
<robertj> there upper-level maths were no match for waypoints and brute force ;)
<robertj> also cheating!
<robertj> bump a tree...get an apple...get enough apples, monsters cant move adjacent to you ;)
<jdub> o/~ don't look down, no, no - go, go, underground! o/~
<jdub> tseng: ping
<jnc> mmm... i wish libgtkspell0 would get updated and stuff
* jnc :)
<tseng> jdub: hi
<lamont> ../../libparted/linux.c:1416: warning: comparison between signed and unsigned
<lamont> ew
<lamont> daniels: you around?
<daniels> of course not
<lamont> heh.
<daniels> 'sup?
<lamont> /usr/include/X11/xpm.h isn't there... is that a build-dep, or missing component in the #include?
<lamont> gcc -I. -I.. -I/usr/include/freetype2 -I/usr/include/freetype2/freetype -I/usr/include/X11 -g
<lamont> +-Wall -O2 -D_REENTRANT -pipe -DHAVE_LIBPNG -DHAVE_LIBFREETYPE -DHAVE_LIBJPEG -fPIC -DHAVE_XPM
<lamont> +-c -o gdxpm.o ../gdxpm.c
<lamont> ../gdxpm.c:22:17: error: xpm.h: No such file or directory
<daniels> -I/usr/X11R6/include
<daniels> actually, would need to be -I/usr/X11R6/include/X11 in this case
<jnc> erg...  if 'dmesg' disappears.   what package is supposed to provide that again?
<daniels> dpkg -S dmesg, should tell you
<lamont> jnc: util-linux
<jnc> i thought it was util-linux
<jnc> oh well
<jnc> i guess it's acting up again in breezy :)
<jnc> daniels: thanks
* lamont grumbles that hppa is the one finding all the x0rg b1rkage
<daniels> lamont: hey, it's not xorg breakage, it's application stupidity :)
<daniels> lamont: in any case, it really really should be <X11/xpm.h>
<jbailey> lamont: pong.
<lamont> daniels: yeah, well x0rg broke it.
<lamont> it used to work just fine... :-(
<lamont> jbailey: nfc what I wanted earlier
<daniels> lamont: xorg exposed previous breakage that used to work through luck
<daniels> when was that app written, anyway?  1991?
<jbailey> lamont: *lol*
<lamont> yeah, same thing.
<jbailey> lamont: glibc?  arts?
<jbailey> lamont: I'm trying to go through the scrollback and catch up.
<daniels> /usr/include/X11 is old-school
<lamont> jbailey: dunno
<daniels> common usage of that predates r6
<lamont> daniels: so is a lot of code... :-)
<daniels> yeah, r6 was released 11 years and 5 days ago
<lamont> heh
<lamont> could be about time to fix them, eh?
<lamont> and the fixed code will work either way, yes? (with or without symlinks)
<daniels> lamont: indeed
<daniels> lamont: if you fix it to <X11/xpm.h> and add -I/usr/X11R6/include, that's the best way
<daniels> since that will also pick up when I move xpm.h to /usr/include/X11
* lamont is just trying to get bugs filed for stuff..
<lamont> I figure I'll bounce it against mdz on monday, and then file all the hppa ftbfs packages as bugs...
<lamont> they're almost all really broken in the archive.
<lamont> alternatively, we could fire up breezy-test
<lamont> daniels: how soon you going to be done monkeying with include paths?
<lamont> because we may as well wait until then to run breezy-test
<daniels> lamont: probably another week, at this rate
<lamont> ok.
<jnc> /bin/bash: line 0: cd: build-tree/libfwbuilder-2.0.7: No such file or directory
<jnc> :(
<jnc> i'm new at making packages
<jnc> it's quite a bit more confusing than the gentoo stuffs i am used to
<lamont> jnc: debian/rules is just a makefile
<jnc> i think what i'm missing is how to make this automated and easy to do without thinking much
<jnc> i seem to be spending a lot of time when new versions of my favorite fw ruleset software comes out, tweaking so the new packages build
<ghpolo> is there an upcoming fix for util-linux package ?
<ghpolo> @ breezy
<Burgundavia> ghpolo, there is already a bug filed about it, so it will be fixed. Please be patient and don't come and bug the developers about it
<ghpolo> im patient
<ghpolo> ^^
<jnc> ghpolo: random stuff missing for you too, eh?
<ghpolo> yes, since yesterday i believe
<ghpolo> i posted once at mailisting aswell
<ghpolo> just checking how many people got it ^^
<ghpolo> dmesg, getty etc
<jnc> does that mean i should not reboot? ;o)
<ghpolo> i didnt ^^
<jnc> would suck if i could not log in haha
<ghpolo> or you could compile util-linux to get these tools again
<jnc> i'm preoccupied making fwbuilder packages
<jnc> i can live without computer upstairs
<ghpolo> heh
<jnc> if my phone service (VoIP controlled by fwbuilder rulesets on a wrt54gs) goes out... bad things happen to my paycheck
<lamont> evening doko
<lamont> or is that just you bouncing?
<crimsun> the latter, I think
<lamont> I rather expect so - it's kinda past his bedtime otherwise
* lamont sleeps
<ghpolo> hmm
<ghpolo> someone know a way to fix a really messed terminal ?
<ghpolo> (reset doesnt fix it)
<jdub> tseng: filed a bug on muine in malone :)
<g14> Why doesn't ubuntu use the suse cdrecord packages that have dvd+rw support built in? suse had to fork the code to do it
<g14> I just got a great error telling me to buy cdrecord-PRODVD from gnomebaker and wasn't very pleased
<fabbione> g14: man growfs
<bob2> did you install dvdrecord?
<fabbione> that's all you need :)
<fabbione> bob2: no no.. that's insane crap :)
<bob2> hah
<fabbione> just use growisofs
<fabbione> or something like that
* fabbione checks
<fabbione> yeah growisofs
* g14 still thinks the suse fork of cdrecord with bundled dvd+-RW support should be in ubuntu vs the upstream version
<g14> Free software shouldn't ask you to upgrade to the pro version for more features
<daniels> g14: could you please file a bug instead of repeating it on irc?
<fabbione> or use growisofs
<g14> I'll do both for now
<g14> fabbione: Thanks for the help
<fabbione> np
* fabbione goes off line
<pitti> Hi
<Hussam> I just wanted to point out that breezy's util-linux is missing /sbin/hwclock
<Amaranth> known, bug report filed
<bob2> please file a bug if no one else has
<Amaranth> util-linux is also missing dmesg and getty, i wouldn't restart if i were you
<bob2> hah
<Amaranth> ack, he left
<bob2> hm, where are the 2.6.12 test kernels?
<Amaranth> in universe
<bob2> ah
<bob2> ta
<Amaranth> you can't build modules for them
<bob2> oh, I know
<Amaranth> the 2.6.12 kernels are compiled with gcc 3.4 and ubuntu only provides 3.3 and 4.0
<bob2> I'm building a new install iso to see if 2.6.12 works with my sata controller
<bob2> I do know what a kernel abi is :-)
<cartman> fuck dmesg is gone lol
<Amaranth> yes
<cartman> Amaranth: thanks for info :)
<Amaranth> don't restart
<cartman> I am dead by next electric shortage
<cartman> *g*
<Amaranth> cartman: this is for smeg :)
<cartman> I love bleeding edge software :)
<Amaranth> oh, wrong channel
<Amaranth> nevermind about smeg
<Treenaks> I love greasemonkey.. it makes on-line banking so much nicer :)
<cartman> Treenaks: how come?
<Treenaks> cartman: I have a script that fixes broken popup stuff ("javascript:" links) and one that removes all target="_blank" attributes
<cartman> ha nice :)
<Treenaks> cartman: so it doesn't open new windows unless I ask it anymore..
<Simira> morning Treenaks!
<Treenaks> hi Simira 
<Simira> I've got a little case for you ;)
<cartman> anyone got the # of util-linux bug?
<bob2> cdebootstrap seems very unhappy about using hoary as the suite
<jdub> FEAR THE XORG UPLOAD
<Simira> jdub: doesn't your mother use Ubuntu?
<jdub> Simira: my metaphorical mother does
<Amaranth> jdub: daniels broke more things? :)
<Treenaks> Amaranth: no, it was fabbione this time :P
<Treenaks> or was it seb? :P
<Amaranth> uh oh
<Amaranth> i don't see any xorg upgrades available, i must have them already
<Amaranth> so, don't restart x then? :)
<Treenaks> Date: Sat, 21 May 2005 10:10:11 +0100 (BST)
<Treenaks> Amaranth: ot jasm
<Treenaks> *ahem*
<Treenaks> it hasn't been built yet
<Amaranth> ah
<Amaranth> wtf did you say before that?
<Treenaks> Amaranth: "it hasn" with one hand shifted
<Treenaks> and I hit enter instead of backspace
<cartman> Amaranth: ha :)
<daniels> jdub: small uploads are for weenies
<daniels> jdub: although the codebase is at least shrinking every time I upload it
<Amaranth> Treenaks: that's worse than ;p; (lol)
<Treenaks> Amaranth: :)
<jdub> daniels: getting rid of all those syscalls ;)
<daniels> heh
<daniels> syscalls are shit, who needs 'em?
<jdub> yeah, just get in the way
<Amaranth> hey if it's shrinking that means more room on the live cd
<cartman> uhgm btw libtunepimp2 has wrong deps.
<cartman> depends on libmusicbrainz4 instead of libmusicbrainz4c2
<Treenaks> tunepimp?
<daniels> cartman: needs a recompile
<Pupeno> I have just finished packaging sbcl 0.9.0 for (k)ubuntu! :D
<cartman> daniels: okies
<Burgundavia> Pupeno, most things are synced from debian
<Burgundavia> Pupeno, I noticed that sid already has 0.9, so it will hit ubuntu breezy very soon
<Pupeno> Burgundavia: I know, but there were not sbcl 0.9.0 for hoary.
<Burgundavia> Pupeno, taking this to -motu
<Pupeno> oks.
<bob2> cdrecord should be able to burn cds on a dvd drive, right?
<cartman> daniels: https://bugzilla.ubuntu.com/show_bug.cgi?id=10942 sounds similar to my weird xkb issue
<cartman> actually its the same =)
<cartman> looking at comments
<Burgundavia> cartman, all breezy users are seeing it
<cartman> ok
<cartman> bah xorg failed :/
<Kamion> bob2: cdebootstrap doesn't support Ubuntu yet
<bob2> ah
<Kamion> use debootstrap
<bob2> I gathered that, I was just kinda surprised it had hard-coded suites at all
<bob2> yeah, I do, this was for dfsbuild
<Kamion> I don't think cdebootstrap is quite the answer to all everyone's ills that it's cracked up to be
<bob2> heh
<bob2> hah, debootstrap on ubuntu even loads the archive key into gpg
<jdub> yo Kamion 
<Kamion> bob2: right, it's on aj's list to merge to Debian ...
<Kamion> jdub: yo
<m0rphx> what happened with util-linux in breezy? dmesg, getty... are missing
<Kamion> yes, known bug
<m0rphx> k
<Kamion> I was actually just in the middle of looking through source packages for that, but got distracted ...
<cartman> m0rphx: don't reboot until it gets fixed
<Kamion> ... oh, I bet I know
<m0rphx> cartman: hehe, I already did. But thanks to the live CD I can boot again
<Kamion> yay dpkg
<cartman> m0rphx: oh ok :)
<Kamion> ifeq ($(DEB_HOST_GNU_SYSTEM),linux)
<Kamion> fixing
<cartman> Kamion: that will fix util-linux too? :)
<Kamion> I'm fixing util-linux
<cartman> yay =)
<jdub> SCHNNNNNAAAAAAKE!
<tseng> jdub: did you assign it to me? last i looked i cant search bugs
<tseng> jdub: until they "release" a new malone
<tseng> jdub: uh... yeah you are going to have to go back and assign it to me please, there is no other way to get to it
<tseng> oh its near the top
<tseng> and yes, we knew that
<tseng> i need dbus update before i can build muine with fixed dh_clideps
<Kamion> util-linux fix upload; will be available in an hour and a half or so
<xxenon> x.org broken in breezy ? (no "*fixed font" or something...)
<Kamion> font path changed
<xxenon> from what to what ?
<willis> xxenon: dpkg-reconfigure xserver-xorg
<willis> xxenon: then restart x and that might help
<xxenon> okay
<Kamion> xxenon: see the changelog
<xxenon> k.
<willis> Kamion: i meant to ask about util-linux, it seems to be missing /sbin/getty
<Kamion> willis: already fixed
<Kamion> 12:47 < Kamion> util-linux fix upload; will be available in an hour and a half or so
<willis> Kamion: cool thanks very much
<Kamion> that was 15 minutes ago
<Kamion> ... and s/upload/uploaded/
<hunger> Why was blockdev removed from util-linux?
<hunger> Was that fixed by Kamions recent upload of util-linux?
<Kamion> hunger: yes.
<hunger> Kamion: You rock!
<hunger> Kamion: thanks.
* hunger waits for the updated util-linux to become available.
* hunger can not mount his homedir without blockdev:-(
<Mithrandir> is it on purpose that util-linux no longer includes getty?
<bob2> 22:02:23         Kamion |  12:47 < Kamion> util-linux fix upload; will be available in an hour and a half or so
<Mithrandir> heh, ok
<bob2> more amusingly, it's scott's fault
<Mithrandir> how so?
<Mithrandir> it's the amazing dpkg?
<hunger> Kamion: Indeed, badblocks is back from the dead.
<Kamion> Mithrandir: DEB_HOST_GNU_SYSTEM changed
<GheRivero> res
<Mirv> does someone happen to know if moinmoin can be forced to reload wikiconfig.py? with ordinary user privileges..
<Mirv> or does someone even know what's the delay?
<trulux> pitti: ping
<pitti> hey trulux 
<trulux> pitti: checked that last krsec?
<trulux> pitti: I think that worked as expected, right?
<pitti> trulux: You told me to wait since you wanted to port it to 2.6.12
<pitti> trulux: you have a never version now?
<trulux> pitti: yup, porting
<trulux> pitti: just ended fixing akpm's patch-scripts and fixing a broken patches stack
<trulux> pitti: weird thing ;(
<pitti> Hi lamont
<trulux> pitti: will get it going on well after lunch
<trulux> pitti: are you going to be here for long?
<pitti> trulux: I have to go soon, prepare a party for tonight
<pitti> trulux: I will return tomorrow around noon, I'll be happy to build a new kernel then
<lamont> morning pitti
<trulux> pitti: OK, great anyways
<trulux> pitti: will upload my SELinux-enabled packages soon
<Riddell> Kamion: do you know why kdenetwork got into hoary-updates but knetworkconf hasn't
<robertj> are there any plans for Device Manager to manage devices in the breezy timeframe? If not, a name change might be good.
<lamont> elmo/Kamion: x11proto-* need some NEW love
<Kamion> Riddell: no.
<Kamion> Riddell: it's all buildd stuff from here; please stop asking me about it, I'm sorry but I don't know exactly what the buildds are configured to do and I don't have access to the relevant machines to find out.
<daniels> lamont: should've just been DMX
<Kamion> Riddell: it seems likely that it was in @no_auto_build (which affects all suites) and that the buildds will get to it in time.
<Riddell> Kamion: ok, sorry for the hassle
<Kamion> lamont: NEW's empty, I guess elmo did it
<Kamion> Riddell: np
<Xgates> hey all
<Xgates> quick compile question, the DEV team compiles with this flag -->  -march=i386 mcpu=i686?
<Xgates> since ubuntu lists the .debs as i386 I'd figure this then has to be correct, BUT for the life of me can't figure why anyone would use i386 anymore since this is very old and all distros are now going at least at i486
<Xgates> even Slack is i486
<daniels> we use -mcpu=pentium4
<daniels> as I explained in #ubuntu
<Xgates> you've GOT to be joking right?
<Xgates> please tell me so
<Xgates> you dont want to do that
<lamont> elmo/Kamion: xorg build-deps: x11proto-bigreqs-dev, x11proto-composite-dev, x11proto-damage-dev, x11proto-evie-dev, x11proto-fixes-dev, x11proto-dmx-dev
<lamont> but some of those are universe...
<daniels> they all need to be promoted to main
<Xgates> daniels: you must not be into multimedia or know anything about it then for CPU optimizations
<lamont> Xgates: note also that -march=i486 -mtune=pentium4 is the default in the compiler...
<Xgates> that is not good then
<daniels> Xgates: shit dude, I didn't do it, why are you laying into me?
<Xgates> mcpu=i686 is generic P4 is not
<lamont> Xgates: anything that does signifcant amounts of multimedia already does -march=pentium4 and -march=k7 and runs the right bits at runtime.
<Xgates> daniels: sorry I'm not hehe ;-)
* Xgates is happy
<lamont> Xgates: please show me an app that runs slow.
<daniels> if you want to put a clearly-reasoned argument, then do it on the mailing list, but wandering into IRC and laying into random developers at 0345 who have nothing to do with it is not the best idea
<lamont> Xgates: and be sure to include an actual use case.
<lamont> that is, an app that isn't _ALREADY_ compiling multiple versions and doing runtime detection
<Xgates> lamont: thats not the point P4 optimiztion as in running the compile flag -mcpu-pentium4 is not correct for overall general compiling for the masses
<lamont> Xgates: tell you what... compile the package both ways, and then tell me that you can determine which build you're running just by how fast it runs
<Xgates> ppl using i586 or in that ball park or even the possible slight few running a i486 will have problems not to mention this is just not correct for AMD
<daniels> Kamion: if there's some sort of main pre-seeding, then x11proto-{fonts,fontcache,gl,input,kb,panoramix,randr,record,resource,scrnsaver,trap,video,xcmisc,xext,xf86bigfont,xf86dga,xf86misc,xf86vidmode}-dev all need to go in
<Xgates> lamont: speed is not the issue it's the optimizations of that particular CPU
<Xgates> a P4 is not a AMD and vice versa and you should at least know that
<lamont> Xgates: yes. in certain corner cases, the instructions will be scheduled in a less than optimal way for certain hardware.
<daniels> Xgates: 'you should at least know that', 'you must not know anything about this' ... neither of these are good ways to make friends
<Xgates> lamont: dude plain and simple this is just not correct compiling Ubuntu needs to start compiling this as -mcpu=i686
<lamont> Xgates: there was talk back in warty of doing a separate K7 tree.  That was scrapped, pending someone showing anywhere that it actually made a visible difference to the user
<daniels> Xgates: your argument is terrible
<Xgates> that is a much better flag all the way across the board for i686 CPUS 
<daniels> Xgates: when I said make a well-reasoned argument, that means put some reasons behind it
<daniels> saying 'this is better, it must be done' is not a well-reasoned argument
<daniels> and saying that the other people obviously don't know anything about it is an even worse way to do things
<Xgates> daniels: not it is  not anyone with any compiling experience knows whats going on here and we would not even be talking about this
<lamont> Xgates: starting with _ANY_ application that shows a noticible difference in performance between -mtune=686 and -mtune=pentium4, on amd64 or p4
<daniels> Xgates: if you're going to keep arguing with that, then I will put you in +q
<Xgates> daniels: it's real simple and it does not even need to be technical you either know what a P4 is and a AMD is or someone does not
<Xgates> and it's clear that you dont then
<lamont> Xgates: ad hominum attacks don't count as well reasoned
<lamont> Xgates: sure we know the difference
<daniels> Xgates: at the moment, all you're doing is annoying a lot of people.
<lamont> and frankly, any real application either (1) does it at runtime, or (2) doesn't care.
<Xgates> sorry I'm not here to troll and bother you I just dont get the reason the DEV team would do something like this that would be a hinderance 
<Xgates> OH
<Xgates> and yes I can tell you that on my AMD T-bird
<Xgates> the slow down was in fact very bad
* mode/#ubuntu-devel [+o daniels]  by ChanServ
<lamont> Xgates: for what application?
* mode/#ubuntu-devel [+q *!*xgates@*]  by daniels
<daniels> bored now
<lamont> and running which kernel?
* mode/#ubuntu-devel [-o daniels]  by daniels
<lamont> ah, but it was just getting interesting
<daniels> if you want to actually put some reasons behind this (not 'it's right and if you don't agree you don't know anything'), do it on the mailing list
<lamont> Xgates: seriously - if there is a significant perf difference that the user can see, it'd be of interest.  It'd also be the first one we've seen in about a year, and > 1M CD's....
* lamont must really run to town now, since he's way late on some errands
<thesaltydog>  /msg thesaltydog IDENTIFY 140289
<thesaltydog>  /msg NickServ thesaltydog 140289
<ogra> hmm, thanks for your passwrod... you should remove the whitespace in the front
<zyga> ;-))
<thesaltydog> that's not my password :-)
<thesaltydog> thanks
<ogra> nope, i guess its your b-day
<zyga> it sure belongs to everyone now ;] 
<thesaltydog> ..
<unifi> how many developers work directly for ubuntu here?
<jnc> erg... advansys scsi module not building with kernel 2.6.12-2.6.11.92
<jnc> it's not in the menuconfig
<jnc> i wonder what happened
<thesaltydog> whcih is the policy to include an application into Rosetta, for localization?
<ogra> thesaltydog, did you ask in #launchpad ?
<thesaltydog> nope..
<thesaltydog> I will..
<thesaltydog> I have just put the question.. waiting for a reply..
<thesaltydog> ogra,  it seems that only ghosts are there
<ogra> hmm
<tuhl> after my latest update on breezy X is broken
<tuhl> on my IBM notebook and a workstation
<g14> tuhl: Read this channel topic :-)
<tuhl> gcc4 transition starting, breezy probably well broken?
<ogra> its a expected side effect, adjust your fontpaths or regenerate your config
<tuhl> ogra: how is the config regenerated?
<ogra> sudo dpkg-reconfigure -phigh xserver-xorg ? dunno, i didnt upgrade my breezy yet because i need my keymap and fonts ;)
<cartman> any news on how the transition is going? :/
<lu|away> hehe
<lu|away> yeah
<lu|away> someone needs to blog a daily 'breezy is *this* ____________ broken' update
<lu|away> :)
<cartman> just wondering I run breezy now and yeah its borked ;)
<robertj> Did 2004 bounty budget roll over into 2005?
* mako is installing his userlinux packages into a chroot...
<mako> dude, 2 extra gigs
<robertj> mako: why are you digging through userlinux stuff?
<mako> robertj: digging through, i've rewritten it :)
<ogra> yay amko
<ogra> mako
<robertj> but err, why?
<mako> robertj: i've made the userlinux metapackages installable on ubuntu
<ogra> because people might want to use them
<robertj> ahh for terminal server and the like?
<mako> yeah, anyone that is intersted in userlinux can now use them from ubuntu
<mako> i'm not sure they are going to be particularly useful really
<mako> i mean, i won't use them
<mako> but people seem to like userlinux
<mako> so, they will like these
<mako> it's also a nice thing we can do to fix their broken packages
<mako> and it's a good step toward debian-distribution merging
<mako> showing that we can all get along and even work together and share packages
<g14> mako: Whats so great about userlinux? Doesn't ubuntu do what Bruce wanted to do and then some?
<robertj> g14: shhh ;)
<mako> g14: um.. it does for me :)
<mako> g14: well, what userlinux has that we don't is a set of metapackages targetted at enterprises
<robertj> actually UserLinux has alot of other goals that Ubuntu isn't near ( a certification program ), but Ubuntu is certianly nearer meeting the UL goals than UL is
<mako> to make certain software configurations easily installable
<mako> and i've just ported that to ubuntu
<g14> mako: I understand, ubuntu will meet most of the UL goals before UL will though more than likely
<robertj> the #1 metapackage most people want is a LDAP/KRB/SMB/PAM package that takes care of all the fuss
<robertj> at least around our uni
<g14> SSO and a directory server, that would be really nice
<g14> If redhat would just hurry up and gpl the Netscape Directory Server they bought a year ago and said they would open source
<robertj> gl4: I use Panther for that at work, it's pretty good at it
<robertj> gl4: anyone who is large enough that slapd aint' gonna cut it probably doesn't need/benefit from a metapackage anyway
* g14 has no problems with but it not a mac guy
<robertj> gl4: its just slapd, kerberos, and samba with sensible configs and a few gui tools
<g14> robertj: OpenLDAP lacks many enterprise features that other directory servers feature. Yes, I've mucked around with ldap and kerberos
<robertj> its still not perfect, like it will hang without prompting you if you give it a password protected cert, and won't give you a prompt to enter in the password
<mako> hm.. liboil0.2 problems
<robertj> gl4: yes it does, but it works "well enough"
<g14> robertj: I agree, I've been trying to get hula email server set up with LDAP
<g14> hula is purty
<g14> http://www.hula-project.org/Hula_Server
<ogra> g14, did you use our hula package for that ?
<hunger> The new twm has --slave settings in wrong order and thus does not configure.
<g14> ogra: Actually, I do qa, I always use the latest svn and install it with checkinstall
<ogra> sad
<hunger> in update-alternatives in its postinstall.
<mako> ok.. liboil0.2
<ogra> i hoped i could hear some feedback from an actual user of the packages
<elmo> mako: is obsolete
<g14> ogra: The hula package in hoary universe is svn 162, they are currently up to rev 218. I would use it if it was updated every few weeks
<ogra> heh, we cant
<g14> ogra: But thats too much to ask of a busy ubuntu maintainer
<ogra> no, we have a policy about updates in stable releases, we simply cant update it
<g14> ogra: The novell guys I talk to say it will be "production ready" 1.0 somewhere around August
<ogra> thats great, then we can have nice packages in breezy based on the current ones...
<g14> I understand the stable packaging policy, its the debian mantra. Maybe hula 1.0 can be in breezy universe :)
<g14> yes
<mako> elmo: right.. and is not there
<elmo> mako: why's your meta package depending on it?
<mako> elmo: it's not.. other things are
<g14> ogra: I've been talking with the hula and openchange devs so sometime in the future, hula will feature native mapi / outlook integration
* ogra *shudders*
<tseng> ogra: shudder?
<elmo> mako: in breezy?
<tseng> ogra: be alot better than running exchange
<herve> hi folks
<mako> elmo: hoary
<ogra> tseng, thats true :)
<g14> ogra: outlook integration is what the suits want. 8 guys are writing openchange for a college thesis. No more exchange will beneift everyone
<herve> g14, no, not MS ;-)
<g14> herve: But honestly, who cares if MS doesn't benefit? It's not like they don't have a billion dollars or anything
<robertj> btw, Evolution on win32 is coming along
<elmo> mako: oh, err
<g14> robertj: Really?
<elmo> mako: my bad, fixed in next mirror pulse
<robertj> novell is throwing money at it
<robertj> Tor Lillqvist is on the case
<mako> elmo: ok.. is it fixed in archive.u.c now?
<g14> robertj: novell is throwing money at lots of great open source
<mako> elmo: what happened?
<elmo> mako: it got demoted in breezy, and I neglected to make hoary cope
<elmo> mako: no, next pulse, i.e. ~30 mins
<mako> elmo: awesome.. 
<herve> yo seb128
<seb128> lu
<jp_> breezy is rockin :D
<jp_> :)
<jp_> :P
<jp_> x is dead =)
<jp_> /etc/X11/X is not executable :_)
<jnc> excellent
<justdave> does anyone know if anything changed at all in the default UserAgent string provided by Ubuntu's Firefox when the fixes from Firefox 1.0.4 were backported?
<justdave> if anything changed at all, I could check for it to let Ubuntu people into addons.mozilla.org without having to hack their version number
#ubuntu-devel 2005-05-29
<justdave> I don't see anything that looks like it did, and due to the nature of the exploit it wouldn't be safe for me to just assume that anyone using Ubuntu has updated...
<elmo> justdave: I don't know off hand, but thom made the changes, easiest might be to mail him
<justdave> ok, thanks
<seb128> elmo: anything using gal2.2 and gtkhtml3.2 atm?
<robertj> seb128: do you know if 2004's bounty budget got rolled over into 2005?
<seb128> no idea
<robertj> am I out of the loop or have bounties been pretty quiet lately?
<seb128> robertj: I don't really knows about bounties, probably want to speak to jdub
<seb128> or mdz
<jdub> justdave: ping
<justdave> jdub: pong
<jdub> justdave: hey, you were asking about version number wrt addons.mozilla
<jdub> justdave: can't answer the question, but i did have the same problem
<jdub> justdave: do you ask because you hit it yourself, or because you've got feedback about it?
<justdave> because we got feedback about it
<jdub> cool :-)
<justdave> people are like "but I already upgraded, how come I still can't get in?"
<justdave> nobody bumped the version number so we have no way to tell from server-side
<justdave> hit http://www-stage.mozilla.org/products/firefox/upgrade/ using the Ubuntu version of Firefox
<justdave> I just added that message at the bottom if it has the Ubuntu useragent
<lu|away> but, like, you don't seriously expect to hand-code exceptions on the server every time someone backports bugfixes and releases a new version on a stable branch?
<justdave> no, I'd rather get the version number fixed in the package. :)
<justdave> Ubuntu seems to be the only distro (that I've heard anything about) that didn't update the version number when they pushed the security fixes.
<seb128> mandriva too I think
<mjg59> justdave: But it /is/ version 1.0.2
<mjg59> It's just a version of 1.0.2 that doesn't have the known security issues
<justdave> 1.0.x supposedly only gets security and stability fixes, so it's hard to imagine what would have got left out by backporting the patches aside from the version number :)
<mjg59> We don't backport stability fixes
<justdave> ah, so "secure but still crashes" :)
<mjg59> Stable releases get security fixes and nothing else (which means that some programs are broken, but they're broken in a consistent way...)
<wasabi_> *yawn*
<wasabi_> i've always been curious about that policy.
<mjg59> So bumping the version number isn't reasonable, because that would imply that it's something that it isn't
<wasabi_> Is it because of lack of manpower to insure backwards compatibility, or some higher philosophical reasoning like usual
<mjg59> It's hard to be certain that a bugfix does nothing other than fix the bug
<justdave> yeah, for the record, 1.0.3 did break stuff (which was fixed again in 1.0.4) as well as fixing the security issues
<wasabi_> I'm sure there are times.
<mjg59> With security fixes, we have no choice - it's better to break the software than to leave it insecure
<wasabi_> But I see the point. It is a man power issue.
<seb128> no
<wasabi_> If you had enough man power to throw at "making sure", such as any commercial vendor does.
<justdave> but in 1.0.3's case, it was the security patch itself that broke things
<mjg59> wasabi_: Microsoft consistently break stuff with Windows service packs
<mjg59> It's not a manpower thing. It's a *hard problem*
<wasabi_> Frankly it's not as bad as you make it out to be.
<wasabi_> I'd rather have a crash fixed.
<justdave> and if the "fix the problem we created in 1.0.3" patch (which wouldn't have been labelled as security) wasn't backported in addition to the 1.0.4 security patches, then you have a crashy browser
<wasabi_> <--- win admin. =/
<mjg59> justdave: Right, so specific cases are obviously more awkward than the general one :)
<mjg59> justdave: But it would be good to be able to signify that a vendor release has been patched without making life awkward for upstream
<justdave> looks like it's actually claiming to be 1.0
<justdave> Firefox/1.0 (Ubuntu package 1.0.2)
<justdave> that's what it says in the UserAgent
* wasabi_ doesn't get it.
<justdave> you could tack the package revision on the end of the one inside the Ubuntu package section
<justdave> (Ubuntu package 1.0.2-0ubuntu5)
<wasabi_> wait are we talking about a stupid user agent check on a web site?
<justdave> yes.
<wasabi_> make the web site fix itself.
<justdave> it's a stupid way to check versions, but it's the only way to do it without sending content from the site.
<justdave> it's a security issue.
<justdave> the site is whitelisted by default for extension installs.
<justdave> if you can load it in an iframe, it can be exploited.
<wasabi_> sounds like a pretty crappy security system. ;)
<justdave> so if your UserAgent says you're running a vulnerable version, you get redirected to another domain that's not in the default whitelist.
<justdave> (which short-circuits the exploits)
<wasabi_> i don't get it.
<wasabi_> sounds like extensions should be signed.
<justdave> yeah, they're working on that.
<justdave> it'll probably work that way in 1.1
<wasabi_> Cool. =)
<CarlFK> I 'think' I am onto a bug in Hoary's network config stuff - OK if I ask for some help here if I promice to bugzil,la it if it is?
<CarlFK> not to mention my GF is gonig to be pissed if I can't get this fixed before she leaves for school with the box
<CarlFK> i think i am hitting https://bugzilla.ubuntu.com/show_bug.cgi?id=8921
<CarlFK> im off to take a shower...
<ogra> hmm, the acer 1520 has no IPW2200 (intel), it has a IPN 2220 (cisco, no linux driver yet) i wonder what the guy is doing there
<amu> bite in the notebook?
<ogra> heh
<amu> punishment enough, if you must work with a acer 
<ogra> agreed... thats my last acer :)
<daniels> Kamion: so what do I need to do to arrange an xorg upload to hoary-updates?
<lamont_r> log files are now .gz files
<jp_> cool
<jp_> =)
<jp_> <-!
<lamont_r> getting elmo to add the content type is left as an exercise for the europe croud
<lamont_r> crowd, even
<ogra> hmm... so my script wont work anymore...
<lamont_r> :-(
<lamont_r> just make it understand both extensions...
<lamont_r> right then.  homeward bound
<wasabi> i must have been one of the only people who used to like Debian's iptables init script
<crimsun> I used it, too
<Lathiat> yeh so did i
<Lathiat> its not that bad really, i didnt se ethe issue with it.
<wasabi> it was stupid simple, which is why I liked it
<Lathiat> i just recreated it. :)
<ogra> lamont, fixed :)
<lamont> ogra: coolness.  Is this something that could drop onto people easily?>
<lamont> hrm.. might be security-policy issues with that though...
<ogra> i guess so... but still, big files will load slowly...so there should be a extra download button...
<ogra> i'll talk to pitti about it
<ogra> hwdb.ubuntu.com runs a similar script which was ok for pitti after some small changes
<tseng> ogra, up late
<ogra> yeah.... my GF os moaning she wants to go to bed...
<ogra> i think i'll do my last dogwalk now, night all
<tseng> bye ogra 
<LinuxJones> bye
<jnc> ogra: "my GF os ..."
<ogra> is
<ogra> :)
<jnc> now now.... ubuntu is nice, must you really make it your girlfriend
<jnc> :-P
<jnc> *kidding*
<ogra> heh
<bluefoxicy> Bus 005 Device 006: ID 05e3:0710 Genesys Logic, Inc.
<bluefoxicy> this is a USB mass storage device.
<bluefoxicy> it's supposed to work in Linux
<bluefoxicy> oh, it is now, wow.
* bluefoxicy unplugged it and replugged it and switched to a pen drive repetedly and nothing o_x
<bluefoxicy> UH.
<bluefoxicy> "since gparted can be a weapon of mass destruction only root can run it
<bluefoxicy> can't I take caps away and drop to nonroot, then exec gparted?  o_o  (in lieu of just rewriting thec ode)
<Lathiat> I've entirely got to stop upgrading breezy/xorg
<Lathiat> daniels: /etc/X11/X -> [broken] /usr/bin/X11/Xorg
* crimsun pats his breezy pbuilder
<Lathiat> heh
<Lathiat> i think i should reinstall and go back to hoary
<jdub> Lathiat: dude, just don't log out or reboot :-)
<Lathiat> jdub: heh
* jdub hasn't for days
<jdub> on laptop or desktop :)
<Lathiat> it was finely bumpy until the X stuff. :)
<Lathiat> jdub: see my suspend is farked
<jdub> suspend? SUSPEND?
<jdub> you build your house on a bed of sand!
<jdub> any norwegian speakers in the house?
<jdub> Mithrandir: around?
<jdub> ha ha
<jdub> http://linuxman.blogsome.com/images/ganador_ubuntu.jpg
<dilinger> ubunticola!
<fabbione> morning
<crimsun> morning
<Lathiat> e
<lu|sleep> ubunticos!
<lu|sleep> (misuse, but whatever)
<lu|sleep> (night)
<Treenaks> how do I compile a debug version of a CDBS package?
<crimsun> you want to pass nostrip to DEB_BUILD_OPTIONS
<Treenaks> ok
* Treenaks has a nasty segfault in hald
* netjoined: irc.freenode.net -> orwell.freenode.net
(Treenaks/#ubuntu-devel) uh, wb all?
<Treenaks> wow.. what happened?
<KaiL> NetSplit
<KaiL> oh ;)
<KaiL> -
<crimsun> network server upgrades
* bod pokes Kamion 
<toresbe> Mirv: Ping?
<toresbe> tja: pin
<toresbe> g
<tja> yes?
<toresbe> tja: Can I msg you? It's a bit OT :)
<tja> hit it
<hunger> Hi! Anyone got X working again after yesterdays upgrade?
<hunger> xprint does no longer work (wrong font path), xdm does not work (wrong path to binary in init-script).
<hunger>  /etc/X11/X points to a non-existing directory
<bob2> yes, welcome to the development branch!
<bob2> the fix is in the bts
<\sh> deja vu
<\sh> but for me it's Xlib.h ;)
<\sh> and I'm not complaining...
<hunger> bob2: Good:-)
<hunger> \sh: I am not complaining either?
<\sh> hunger: adjust the font paths...
<hunger> \sh I just wanted to point out the problems I am seeing while I am not able to get into the bugtracker to report them.
<hunger> \sh: Did that already.
<hunger> \sh xprint has some settings different from those in /etc/X11/xorg.conf
<\sh> normally Xlib.h should be in /usr/include/X11/ and not anymore in /usr/X11R6/include/X11 
<\sh> think i need some coffee to get this confusion out of my brain
<hunger_> What is the purpose of this X-reorganization anyway?
<hunger_> Making room for /usr/X11R7 ?
<\sh> i think just because we have now two free implementations of X11..xfree86 and xorg
<tja> hunger: no, getting rid of /usr/X11* altogether
<bob2> except no one uses XFree86 anymore
<hunger> \sh: There is no xorg in the path...
<hunger> tja: The amount of stuff in /usr/X11R6 has not changed so far.
<hunger> tja: It is only that /usr/bin/X11 etc. went missing.
<tja> stuff is being migrated bit by bit
<\sh> morning pitti
<pitti> Hi folks
<\sh> but something went mad after the update this morning
<Mithrandir> jdub: pong
<hunger> Hi pitti.
<pitti> trulux: here?
<Treenaks> pitti: hi
* Treenaks points everyone at #11060
* hunger_ is of to write bugreports about his recent trouble with X.
<ajmitch> hi pitti 
<xe||> hi
<xe||> thanks very much for fixing kopete that fast, ubuntu rocks!
<daniels> Lathiat: uhm, /usr/bin/X11 is still a directory on my ... oh shit
<daniels> Lathiat: good catch, thanks
<daniels> thom: so, I think the way to reproduce my firefox crash is, start with about 10-15 tabs, then open something like www.theage.com.au and news.bbc.co.uk, and just open a bajillion links in new tabs
<daniels> thom: that seems to screw it up prett reliably
<daniels> hunger_: what sort of trouble?  is it related to fonts or keyboard?
<hunger_> daniels: No, more to x not starting at all due to broken pathes all over the place
<daniels> that's well-known
<daniels> we're in the middle of a huge path transition for xorg
<hunger_> daniels: I know.
<hunger_> daniels: But when you break my system you will get bugreports. Just so things will not get forgotten.
<hunger_> daniels: And even in unstable X should work IMHO, independent of ongoing changes. You are giving out the packages to get feedback, aren't you?
<daniels> hunger_: trust me, it's not been forgotten
<daniels> and no, breezy isn't necessarily supposed to always be usable
<hunger_> daniels: Good:-)
<tepsipakki> people are spoiled by sid
<daniels> it's just that I don't have the resources to fix it right now
<daniels> if you're not comfortable fixing breakages like this, right now you shouldn't be using breezy
<hunger_> daniels: It is not supposed to be useable or it may become broken at anytime?
<hunger_> daniels: I am comfortable fixing the fallout. I am running X again.
<hunger_> daniels: I do not mind running a distri that may break at any point in time. If the distri is meant to be broken, then I may need to look around for something else though.
<mjg59> hunger_: We have a nice stable distribution called "hoary"
<mjg59> Breezy is under active development. The priority is to ensure that stuff will work at release time, not to ensure that it works at any intermediate point
<mjg59> Prioritisation means that something may remain broken for some time
<hunger_> mjg59: Yeah... but I am an apt-addict;-)
<hunger_> mjg59: That is fine for me!
<mjg59> So, currently, X is broken because other things need to be worked on and have a higher priority
<hunger_> mjg59: I will write bugreports and fix stuff for myself.
<hunger_> mjg59: I am not complaining (sorry if that is what I sound like), I was just reporting my findings in case they were not yet known.
<hunger_> mjg59: OK, I doubt that "x does no longer start" was not noticed before;-)
<mjg59> hunger: Heh. Sure, that's no problem.
<hunger> tepsipakki: I have used other unstable distris apart from sid... which indeed does spoil people.
<tepsipakki> hunger: the other distros or sid?
<hunger> tepsipakki: sid spoiled me.
<tepsipakki> me too
<tepsipakki> breezy is better ;)
<tepsipakki> keeps you on your toes
<daniels> it's more fun
<tepsipakki> right on
<tseng> "what is daniels going to break today?"
<tseng> its always a suprise
<hunger> tepsipakki: If you want broken unstables... try gentoo.
<tepsipakki> nooo, never
<hunger> tepsipakki: with having to build the broken stuff for yourself all the time that distri is really painful.
<tepsipakki> heh
<tepsipakki> i bet
<hunger> tepsipakki: feels a bit like digging your own grave...
<tepsipakki> "I'm off hunting... my own foot!"
* hunger wishes that not everything that gets installed will automatically have its init scripts run at bootup.
<hunger> But well, that is probably just me again...
<tseng> if you install a service intentionally, theres a good chance you want to run it
<tseng> if not, you can update-rc.d
<tseng> optimize for the common case dudes
<hunger> tseng: As I said: probably just me again:-)
<hunger> tseng: I install lots of stuff that I need in this or that network but not the others.
<tseng> oh
<tseng> you need NetworkMagic
<tseng> with more *MAGIC*
<hunger> tseng: Just trimmed down the rc-dirs by 15 entries that are not needed everywhere.
<tseng> http://tseng.ath.cx/galleries/udu/mq/img-23.jpg
* hunger keeps forgetting to remove the links right after startup:-)
<tseng> on idea for network magic is to be able to start/stop services
<tseng> depending on the connection
<hunger> tseng: Should work... the normal debian scripts can do that!
<tseng> I mean.. magically
* hunger wonders why those are not used in ubuntu.
<hunger> tseng: I have my wlan configured based on available APs with the normal /etc/network/interfaces mechanismns.
<hunger> tseng: For some reason they are ignored in ubuntu afaict.
<tseng> eh if you know what you are talking about, it sounds like bug report material
<tseng> i dont use debian.
<hunger> tseng: I put the necessary stuff on the wiki.
<tseng> http://tseng.ath.cx/photos/index.php?galerie=udu&snimek=31&exif_style=&show_thumbs=
<tseng> this is why your X is broken
<hunger> tseng: Because of STRANGE people grinning into the camera? ;-)
<tseng> one strange scruffy person
<daniels> hey, I'm not scruffy
<hunger> tseng: So basically you all sat together and decided to break my computer? ;-)
<daniels> nor am I grinning
<Mithrandir> hunger: yes.  We call it development.
<Mithrandir> :)
<daniels> Mithrandir: 'progress'
<Mithrandir> daniels: that too.
<bob2> hey, you didn't use to be scruffy
<hunger> Mithrandir: Good answer;-)
<bob2> but after ols...
<daniels> bob2: ... my hair was very close-cropped
<hunger> tseng: Do you have some pics of the board, etc.?
<tseng> hunger: which board?
<bob2> daniels: I'm not talking hair
<daniels> bob2: i had my beard before OLS
<bob2> hm, ok
<bob2> I'll blame palais, then
<daniels> bob2: i've had it since about last January
<hunger> tseng: the whiteboard.
<bob2> it seems to encourage dodgy beards
<tseng> hunger: yes its the next shot or the one after for network magic
<daniels> since before I'd visited the palais :P
<tseng> hunger: you can get a full page of thumb nails
<hunger> tseng: Yes, found a couple already.
<daniels> bob2: http://people.freedesktop.org/~daniels/albums/syd-jul2004/aan.sized.jpg
<hunger> Is there a reason for not running ntpdate via /etc/network/if-up.d instead of in rcS.d?
<Mithrandir> hunger: it'll all be fairly redone for breezy.
<Mithrandir> look at the UdevRaces spec
<daniels> bob2: (and my hackergotchi was from april-ish last year)
<bob2> daniels: oh yeah, I was at the giant phallus pizza party
<hunger> Mithrandir: Basically all network services could be started via if-up.d/if-down.d...
<daniels> bob2: abh in that gallery is le amore pascal
<bob2> ahhhh, good times
<bob2> daniels: cabal.!
<Kamion> daniels: hoary-updates> upload, send me/mdz the diff for approval
<daniels> Kamion: 'kay
<daniels> Kamion: will email the diff, but it's not the most complex: http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c?r1=1.15&r2=1.16
<Kamion> a rationale for the X-illiterate among us would be nice, too. :)
<elmo> actually, if you could get the upload approved _before_ uploading it, that'd make my life easier
<Kamion> oh, ok
<daniels> Kamion: ok, so it reads the clocks out of DDC to validate modes against
<Kamion> didn't know it made a significant difference, barring queue/accepted/ noise
<daniels> Kamion: but the initialiser for DDCClock is in the wrong place, so you basically end up with 640x480 on Intel desktop chipsets.  it's #7878.
<elmo> Kamion: queue/accepted isn't designed to have stuff removed out from under it; the current hoary-updates mechanism is a gross hack done through necessity
<Kamion> daniels: [reads references]  ok, that's fine by me, go ahead and upload
<daniels> Kamion: cheers
<tuhl> any hints when X will work again in breezy?
<fabbione> tuhl: uh? never.. we are going back to framebuffer console...
<fabbione> ;)
<pitti> fabbione: ++
<fabbione> pitti: ehheh
<tuhl> fabbione: :-)
<pitti> that's part of GettingRidOfTheDesktop
<fabbione> ahaha
* bob2 Seconds
<bod> Kamion: awake?
<ajmitch> pitti: so how does that go along with CommandLineDisintegration? :)
<Kamion> bod: yep
<pitti> ajmitch: DirectBrain(tm) connection only
<ajmitch> sounds nice & secure 
<pitti> ajmitch: yeah, solves all authentication problems :)
<fabbione> and if you get brainr00t3d?
<fabbione> are you going to end up like Mr Bean?
<pitti> no regression, the attacker can get your passwords out of your brain, too :-)
<bob2> hahaha
<bob2> glad pitti's in charge of security ;p
<Kamion> elmo: could you sync perl 5.8.6-1 from experimental, please? (it's only there due to Debian freeze policies)
<fabbione> Kamion ++ for extra crack :)
<Burgundavia> when is breezy UVF?
<fabbione> hey _infinity 
<pitti> Hi _infinity 
<pitti> short visit...
<Kamion> elmo: libdb1-compat seems to have been incorrectly demoted to universe in warty and hoary
<Kamion> Burgundavia: http://udu.wiki.ubuntu.com/ReleaseCycle
<Kamion> release - 14 weeks
<Burgundavia> Kamion, thanks, couldn't find it
<elmo> Kamion: eh? there are symlinks for it
<Kamion> elmo: oh, ok. somebody was complaining about debootstrap failing on libdb1-compat
<Kamion> are the symlinks recent?
<elmo> May 21 22:23
<Kamion> ah
<Kamion> ok, thanks
<seb128> elmo: is anything using gal2.2/gtkhtml3.2 ?
<jdub> morning seb128 
<seb128> hey jdub 
<jdub> having a nice, relaxing sunday morning? :)
<jdub> we had a eurovision party tonight
<seb128> I slept until 11am, so yes :)
<jdub> the french act was merde :)
<seb128> roh
<jdub> don't worry, the UK act was complete bollocks ;)
<seb128> I watched the local soccer team winning 3-2 yesterday, much better than the crappy eurovision :p
<Burgundavia> not surprisingly (haven never seen it), the pretty girl won
<elmo> seb128: not gal2.2, I demoted that a while ago
<elmo> and gtkhtml3.2's in universe too
<seb128> ie: is that ok to drop them?
<seb128> I've asked some time ago and abiword was still using that IIRC
<elmo> Checking reverse dependencies...
<elmo> No dependency problem found.
<seb128> k, please drop them so
<seb128> thanks
<elmo> removed
<lifeless> elmo: ping
<trulux> heya folks
<trulux> mdz: ping
<Kamion> mdz's on vacation
<trulux> Kamion: lucky man
<trulux> :)
<\sh> guys i have a little problem
<\sh> arkrpg doesn't want to compile with the actual settings in the source...so I removed config.sub and config.guess from the actual source and rerun aclocal/automake-1.7 ; autoconf now it would compile the right way..but what is the best way to get diffs for it now?
<Mithrandir> if the problem is just config.sub/guess, just update those from /usr/share/misc
<\sh> Mithrandir: done...but i need to provide some patches for cdbs simple-patchsys
<\sh> and the patches already in the patches dir must be applied before that
<\sh> or should i do the replacement in debian/rules?
<Mithrandir> add a patch which updates config.sub/guess simply?
<\sh> Mithrandir: i have to rerun aclocal and automake with 1.7
<\sh> i could do an aclocal etc. in the rules file, but this is not nice
<bob2> \sh: run it yourself before the .diff.gz is generated, and it will get included in there
<bob2> then you have an ugly diff but a working program
<bob2> then you beat upstream until they update
<\sh> bob2: no...I'm doing it another way...using clean tar.gz and work the changes in and diff it and put those patches to debian-sourcedir
<bob2> ok, same deal
<bob2> the last step is the same, anyway ;p
<zul> hey
<Nafallo> hi all!
<zyga> hello
<zyga> is anybody else under the impression that firefox crashes like crazy lately?
<ogra> zyga, only on amd64
<zyga> ogra: I'm running amd64
<zul> hmmm...planet.gnome.org change the layout
<zyga> ogra: why amd64? some library is messed up?
<ogra> zyga, no idea...
<ogra> zyga, but i switched back to mozilla-firefox for now....
<ogra> (on amd64 at least, on the other arches it works fine)
<zyga> ogra: I'll wait as usual
<zyga> ogra: besides I'm too scared of updates ATM
<eruin> any rosetta people here?
<Kamion> #launchpad
<eruin> cheers
<Kamion> (if they're not there, they probably won't be here :-))
<AndyR> afternoon all
<pitti> trulux: here?
<trulux> pitti: yup
<pitti> cool, how are you?
<pitti> trulux: any news?
<trulux> pitti: fine, well, tired but good at least. yep, some
<trulux> I'm about to upload some packages
<trulux> pitti: and I'm porting krsec to 2.6.12-rc4
<trulux> pitti: pretty straight forward
<trulux> pitti: BTW, I will send the spec today
<pitti> yeah, no big deal, but it is easier if I don't have to do it over and over again
<trulux> pitti: we can't wait more for it
<trulux> pitti: done
<mdke> hi pitti 
<pitti> hi mdke 
<mdke> did you get anywhere with update.mozilla.org?
<trulux> pitti: the patch is updated in pearls.tux...
<pitti> mdke: no, I didn't deal with that so far
<trulux> pitti: next, how do you want to deal with the packages?
<mdke> pitti, i wondered if it would be worthwhile opening a bug, so people can track the problem
<pitti> trulux: do you have the full URL? I'm on my laptop ATM and don't have my desktop history
<pitti> trulux: "the packages" == SELinux packages?
<trulux> pitti: http://pearls.tuxedo-es.org/patches/security/kern-security-1.patch
<trulux> pitti: right
<pitti> trulux: dpkg should be done by Keybuk, all other packages are fine for me to upload
<pitti> trulux: we need to ask mdz tomorrow
<pitti> trulux: is ajmitch fine with them?
<pitti> trulux: patch looks fine
* pitti kicks another kernel build 
<trulux> pitti: thanks
<trulux> pitti: one sec, door knocking
<mdke> pitti, ah np there is a bug already
<mdke> https://bugzilla.ubuntu.com/show_bug.cgi?id=10986
<KaiL> that guy didn't test 1.0.4? ;)
<pitti> hm?
<KaiL> I got some VERY bad comments about Firefox 1.0.4, seams to be unable to install some extensions
<mdke> KaiL, that guy is running hoary
<KaiL> jup
<trulux> pitti: back
<pitti> trulux: there is a typo
<pitti> +#ifndef CCONFIG_KERN_SECURITY_BOOT_PARAM_VALUE
<pitti> +#define CONFIG_KERN_SECURITY_BOOT_PARAM_VALUE 1
<pitti> trulux: mind the "CCONFIG"
<trulux> pitti: argh
<trulux> pitti: yup
<pitti> trulux: no worries, I corrected it
<pitti> trulux: kernel is building
<pitti> Hi ska-fan 
<trulux> pitti: fixed version uplaoded
<pitti> typo day? :-)
<ska-fan> pitti: hi
<trulux> pitti: I'm not drunk. I promise.
<trulux> pitti: ;P
<pitti> hehe
<robertj> "You've been out all night not drinking again!"
<trulux> pitti: there?
<pitti> trulux: barely...
<trulux> pitti: who was that python, pygtk / gnome hacker that you told me I could ask for help/work together?
<pitti> trulux: just ask at u-devel ML
<trulux> OK, thanks
<trulux> pitti: I will send you an email when the packages get uplaoded and the like
<trulux> pitti: will upload the spec. too, is that OK?
<pitti> sure, thanks
<mxpxpod> how would I just build the powerpc kernel packages w/o building power3/power4 using dpkg-buildpackage?
<mxpxpod> fabbione: ping
<crimsun> mxpxpod: just delete all the configs except for powerpc
<mxpxpod> crimsun: ah, cool
<mxpxpod> crimsun: in the debian/config/powerpc dir, right?
<crimsun> yes
<mxpxpod> thanks
<crimsun> np
<GheRivero> res
#ubuntu-devel 2006-05-22
<LaserJock> does anybody know how the spec process will work for Edgy? How do we know what is an edgy spec or a dapper spec or does it matter?
<Burgwork> LaserJock, just create specs for ubuntu
<Burgwork> they will be looked at and retargeted as needed
<LaserJock> Burgwork: by the Ubuntu (slave) drivers? :-)
<Burgwork> yep
<sladen> keybuk: is udev compatible with ifplugd
<mjg59_> sladen: No, it replaces it
<wasabi__> There a methodology by which base packages are marked? ie needed to be bootstrapped on a new arch?
<wasabi__> ubuntu-minimal has stuff like xfsprogs, which clearly doesn't.
<tseng> i think the maintainer of the packages just know
<wasabi__> Hmm. Maybe I should tear into debootstrap and see what it uses.
<tseng> mono wasnt marked when we had to manually bootstrap it
<wasabi__> I mean distro packages.
<tseng> i dont see what the difference is
<wasabi__> required for boot.
<holycow> hey guys, anyone know if open office has logging capabilities?
<WildTangent> Not sure if anyone is aware yet, but the latest updates seem to break the icon beside the applications menu for any icon theme other than Human, Tangerine and Tango
<wasabi__> Heh. Looks like debootstrap has some hard coded items.
<WildTangent> instead of the normal Ubuntu logo, i see the standard gnome foot logo
<holycow> WildTangent, true i just noticed that too
<holycow> i preffer the foot logo my self but for ubuntu it should be the logo *nod*
<WildTangent> the gnome foot annoys me :)
<wasabi__> Ahh. Priority: important
<WildTangent> coz_ here has the same problem as I do
<coz_> well the recent dapper updates, as of 15 minutes ago, have replaced the distributor-logo next to applications with the gnome foot. I don't hink so. How can this be changed systemically
<LaserJock> wasabi__: probably Required+Important
<coz_> I found that even in my own icon set the logo has been replaced 
<WildTangent> coz_ there is no distributor-logo.png anymore besides the ones that come with the Ubuntu-made themes
<coz_> WildTangent, it iwas in hicolor and is now gone
<coz_> hmm need to solve this
<WildTangent> indeed
<WildTangent> this is quite upsetting
<LaserJock> have you guys looked at the dapper-changes to see what the changelog says
<LaserJock> WildTangent: I doubt there is a need to be upset :-)
<WildTangent> perhaps Ubuntu is trying to make each theme decide its own logo...but the problem is, it doesn't seem that the theme-makers have quite caught onto this ;)
<coz_> LaserJock, no I haven't looked and I don't hink anyone is upset just taken back by the inappropriate change
<WildTangent> ya...and there doesn't seem to be a way for us mere mortals to fix it ;)
<WildTangent> I've tried many things, nothing has worked
<coz_> I am sure whoever is capable of changing this will do so soon I have great confidence in you guys look forward to the change back to the ubuntu logo for the gnome menus
<WildTangent> where is the changelog?
<WildTangent> i cannot find it
<LaserJock> somewhere in https://lists.ubuntu.com/archives/dapper-changes/
<Burgwork> WildTangent, file a bug against the tangerine icon theme
<WildTangent> Burgwork: how are you sure that Tangerine is the problem? I've already stated that the icons in Human, Tangerine, and Tango all work, its the icons in 3rd party themes included with Gnome, and downloaded from places like gnome-looks.org that dont display the correct logo
<WildTangent> they worked before the update, but now they dont
<LaserJock> WildTangent: look at what packages were updated
<WildTangent> I am trying, but your changelog is hard to navigate
<LaserJock> WildTangent: https://lists.ubuntu.com/archives/dapper-changes/2006-May/date.html
<Burgwork> WildTangent, then the issue is not an Ubuntu one
<LaserJock> and if you used aptitude or synaptic look at the history
<WildTangent> Burgwork: it is obviously an Ubuntu issue...this problem did not surface until immediately after the updates
<WildTangent> others have confirmed this
<WildTangent> they have the exact same problem as I do
<LaserJock> but the question might be if it was an upstream thing or whether it was an accident, etc.
<WildTangent> tangerine-icon-theme (0.12-0ubuntu1) to 0.13-0ubuntu1, tango-icon-theme (0.7.2-0ubuntu2) to 0.7.2-0ubuntu3, tango-icon-theme-common (0.1-0ubuntu1) to 0.2-0ubuntu1, ubuntu-artwork (18) to 20
<WildTangent> those are the theme updates today
<WildTangent> all ubuntu packages
<LaserJock> ok, so then you can find them on https://lists.ubuntu.com/archives/dapper-changes/2006-May/date.html and look at the changelog
<WildTangent> latest i can find for tango was may 11
<Burgwork> WildTangent, tomorrow, as dholbach about it. He does all the icon stuff
<LaserJock> WildTangent: ok, https://lists.ubuntu.com/archives/dapper-changes/2006-May/010964.html and https://lists.ubuntu.com/archives/dapper-changes/2006-May/010976.html
<WildTangent> thankyou
<WildTangent> nothing looks suspect in there...maybe this was an unintentional mistake
<WildTangent> in either case, it needs to be fixed :)
<LaserJock> WildTangent: so go file a bug :-)
<WildTangent> I shall
<olafura> I'm just wondering why libvisual plugins aren't appart of the gstreamer0.10-plugins-base in dapper?
<Burgwork> olafura, you need to talk to slomo__ 
<Burgwork> olafura, I would also check launchpad for any bugs
<robertj_> is it just me or do the new java distribution terms for distros look very _ugly_
<robertj_> especially  - Ship only a compatible JDK on your OS
<wasabi__> Very few packages have pure binary-indep support that's optimized eh
<ajmitch> morning
<BlueT_at_Mars> morning :)
<CarlFK> Kamion: install kernel append .... preseed/url=http://foo/bar - that creates a var preseed/url - how can I wget that?  (the / screws up $preseed/url)
<joelbryan> hello, anyone know why pessulus isn't included in dapper?
<Burgundavia> joelbryan, it is part of the admin stuff, and thus is not shipped by default
<Burgundavia> joelbryan, it is a great tool, but not one that everybody needs
<joelbryan> ah
<joelbryan> it's a great app
<joelbryan> Burgundavia: I thought the reason was it has a epiphany tab by default, which really easy to fix
<Burgundavia> nope
<wasabi__> libc failed on arm. =(
<wasabi__> that was quick.
<bddebian> Howdy
<jsgotangco> good morning
<bddebian> Heya jsgotangco
* wasabi__ beats distcc
<bddebian> Anyone know aobut the libmysqlclient update?
<desrt> big bad dapper bug!!!
<desrt> if multiple users are logged in when you plugin a usb storage device then the 'wrong one' mounts it and gains sole permission to it
<desrt> my sister tried to load up her mp3 player with my other sister logged in in the background
<KaiL> I guess, the one logged in first gets it?
<desrt> actually, it's a crapshoot
<desrt> but the one logged in first seems to have a statistical advantage
<KaiL> the tools in the background (same problem for sound!) doesn't get any information, that a session is locked/disabled...
<KaiL> that's not a normal bug, that's just missing design...
<desrt> ya
<desrt> seriously
<Burgundavia> desrt, I wonder if this is a pam_foreground bug
<desrt> such a thing exists?
<Burgundavia> such a total shot int eh dark
<desrt> the best thing i can think of is for g-v-m to check /var/run/console to make sure that the current vt belongs to the logged-in user
<Burgundavia> desrt, talk to mjg59_ as this is a solved issue
<desrt> not really
<desrt> mjg59 solved it for power management via dbus
<desrt> mounting of hotplugged storage occurs by execing pmount (setuid), not over dbus
<Burgundavia> does lib_pamforeground not solve the "whose is currently in control of this computer" issue?
<desrt> this isn't really a pam thing, though
<desrt> unless the change it made to pmount....
<desrt> Burgundavia; sorry.  you were right.
<desrt> Burgundavia; there is definitely code in place to deal with this
<desrt> Burgundavia; for some reason it does not work
<Burgundavia> desrt, see, my totally non-technical knowledge pays off
<desrt> ahah
<desrt> the effected computer is probably running the old version
<desrt> the fix went in just a few days ago
<desrt> thank god.. i can now go to sleep at a reasonable hour tonight :)
<desrt> ew.
<desrt> *affected
<desrt> anyway.  thanks.  goodnight.
<wasabi_> There we go.
<wasabi_> Compiling Ubuntu on Debian/ARM in qemu using distcc with a cross compiling toolchain to my fast machine.
<wasabi_> http://news.com.com/Sun+flirts+with+Ubuntu/2100-7344_3-6073104.html?tag=nefd.top
<wasabi_> Now that's interesting.
<jsgotangco> yeah
<desrt> maybe sun could be friendly back and license their jvm so that ubuntu was actually able to ship it
<desrt> it'll be cute when sun is shipping an OS on their servers that is not legally able to include sun's own platform
<wasabi_> They have.
<wasabi_> apt-get install sun-j2sdk or something
<wasabi_> it's there right now.
<desrt> in universe, multiverse?
<wasabi_> good question
<wasabi_> multiverse
<wasabi_> But it is finally packaged properly.
<desrt> that's nice
<wasabi_> I'm a bit disappointed actually.
<wasabi_> I really like GCJ/kaffe. ;)
<desrt> gcj is quite elite.
<desrt> gcj is officially what makes java better than c#
<wasabi_> Heh. WHy do you say that?
<desrt> native code
<wasabi_> C# has the same.
<desrt> no need for a runtime environment
<wasabi_> Done in pretty much the same way.
<wasabi_> gcj still has a runtime environment.
<wasabi_> In fact, for EJB, and servlets, it's pretty much neccassary.
<desrt> well, you need a GC, etc...
<desrt> but i mean no virtual machine
<desrt> it has a runtime in the sense that ghc-compiled executables do
<wasabi_> Well... Dunno what you mean by no virtual machine. It's a very fine line.
<wasabi_> GCJ needs to be able to compile java code and bytecode on the fly.
<wasabi_> To compile servlets and applets on the fly.
<wasabi_> And runtime bytecode generation.
<wasabi_> At the end of the day, they're all just generating bits of machine language and linking them together on the fly.
<wasabi_> Or reading pre-built bits off the disk.
<wasabi_> C# has a precompilation thing. Basically just plugs in and circumvents the JIT.
<desrt> anyway.  time for bed.
<desrt> see you.
<jsgotangco> glatzor: ping
<glatzor> hi jsgotangco!
<jsgotangco> glatzor: hey, i don't think we can do so much for the u-m guide now
<jsgotangco> the current u-m is so different
<Burgundavia> u-m?
<glatzor> Burgundavia: update-manager
<glatzor> THe manual covers update-manager and the software properties
<Burgundavia> ah
<glatzor> that's a pity.
<jsgotangco> well its my fault too i didnt look at it that much, but since both u-m and software propterties are separate now, the guide is really outdated
<glatzor> jsgotangco: I will take a detailed look at the manual
<jsgotangco> ok the current u-m only has 4 buttons
<glatzor> jsgotangco: update-manager istn't the problem. it only needs some minor changes and updated screenshots
<glatzor> but the software-properties are slightly out of date :)
<glatzor> I could perhaps fix this today, since I am going to stay at home today (bike accident).
<glatzor> jsgotangco: Burgundavia: you would agree to a freeze breakage exception?
<jsgotangco> glatzor: oh
<jsgotangco> as long as we can still upload i think its ok, there's a scheduled flight 8 this friday
* jsgotangco is at work atm, doesnt have his tree
<crimsun> jsgotangco: (no, that was cancelled.)
<jsgotangco> ahh
<crimsun> mandatory holiday and all
<glatzor> has anybody seen his screen turning yellow recently? 
<glatzor> mine is nearly complete in yellow
<pitti> Good morning!
<crimsun> 'morning :)
<jsgotangco> glatzor: yeah that was a known issue, but i belive its tagged as fixed
<glatzor> ok
<Gloubiboulga> hello
<sivang> morning all
<ajmitch> hi
<pitti> infinity: bug 39484 can be closed now, right?
<Ubugtu> Malone bug 39484 in samba "cups smb printing backend no longer works" [Major,In progress]  http://launchpad.net/bugs/39484
<pitti> infinity: I'll upload the fix for another major printing regression now and then will do a new round of cupsys bug triage and call for testing
<hendry> does Ubuntu prompt for a screen res when configuring X or is that Debian
<Seveas> ubuntu only does that for wonky graphics setups where it can't be detected automatically
<jsgotangco> heya sabdfl 
<glatzor> jsgotangco: I would like to keep software-properties and update-manager in one document
<glatzor> but I am unsure.
<glatzor> jsgotangco: one again yellow :/
<infinity> pitti: Yes, there are a mess of bugs I need to close now.
<pitti> infinity: yay
<ivoks> phew... cups is back on track again :)
<pygi> ivoks, heh, CUPS 1.2 on Kubuntu? :)
<ivoks> pygi: CUPS 1.2 upstream :)
<pygi> ivoks, eh :)
<pitti> ivoks: yay upstream patch for the octet-stream printing :)
* pitti gives dholbach a good morning hug
<dholbach> heya pitti!
* dholbach hugs pitti
<pitti> ivoks: as soon as my flatmate went out of bed, I'l grab him for testing and then I'll upload the fix
<infinity> s/went/gets/
<ivoks> :)
<pitti> infinity: right, thanks
<ivoks> pitti: yeah, that patch fixed IPP
<infinity> pitti: You're the only person I know who actually wants his english corrected, so I'd be remiss if I didn't do so. :)
<ivoks> but SMB is fishy... i won't say anything untill i test it
<hendry> where should I send failed installation logs to?
<pitti> ivoks: which direction? the cups -> windows print server direction should have been fixed yesterday (thanks to infinity)
<ivoks> i need computer with working windows :/
<pitti> infinity: or do you mean windows client to cups server over smb?
<infinity> Wrong "i" nick.
<ivoks> pitti: i get access denied on printer, but it could be config issue
<infinity> Access denied sounds a lot better than segfaults...
<pitti> infinity: I should really get breakfast before doing anything serious...
<ivoks> :)
* infinity wonders how many more times the icons on his desktop are going to change before release.
<infinity> It's like I get a whole new OS when I wake up and upgrade every morning.
<pitti> did they change again?
* pitti calls restartgnome and watches
<infinity> My Audio CD icon changed, and the connect types for NetworkManager got new icons.  Not sure what else.
<Burgundavia> infinity, grumble. UI freeze has come and gone
<pitti> also, did the System menu get shorter yesterday? I don't actually miss anything, but I have the feeling something was dropped
<crimsun> (I do like the new network monitor icons)
<pitti> oh, I know! "Lock screen" -- /me looks at dholbach
<infinity> Yeah, lock screen went away.  And those icons keep changing too.
<infinity> Log out is completely different today.
<infinity> And had a computer with a power off button.  Hrm.  Mixed signals much? :)
<dholbach> pitti: hu?
<pitti> dholbach: moo
<dholbach> they are going to change
<infinity> pitti: I expect we're meant to lock the screen from the logoff menu now.
<dholbach> and some icons might not be in the right place - I had to transition to use icon-naming-utils
<dholbach> I'm not happy about it, but that's the way it is -- you can poke me or file a bug if something is wrong / feels wrong
* infinity just cheats and locks the screen using his laptop lid button anyway.
<pitti> dholbach: putting 'lock screen' behind an icon with a power switch is even worse than putting 'change user' behind it...
<pitti> hey seb128 
<seb128> hello pitti
<pitti> dholbach: aside from that, it's an extra click
<pitti> and the System menu isn't exactly crowded...
<dholbach> pitti: it will change - bug is known, removing lockscreen was Mark's decision
<infinity> If the recycle icon weren't already used for garbage/trash, it would be the ideal icon for "switch user/reboot/log out"... Too bad, really.
<infinity> The whole feel of "recycling the computer" would work well.  Damn Microsoft for turing that into a "deleted files" logo for everyone.
* pitti votes for a single 'System' menu entry 'Change system state...' which pops a huge dialog with 23 big icons
* infinity laughs.
<dholbach> pitti: "Do something"
<pitti> "Make it so!"
<infinity> Why not get rid of the panel and menus altogether, and just have a huge icon in the middle of the desktop labelled "use computer"?
<pygi> lol
<dholbach> way to go
<infinity> Can someone upload that change to edgy on June 2nd? :)
<pygi> :-P
<ivoks> pitti: well...
<ivoks> pitti: printing works, but windows says "Access denied, unable to connect"
<pygi> Argh, windows again :-/
<infinity> ivoks: Err...
<infinity> ivoks: It prints *and* says access denied?
<pitti> ivoks: erm, you mean printing from the windows box works? or just in genereal, i. e. locally?
<ivoks> right
<ivoks> from windows to cups1.2 works (ipp and smb)
<infinity> Maybe Windows is trying to view the spool and hasn't enough permissions to do that?
<ivoks> but smb says Access denied, unable to connect
<infinity> (Hence the access denied)
<ivoks> could be
<ivoks> i don't do printing over samba very often :)
<infinity> Okay, quick, someone tell me how to setup a null printer (print to postscript or something) in CUPS.
<infinity> I can test the Windows->SMB->CUPS stuff here.
<infinity> But I have no printer. :)
* pitti would guess 'DeviceURI file:///tmp/print.ps' in /etc/cups/printers.conf
<ivoks> i could be my windows broken...
<ivoks> s/^i/it
<ivoks> lol
<ivoks> after restart it says Ready
<seb128> pitti: turn /apps/panel/global/upstream_session, restart your panel, be happy ;)
<pygi> ivoks, windows = always broken :)
<ivoks> but doesn't print :)
<ivoks> omg
<Treenaks> seb128: I LOVE YOU!
<infinity> Holy crap, "reading printer database" takes forever...
<infinity> (Can you tell this is the first time I've ever run gnome-cups-admin?)
<seb128> Treenaks: lol, no need of that much but thank you ;)
<infinity> Oh, and that was useless anyway.
* infinity tried hand-tweaking as pitti suggests.
<Treenaks> seb128: If I'd know of that gconf key earlier.. :)
<Treenaks> +n
<seb128> Treenaks: reading the ChangeLog entries is useful :p
<Treenaks> seb128: sometimes there are too many
* mdke wonders if everyone is going to set that key
<pitti> infinity: you can create an arbitrary printer and then change printers.conf manually; the file:/// destination is disabled by default for some reason
<janimo> bug 45180
<Ubugtu> Malone bug 45180 in xubuntu-live "After install xubuntu from live cd, xubuntu-live package is also installed" [Normal,Unconfirmed]  http://launchpad.net/bugs/45180
<hendry> my fresh install of Ubuntu's time is wrong. How do i fix it?
<janimo> is that normal, just not seen with ubuntu/kubuntu because they don;t ship more language support packs?
<hendry> when i run ntpdate, it says "no servers can be used"
<pygi> janimo, no, that shouldnt be there
<infinity> pitti: Hrm, cups-pdf seemed to be precisely what I wanted, but doesn't actually do anything.
<infinity> pitti: Does it need updating to work with cups 1.2?
<pitti> infinity: cups-pdf iz broken
<janimo> pygi: so ubuntu-live is not on an ubiquity installed system?
<ivoks> you need to run cups as root for that
<pitti> infinity: bug 36093
<Ubugtu> Malone bug 36093 in cups-pdf "needs to be fixed to work with cupsd running as non-root" [Normal,Confirmed]  http://launchpad.net/bugs/36093
<infinity> pitti: Ahh.  How do I mangle cups to run as root?  Init script?
<pitti> infinity: luckily, Mike Sweet already started implementing native PDF support for cups
<pygi> janimo, well, ubuntu-live *and therefore xubuntu-live* shouldnt be there after installation
<pitti> infinity: Mike removed the RunAsUser option in 1.2, so you can't any more
<ivoks> he did?
<janimo> pygi: ok thanks
<pygi> janimo, that bug for ubuntu-live was fixed I think
<mdke> hendry: #ubuntu or #ubuntu+1
<ivoks> oh my
<pitti> (that was a very bad idea, yes...)
<infinity> Oh.  Fun.
<pitti> infinity: in his opinion, RunAsUser was unsafe, and distros should rather use SELinux and the like
<pitti> lol
* infinity removes cups-pdf and does it the other way.
<ivoks> i guess he never tried to use selinux :)
<janimo> Kamion: is it ubiquity that has to be told not to install xubuntu-live?
<pitti> infinity: ah, edit /etc/cups/cupsd.conf and add 'FileDevice Yes'
<ivoks> afaict my smb.conf is ok, but it's access denied and it prints
<Gloubiboulga> janimo, hi, I have casper and ubiquity packages installed on the HD too
<janimo> Gloubiboulga: hi, ok let's see what the desktop CD people say
<pitti> infinity: then you can create an arbitrary printer (preferably with Generic/PostScript driver) in gnome-cups-add and then change printers.conf 
<pygi> Gloubiboulga, ergh, I thought that bug was fixed
<pygi> from what live cd?
<Gloubiboulga> may 15th IIRC
<janimo> pygi: it may not have been for xubuntu if an explicit blacklist of some sort is needed
<Gloubiboulga> I can trry with a more recent live cd
<pygi> Gloubiboulga, no need.
<pygi> jamesh, indeed
<looksaus> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Confirmed]  
<looksaus> what else can I do to find out more information about this one so the bug can be rooted out?
<pygi> janimo, have you tracked bug like that for Ubuntu on launchpad?
<pygi> perhaps there is an explanation
<janimo> pygi: I was not aware of such a bug till this morning when Gloubiboulga reported it
<looksaus> I'm willing to setup a vnc server or something for a developer to check remotely
<infinity> pitti: Hrm, no dice.  When I try to print a test page, it just sits there with "Printing 1 Jobs" (yay, badly formatted strings) and doesn't spit anything out to the file.
<looksaus> I'm getting a bit scared that this problem might still be there with the Dapper release
<pygi> janimo, hm, I can try tracking it down later if you want
<pitti> infinity: anything in /var/log/cups/error_log?
<pitti> infinity: did you set the destination to somewhere in /tmp?
<ivoks> pitti: also, printing/browsing/everything works fine with 1.1<->1.2
<janimo> pygi: thanks, if we don;t get a clarification on irc this morning
<infinity> E [17/May/2006:17:36:17 +1000]  [Job 1]  No %%BoundingBox: comment in header!
<infinity> pitti: Yeah, I just copied and pasted your stuff from above. :)
<infinity> pitti: Looks like it doesn't like the job itself.  Awesome.
<pitti> infinity: hm, that works fine for me
<infinity> Hrm.  My DeviceURI got over written...
<infinity> Weird
<pitti> infinity: I grabbed a postscript file, created a file:/// printer 'f' and did 'lp -d f /home/martin/latex/test/formel.ps'
<ivoks> hm...
<pitti> ivoks: darn, none of my flatmates is at home and I don't know their windows passwords; if you confirm that the patch really fixes octet-strem, I'll just upload it
<ivoks> smbd[14535] :   astro (192.168.0.101) couldn't find service ::{2227a280-3aea-1069-a2de-08002b30309d}
<ivoks> pitti: it does for IPP, but i'm not 100% sure this is everything needed to get SMB printing back on track
<ivoks> pitti: windows passwords? :))
<pitti> ivoks: alright, then let's test and rock
<ivoks> pitti: that's easy...
<ivoks> pitti: i'm sure none of them has password for 'Administrator' account
<infinity> pitti: Okay, got that sorted.  Now to test from Windows...
<pitti> ivoks: I don't know the Windows equivalent of 'init=/bin/bash' :)
<ivoks> pitti: on login screen, hit ctrl+alt+del twice
<pitti> ivoks: they have, and they don't work as admin. Just because they are *my* flatmates :)
<ivoks> pitti: and enter Administrator for username, blank password
<ivoks> pitti: works in 99% of cases :D
<ivoks> if it's XP
<ivoks> so, java is going open source after all? says Shwartz
<janimo> pitti, sorry to bring this up again, but is there a chance to consider a separate evince-gtk source pkg for main?
<janimo> doing it withing evince proper is too instrusive
<janimo> and I have cleaned up the package FWIW so it's almost like the evince one
<infinity> pitti: Okay, same results.  A WinXP test page printed fine, but the spool viewer claims lack of rights to the printer.
<janimo> otherwise an alternative would be another app in main (epdfview) but evince is more tested
<pygi> ivoks, indeed, just we dont know which licence yet
<infinity> pitti: I'll poke at that.
<pygi> ivoks, perhaps "Sun Open Source Licence" :-D
<ivoks> infinity: imho, this is samba issue
<janimo> another alternative is no doc viewer at all in default install
<infinity> ivoks: Perhaps, but I don't recall ever having this issue before.
<ivoks> me too
<ivoks> infinity: smbd[14535] :   astro (192.168.0.101) couldn't find service ::{2227a280-3aea-1069-a2de-08002b30309d}
<ivoks> infinity: that's only error i get in logs
<crimsun> janimo: just considering security, I'd vote for no doc viewer by default to avoid yet more source to fix
<infinity> pitti: Should I be concerned about all the "cupsdAuthorize: Local authentication certificate not found!" in the log file?
<janimo> crimsun: right, althoug most flaws are in poppler not the viewver itslef no?
<infinity> ivoks: In which log are you seeing that?
<crimsun> janimo: hmm, yes
<ivoks> infinity: syslog (i redirected samba logs in syslog, and set syslog level to 256)
<ivoks> infinity: astro is a client machine
<infinity> pitti: Also, cupsd complains repeatedly about not being able to open access_log.
<ivoks> infinity: certificate is cause it trys SSL first
<ivoks> tries
<janimo> crimsun: and the slight advantage over this kind of duplication is that you fix the same thing, whereas with a totally different app you may have a new flaw altogether
<infinity> pitti: Hrm, which could be because it was created as root...
<janimo> s/over/of/
<infinity> ivoks: Okay, as I thought.  The "Access Denied" is because WinXP is probing to see if it can admin the remote print spool.
<infinity> ivoks: Adding "printer admin = @lpadmin" to my smb.conf, doing "adduser testuser lpadmin", and restarting samba made the error go away.
<ivoks> infinity: right...
<infinity> ivoks: Either way, with or without that error, I can print to the printer just fine.  The error seems to only relate to spool manipulation, not job creation.
<infinity> pitti: ^^^
<ivoks> infinity: but... you know what's funny
<ivoks> infinity: after restart it's Ready and doesn't print
<ivoks> so... i don't know should i laugh or cry
<infinity> ivoks: Okay, that's bizarre.  On mine, it's "Ready" and prints fine. :)
<ivoks> i really hope vista will have IPP browsing
<infinity> pitti: Do you think I should change the default SMB config to suggest using "printer admin = @lpadmin" (commented out, of course), so people can figure this one out? :)
<infinity> ivoks: AFAICT, Microsoft is moving 100% to IPP, so I assume it will.
<infinity> ivoks: SMB printing has always been a hideous hack, and I'm sure they'll be glad to drop it and move on.
<ivoks> finally
* pygi suggests infinity to do that
<infinity> ivoks: The fact that SMB printing requires local drivers on the client machine is a big non-starter.  How it survived this long, I'll never know.
<ivoks> infinity: i allwayes hated smb printing :/
<ivoks> always
<infinity> ivoks: So does every NT admin (me included) that I've ever known.
<infinity> It's not just doing it via samba that sucks, doing it on NT server is just as bad.
<infinity> "What do you mean I need to have client print drivers for each printer on every single workstation?  For how many operating systems on how many architectures?  Say what now?"
<ivoks> infinity: um... can you please restart your windows and try printing again?
<morgs_> hiya, if flight7 ubiquity failed to resize an ext3 partition and created a zero-length partition, where should I log the bug? Is it ubiquity or gparted or...?
<ivoks> infinity: it just doesn't work here :(
<infinity> ivoks: Alright, I have to save some stuff my girlfriend was mangling in Photoshop... 'Sec.
<ivoks>  WARNING: The "printer admin" option is deprecated
<ivoks> oh, lol
<dholbach> heya mvo!
<mvo> hey dholbach
<pygi> ivoks, nice :)
<infinity>               This  parameter  has  been marked deprecated in favor of using the SePrintOperator
<infinity>               Privilege and individual print security descriptors. It will be removed in a future
<infinity>               release.
<seb128> hi dholbach
<seb128> mdke: around?
<looksaus> why does my ppc ibook have a sun-java5-jre package, while it doesn't have a sun-java5-bin?
<dholbach> hi seb128!
<Kamion> janimo: yes, it's a ubiquity thing, but it should be done automatically by the stuff we put in place ages ago; I've asked for more information
<seb128> dholbach: ups, I'm too used to type your name, I was thinking "hi mvo" ;)
<Kamion> morgs_: was this the automatic "resize <partition> and use free space" option, or did you go to "manually partition" and choose to resize something there?
* dholbach hugs seb128
<Kamion> janimo: by the way, are you aware that Xubuntu live filesystem builds have been failing for some time? see e.g. http://people.ubuntu.com/~lamont/liveLogs/dapper/xubuntu/latest/livecd-20060517-i386.out
<Kamion> xubuntu-docs is failing to install
<infinity> I was just about to mention that. :)
<morgs_> Kamion: it was a couple of days ago, and I rebooted since then so I can't remember exactly, but I think it was the automatic option.
<morgs_> Kamion: I'm just trying to repair my hda1, if I can fix it I'll try again to duplicate the problem.
<Kamion> morgs_: then ubiquity; please attach /var/log/installer/syslog and /var/log/installer/partman to the bug report
<morgs_> Kamion: OK
<Kamion> (please do that before potentially trashing the disk :-))
<ivoks> pitti: i see you are in upload mood :) maybe to upload that addition for g-c-m, so translators have time to translate it? :)
<morgs_> Kamion: somehow my hda1 partition (ext3) shows as ext3 in cfdisk, fdisk etc but in gparted it shows as "unknown". If I try mount it I get a bad superblock or missing filesystem... so perhaps it's already trashed. Unfortunately I rebooted after the installation attempt so I lost the logs.
<looksaus> hm, there is a sun-java5-jre package on ppc, but no sun-java5-bin
<pygi> looksaus, use #ubuntu
<looksaus> k
<looksaus> pygi, oops, told this twice in the same channel, sorry
<infinity> ivoks: Printing (and spool admin) still works after a reboot of the XP machine.
<infinity> ivoks: Looks like your problem is local. :/
<ivoks> infinity: great :)
<ivoks> infinity: yeah... windows doesn't even try to connect to my share after reboot... if it's just me, thats great
<Kamion> morgs_: cfdisk/fdisk are showing the partition type code; gparted is actually scanning the contents
<ivoks> infinity: sorry for unneeded reboot :/
<Kamion> morgs_: what vintage of live CD was this?
<infinity> ivoks: S'ok.  I just hate rebooting my girlfriend's machine when she's not home. ;)
<infinity> ivoks: I'll be sure to blame you when she asks.
<AnAnt> may someone help me with creating a package ?
<AnAnt> I used pbuilder to create elinks-0.11.1 package 
<morgs_> Kamion: flight 7
<ivoks> infinity: oh no! lucky my, i'm so far far away :)
<infinity> AnAnt: -> #ubuntu-motu
<infinity> AnAnt: Also, the last two weeks before release may be the wrong time to be asking people to help mentor you.
<AnAnt> but it called it elinks_0.11-0.0upstream.deb
<AnAnt> infinity: huh ? what release are u talking about ?
<AnAnt> what two weeks ?
<infinity> AnAnt: Dapper.  Releases in 2 weeks.  We're busily working on that.
<ivoks> AnAnt: we'll talk in #ubuntu-motu
<AnAnt> oh, ok
<AnAnt> well, maybe u can include that latest elinks package in it 
<ivoks> ok
<pygi> AnAnt, no,we cant
<ivoks> then, AFAICT cups is done
<ivoks> yay1
<pitti> ivoks: mvo prepared the package yesterday, I hope we can get it uploaded now or today
<ivoks> pitti: ok
<AnAnt> pygi: is there some process for it ?
<pitti> mvo: good morning!
<pygi> AnAnt, well, you cant get packages in just 2 weeks before a release
<AnAnt> pygi: np, I was kidding about that
<mvo> pitti: hello, its on people.u.c (ubuntu7.2)
<mvo> ivoks: we changed it so that browsing and shareing are independant options
<Kamion> AnAnt: the process involves turning up at least a month ago; we look forward to your time machine :)
<ivoks> mvo: ok... it makes sense and that's what i wanted first
<AnAnt> Kamion: np, it can be in the one after, right ?
<ivoks> mvo: but it's kind of misleading for users that don't know cups very well :)
<mvo> ivoks: cool, can you test the new souce too (its only deb-src currently) please? 
<ivoks> mvo: sure
<pygi> AnAnt, indeed
<mvo> pitti: blast, sorry. I have not yet uploaded the change from "Detect LAN printers" to "Detect/advertise LAN printers" :/
<ivoks> :)
<AnAnt> pygi: I meant, how/where to submit it ?
<ivoks> nice touch
<pygi> AnAnt, any packaging questions --> #ubuntu-motu :)
<AnAnt> ok
<pitti> ivoks: we should keep the code easy at this stage of the release, and some people might actually want to just open cups for windows clients (which doesn't need browsing)
<ivoks> pitti: i understand, i even like the idea :) but we should document that (since CUPS it self doesn't have very straightforward documentation)
<pitti> ivoks: I agree; 
<ivoks> pitti: what are other plans for automatic printing spec?
<ivoks> pitti: sharing printers could be easily expaned to SMB (printing = cups; printing = none)
<pitti> ivoks: let's consider that post-release :)
<ivoks> pitti: so i guess, for edgy we have sharing covered
<ivoks> pitti: of course that's for post-release :)
<pitti> ivoks: but in short, cups 1.2 has dbus support now, so we should tie this into the gui
<ivoks> i see, for local autodetection
<pitti> ivoks: i. e. plugging in a new printer should spawn g-cups-add or something even simpler automatically if the printer is not yet configured
<ivoks> right
<ivoks> that could be done for edgy
<pitti> yes, I hope so
<pitti> we'll drop gnome-cups-manager, too
<pitti> it's abandoned upstream and pretty buggy, so we'll switch to eggcups or whatever; I didn't deal with that yet, though
<ivoks> ok
<pitti> hi mdz
<mdz> hi
<seb128> hey mdz
<infinity> mdz: 'Morning.  I finally got that OOo build to die in the same spot... But not with a SIGABRT this time, instead with an illegal insn.
<infinity> mdz: (Died overnight, haven't played with it yet, just saw the log)
<mdz> infinity: curiouser and curiouser. how?
<mdz> was just pulling down the source to play with that now that I have bandwidth
<infinity> mdz: No idea "how", really.  Just a by-hand reproduction of the LP-buildd process, unpack-chroot, mount stuff inside, upgrade, sbuild...
<mdz> infinity: but you said you tried that before and couldn't reproduce it
<infinity> Which I'd done previously too, but maybe I missed something the last time (the only difference that pops to mind is /dev/pts being mounted... Not sure I want to kill another 6 hours testing that theory, but I can)
<ivoks> bye all
<infinity> mdz: Last time, I did it very by hand.  This time, I used the lp-buildd scripts.
<mdz> I see
<infinity> mdz: Like I said, the only thing that I /think/ would be different is /dev/pts, but that makes no sense to me (how that could lead to a sigabrt or illegal insn)
<infinity> Anyhow, I'm poking more today in the background as I do other stuff.
<mdke> seb128: sort of
<seb128> mdke: would changing gaim to not open the "create account" on first startup would be an issue for documentation team?
<mdke> seb128: no
<mdke> seb128: lemme check something quickly
<seb128> mdke: it's sort of useless, it got stacked behind the account list one which add an obvious "add" button
<infinity> And this is the part where I scream because I realise my .sbuildrc had $purge_build_directory="always" in it...
* infinity restarts the buildand hopes it fails again.
<seb128> mdke: they don't open if with gaim 2.0beta3, I want to do that change for dapper too
<mdke> seb128: no problem
<seb128> mdke: ok, thank you
<Usiu> Hi
<Usiu> /usr/bin/cdebootstrap
<Usiu> E: Unknown suite dapper
<Usiu> any help ?
<Usiu> Laurens_S, are You a developer?
<Kamion> use debootstrap instead; we've never made cdebootstrap work properly with Ubuntu
<Laurens_S> no, just lurking - if that's in apropriate, I'lll leave
<Kamion> Laurens_S: lurking is fine
<pitti> mvo: so you will wait for ivok's test results before uploading gcm?
<Laurens_S> ok
<sladen> mdz: when "next week" does your manual uploads monitoring kick in?
<mdz> sladen: deliberately unspecified
* sladen chuckles
<mdz> sladen: if there's something you're planning on landing, it should have been in already
<mdz> the last two weeks should be entirely release prep
<sladen> only bug-fixes
<mvo> pitti: do we have the ok from the release team?
<pitti> mvo: doc team said yes, Colin too
<pitti> mvo: let's ask mdz, too
<infinity> mdz: What about universe?  Slightly more liberal there still?
<pitti> mdz: we have a small gnome-cups-manager patch which adds a 'Share local printers' menu option. This just calls /usr/share/cups/enable_sharing. It breaks the UI, but doc-team is fine with it
<infinity> mdz: (Thinking about the "dmraid initramfs support" thing, which is in universe, and the contributed scripts appear to be good and work fine)
<Usiu> Kamion, E: No such script: /usr/lib/debootstrap/scripts/dapper
<Usiu> I am building on debian
<infinity> Usiu: So, install our version.  It installs fine on Debian.
<infinity> Usiu: http://packages.ubuntu.com/dapper/admin/debootstrap
<mdz> infinity: yes
<mdz> pitti: this sounds awfully like a feature
<Usiu> infinity, thx
<pitti> mdz: yes, it is, that's why I asked so many people; it adds the missing UI bit to the cups script
<mdz> pitti: mail me the patch?
<mdz> pitti: who created the patch?
<pitti> mvo: ^ you have the current one, can you do?
<pitti> mdz: it was initially created by ivoks, and mvo fixed some stuff and made it easier (we discussed and tested this yesterday)
<pitti> mdz: now the patch is basically a copy&paste&tweak of the already existing 'Enable browsing' patch
<Usiu> infinity, one more thing (important) is the dbus services dir the same in dapper as in debian?
<Usiu> infinity, /usr/share/dbus-1/services/
<Usiu> ?
<infinity> Usiu: No idea.
<mdz> pitti: I'd like to look over the patch
<pitti> mdz: sure
<Kamion> it's /usr/share/dbus-1/services/ in dapper, yes
<mvo> mdz: I can send you both the new and the old patch or a diff of the patches (but that is going to be not readable)
<mvo> or both of course
<mvo> :)
<Kamion> mvo: interdiff!
<Usiu> thx
<Usiu> Kamion, thx
<mdz> mvo: if the new patch is so complex that I won't understand it without the old patch, we don't want it ;-)
* mvo drinks a cups of tea before typing more nonsense
<infinity> mvo: "a CUPS of tea"?... Looks like someone needs a vacation.
<pitti> infinity: but it fits, given that it's about printing :)
<Treenaks> http://openclipart.org/clipart/food/beverages/teacup_bw.svg
<mvo> infinity: you are so right
<Kagou> hi
<sivang> mvo: hehe :)
<sivang> infinity: sharp eyes you have
<Kagou> infinity, wow what a huge release for samba :) thanks 
<mdz> pitti: PS, I'm going to sleep very soon
<Kagou> infinity, 10 bugs closed in the same time ... are you looking for a record ?! ;)  dholbach have to make a big hug :D
* dholbach hugs Kagou! :)
<dholbach> Happy Hug Day!
<mdz> mvo: this patch is way too big
<mdz> pitti,mvo: please defer until after the release
<pitti> hm, ok
<mvo> mdz: ok
<mdke> Kamion: an email for you: https://lists.ubuntu.com/archives/ubuntu-translators/2006-May/000587.html
<janimo> Kamion: was not aware of the liveCD build failure, has it been happening before today as well?(latest xubuntu-docs upload was yesterday)
<mdke> Kamion: can you make sure string changes are always notified to that mailing list, if there are any more?
<infinity> janimo: Older livefs build failures appeared to be due to xubuntu-desktop being uninstallable, which I assumed you would have known about...
<janimo> infinity: right. iwj uploaded a xubuntu-docs yesterday may be it?
<janimo> although I just installed fine here
<pitti> janimo: see http://people.ubuntu.com/~cjwatson/anastacia.txt
<pitti> janimo: apparently xubuntu-desktop depends on some universe packages
<janimo> pitti, hmm those which have not yet been promoted
<pitti> janimo: I recognize the names, most (all) of them have been approved, so they need to be promoted
<janimo> but it's ok since the seeds to not translate to the desktop package
<janimo> pitti, they have been in the seeds for the long time. But the script wjhich makes xubuntu-desjtop ignores them so np AFAIK
<janimo> pitti, yes 5 of them you approved yesterday :)
<pitti> janimo: seeding is fine, but as long as the packages are in universe, they are uninstallable
<janimo> xubuntu-desktop has been installable afaik. Weird, can liveCD install fail if I can just install the package fine on an existing  system?
<janimo> so liveCD uses it's own thing instead of apt if I recall corerecly?
<pitti> janimo: because you have universe enabled?
<janimo> pitti, not because univers
<janimo> pitti, xubuntu-desktop the metapackage does not depend on universe stuff
<janimo> only the desktop seed has them
<janimo> they are only going from seed to metapckage when they are in main
<janimo> until then I thought the do no harm, but apparently liveCD cares
<infinity> janimo: ubuntu-desktop is obviously installable now (or we wouldn't be getting the ubuntu-docs failure), so I think the point is moot.
<infinity> janimo: It /was/ uninstallible in the past, that's all.
<Kamion> mdke: will do, but the only one I was aware of lately outside of ubiquity was in user-setup, which came with a bunch of translations from upstream
<Kamion> mdke: I don't intend for there to be any more, though
<Kamion> janimo: I noticed the same build failure yesterday
<janimo> infinity: I am not saying it was not, just that maybe it could have been causing problems ofr livecd build but otherwise install fine
<mdke> Kamion: ok. If you want to pass me an answer to that email, I'll pass it on (about when you're going to be downloading the translations)
<Kamion> mdke: I expect I'll do it on Sunday night or Monday morning, if that's OK with mdz ...
<Kamion> Thursday evening is cutting it a bit fine, and I'll be away Friday -> Sunday
<mdke> Kamion: same as with the docs :) great, I'll pass that on
<Kamion> mdke: if you don't mind being a conduit for me, it might also be worth passing on that where the installer is concerned, I always let upstream translations take priority; anything else means that I get put in the position of trying to decide which of two strings I don't understand is better, when it comes to merge time
<Kamion> so "accidentally overwriting some Rosetta translations" is wrong, but only because it's deliberate
<janimo> Kamion: ok, looks like my latest xbuntu-docs upload botched something
<Kamion> unfortunately there is no good Rosetta workflow for passing string changes made in Rosetta upstream, at present, so if translators are making necessary corrections then they really need to pass those upstream themselves
<Kamion> (similarly, I can't realistically pass all of those on, because I don't know why they were made)
<mdke> Kamion: sure thing
<Kamion> thanks
<iwj> ispiked: Did the person get it to work ?  Which patch ?  What error ?  etc.
<mdke> Kamion: can you answer the last paragraph of that email too?
* mvo goes for lunch
<sivang> mvo: bon appetite
* sivang waits for his launch to arrive.
<mdke> Kamion: also, when you say you give priority to upstream, that is when merging into Rosetta, so any later changes in Rosetta will still be effective, correct?
<Kamion> mdke: forward/back> those are stock gtk strings
<Kamion> mdke: (although I may switch to the "Go Back" / "Continue" strings that are already translated, because gtk strings require language packs to be installed; haven't decided yet, but it won't require translator action either way)
<mdke> Kamion: gotcha
<Kamion> mdke: I completely ignore Rosetta changes to installer strings that have existing translations upstream; I'm just not equipped to make that decision
<Kamion> so I go for minimal diff to upstream as a default action
<mdke> whoa
<Kamion> remember that the installer is not subject to language packs, so I have to import everything by hand
<mdke> so when you download the rosetta translations, you strip out those which have changed since upstream?
<Kamion> I think you've got the sense of the activity the wrong way round
<Kamion> I have to apply all these by hand - I only apply changes to Ubuntu-specific strings and ones which don't have existing translations upstream
<Kamion> there isn't really an active stripping out
<mdke> well, all the upstream strings are also in the po files in rosetta, so in theory you could get everything there, and give effect to the changes of the ubuntu teams. but, anyway, I've got the answer, thanks
<Kamion> I could, but I'd have to upload every installer package
<Kamion> there are like 50-odd of them
<mdke> ah right
<Kamion> the human effort on my part would be really very considerable indeed
<mdke> ok, it's useful for the translators to know what's up, because the behaviour is different for everything else (ubuntu changes take precedence). thanks for the info
<Kamion> I'm happy to take changes if translators let me know that they're super-urgent, but I just can't manage it as a general rule
<Kamion> yeah, sorry if it's been unclear, I haven't made any secret of the way I handle installer strings but I may not have broadcast it either
<mdke> np, i think in general people will be happy for upstream to take precedence
<mdke> the other way round has often been problematic
<Kamion> and as I say, for Ubuntu-specific strings obviously I get translations for those from Rosetta
<Kamion> and I try to pass them upstream if the string goes upstream
<mdke> Kamion: ok, i'll let you get back to work. thanks
<Kamion> thanks for forwarding
<mdke> np
<ivoks> mvo: ping
<ivoks> mvo: g-c-m needs revision of pop-up messages when enabling sharing local printers (it says that it will enable browsing, which is not true any more)
<janimo> ivoks: mvo is lunching
<ivoks> janimo: he will see message, i hope :)
<ogra> iwj, what did yu change in edubuntu-artwork yesterday ? seems the default homepage doesnt work in epiphany anymore 
<iwj> ogra: Urr.  I added another couple of symlinks.  I even diffed the resulting .debs and I'm pretty sure that nothing was removed from edubuntu-artwork.
<iwj> seb128: Did you upload the new epiphany ?  Did you try it with edubuntu ?
<ogra> hmm, jsgotangco reported it doesnt work anymore, jsgotangco `
<ogra> ?
<seb128> iwj: no, not yet, I'm going to do that after being done with google SoC stuff
<ogra> ah, ok, so it depends on a specific ephy upload, ok
<ogra> Kamion, http://cdimage.ubuntu.com/edubuntu/daily/current/report.html disagrees with the cd build log
<iwj> ogra: Do you have any reason to think this bug is caused by the edubuntu-artwork change ?
<ogra> (amd64 is still 3M oversized, there must be uninstallables=
<ogra> )
<Kamion> that's an interesting assumption
<ogra> iwj, it appeared today and the only related change was your upload
<Kamion> how do you know it'd be packages that overflow, or that the packages that overflow would be ones that other packages depend on?
<ogra> Kamion, i'd think its a very special case to match the point where a package thats on CD 2 has no deps :)
<ogra> so we met a cornercase ? 
<ogra> (at least i've never seen that before :) )
<Kamion> ah, heh
<Kamion> Traceback (most recent call last):
<Kamion>   File "/srv/cdimage.no-name-yet.com/britney/update_out/check_out.py", line 4, in ?
<Kamion>     import britney;
<Kamion> ImportError: No module named britney
<ogra> ok :)
<Kamion> probably a side-effect of switching to bzr; I'll sort it out
<Kamion> thanks
<iwj> ogra: I don't think my change can have caused this but the right approach is to debug it.
<ogra> thanks as well :)
<ogra> iwj, yep, will check it
<iwj> Thanks.
<Kamion> right, that 'make' should have taken care of it
<iwj> ogra: Also, note that we've had some difficulty with the `firefox-homepage' alternative mistakenly getting set to `manual'.
<Kamion> let me know if it still happens tomorrow
<iwj> ogra: It doesn't happen every time and I suspect a bad package some time earlier in dapper to be responsible but it might be relevant.
<iwj> So if `update-alternatives --display firefox-homepage' shows manual, then that's probably the bug.
<iwj> ogra: In that case we want to know the upgrade history of the machine.
<ogra> iwj, ok, thanks ... we should find something better for edgy here
<ogra> instead of alternatives ...
<iwj> I don't think there's anything fundamentally wrong with the current setup except the clumsy interaction with the ff localisation system.
<iwj> instead of alternatives> So you can have one machine be {,k,x,ed}ubuntu, you mean ?
<ogra> nope, but we should probably not abuse the alternatives system for this purpose i think ...
<iwj> Why don't we talk about this in Paris :-).
<ogra> at the moment we use two different systems here (alternatives *and* linking for nonexistent locales), where we could use only one (only links, even for disto specific subdirs)
<Kamion> Would anyone care to investigate an apparent yaboot/kernel (not sure which) bug for me?
<Kamion> https://launchpad.net/distros/ubuntu/+source/yaboot/+bug/40973
<Ubugtu> Malone bug 40973 in yaboot "Dapper PPC beta CDs yield blank screen on Graphite iBook" [Normal,Unconfirmed]  
<Kamion> these bugs may also be related:
<Kamion> https://launchpad.net/distros/ubuntu/+source/yaboot/+bug/40342
<Ubugtu> Malone bug 40342 in yaboot "Failure to boot after install" [Normal,Unconfirmed]  
<Kamion> https://launchpad.net/distros/ubuntu/+source/yaboot/+bug/40692
<Ubugtu> Malone bug 40692 in yaboot "No boot with 1.3.13-4.1ubuntu4" [Normal,Unconfirmed]  
<Kamion> https://launchpad.net/distros/ubuntu/+source/yaboot/+bug/45213
<Ubugtu> Malone bug 45213 in yaboot "Booting on IBM pseries server" [Normal,Unconfirmed]  
<Kamion> https://launchpad.net/distros/ubuntu/+source/yaboot/+bug/40092
<Ubugtu> Malone bug 40092 in yaboot "it doesn't boot" [Normal,Unconfirmed]  
<Kamion> the thing is that about the only thing that's changed that could cause all that breakage is that we've recompiled
<ogra> i wonder if these machines have nvidia cards
<Kamion> ogra: no
<Kamion> pseries won't
<Kamion> (at least I'd be astonished)
<Kamion> so I think it might be due to building with gcc-4.0
<ogra> hmm,, i still see usplash timeouts on ppc
<ogra> and i know we have a bug that hardlocks with nvidia drivers if you switch to coinsole
<Kamion> please stop conflating bugs!
<Kamion> good grief, not every powerpc bug is the same
<Kamion> I'd like somebody to try building yaboot with gcc-3.3 and putting together a test CD image for these folks to try
<Kamion> to see if that clears it up
<Kamion> if it does, we need to roll back yaboot to building with gcc-3.3, and start diffing assembly and stuff to find out where the bug is
<ogra> does it need to be a CD ? wouldnt a package and running ybin suffice ? 
<Kamion> a CD would be a lot easier for people to test in some of these cases
<Kamion> they do not all have working Ubuntu installs
<Kamion> it doesn't have to be a full CD; an install CD with all of dists/ and pool/ removed would be quite adequate
<iwj> Are there instructions somewhere on how to do a CD build ?
<tseng> iwj: they are from breezy
<tseng> LiveCDCustomizationHowto
<Kamion> those instructions are adequate in this case if you ignore nearly all of them :-)
<Kamion> give me a moment
<Kamion> iwj: OK, just grab an existing CD image, loop-mount, copy, hack, and then the "Putting the CD back together" part of https://wiki.ubuntu.com/LiveCDCustomizationHowTo should be adequate now
<Kamion> (even if it's an install CD; the mkisofs bit doesn't vary between install and live CDs)
* Kamion goes to sync InstallCDCustomizationHowTo from that
<iwj> OK.  I'll give it a go.  Starting with the 20060126 daily ?
<Kamion> that sounds rather too old for this
<Kamion> today's daily would be preferable
<Kamion> thanks for the help
<iwj> The `current' daily installer in my mirror is 20051026ubuntu13.0.20060126 dated January.  Everything else in my mirror is obviously up to date.
<iwj> Is it possible this is a soyuz bug ?
<Kamion> daily-installer-* is dead, yes, that's a soyuz bug; use installer-* instead
<iwj> Oh!  *light dawns*
<iwj> 20051026ubuntu32 looks better.
<Kamion> um, I had been thinking of starting with an actual CD build though rather than from the installer; for instance I can't guarantee that the breakage isn't due to Ben's automatic powerpc/powerpc64 switching code, which would take some effort to reproduce based on the d-i output in your mirror
<Kamion> I'll build a CD image with dists and pool stripped out based on today's daily build, which should be a lot quicker to download
<sladen> where's a keybuk when you want him
<iwj> OK, thanks.  Otherwise I can start downloading it now and do something else for an hour or two ...
<iwj> I think I need coffee.
<Kamion> iwj: http://people.ubuntu.com/~cjwatson/tmp/dapper-install-powerpc-stripped.iso
<iwj> Kamion: ta.
<Kamion> I wouldn't mind if somebody with a powerpc with a working CD drive could test-boot that to see that it at least gets you into the installer, BTW. It won't actually *install* anything, since I took out most of its brain, but ...
<Kamion> If nobody has time at the moment, then it might be worth giving them that image too as a control.
<infinity> Does anyone have a powerpc machine that can boot from CD? :)
* infinity thinks he should probably buy one after the release.
* mvo points to dholbach
* pitti raises hand
<dholbach> infinity: yes, quite an aged one
<iwj> Kamion: Just to be sure I'm not completely confused, what I plan to do is to unpack gcc-3.3 in my filespace in one of the DC ppc chroots and then build yaboot from dapper using that.  I expect this to produce a udeb which I stuff into the fs image.  Is that right ?
<infinity> iwj: No, we're talking about the actual yaboot used to boot the CD in this case.
<Kamion> iwj: nearly, except for the udeb bit; the .deb it produces will contain /usr/lib/yaboot/yaboot, with which you should overwrite /install/yaboot in the image
* iwj reads LiveCDCustomizationHowTo again.
<iwj> Ah, right.  OK.
<sivang> Kamion: should this work on a pSeries as well? :) (reminding our old old discussions about it)
<Kamion> sivang: yes, I'd hope so
<Kamion> sivang: we have one bug about current images not booting on a pSeries, so if you have one to hand, testing that stripped image would be good
<infinity> sivang: In theory, it should.  Since I have no pSeries machine to test on...
<sivang> Kamion, infinity : I really need to free up some time and test it, or get a pSeries over home :) 
<infinity> sivang: You're welcome to convince IBM (or, more likely, a small IBM vendor with their hearts in the right place) to ship me a really low powered one.
<infinity> sivang: But no amount of testing at this point will allow us to fix any but the simplest bugs, so here's hoping it already works.
<sivang> infinity: hehe, I'm already on a waiting list of one like this when it gets availabel from a local IBM consultancy firm, which I have connections at.
<Kamion> gcc-3.3 is still in main; switching back to that is doable if that's what it takes
<thom> infinity: can you not blag an openpower box off OzLabs? i'm sure they'd be receptive
<infinity> thom: Can you repeat that in International English?
<sivang> thom: right, what about the non native speakers? :)
<infinity> thom: (And I've never talked to anyone at OzLabs, so I dunno)
<thom> infinity: does blag not translate to north american?
<infinity> thom: Nope.
<ogra> thom, blag translates to "unloved child" in german
* sivang downloads
<thom> bummer. it means, "talk them into giving you"
<infinity> thom: Though without you defining it, I'd perhaps translate to "scam" or "swipe", based on context.
<Kamion> scam is closer than swipe
<sivang> I will go try this as soon as it finished download on the black machine.
<thom> Kamion: but less all out criminal than either, generally
<Kamion> yeah
* sivang goes to burn
<siretart> Kamion: FYI: I'm currently talking to Mrfai about fai-kernels. They intend to switch from fai-kernels to something initramfs-tools based for etch, so I expect fai-kernels to die for edgy
<infinity> thom: According to Zofia, it's not a word in en_AU either, so there you go.
<thom> your crappy ripped off englishes are deficient then
<thom> :-)
<Kamion> siretart: hooray
<siretart> but for dapper, we still need fai-kernels so fai can be used for something.
* Kamion makes ubiquity deal with /media/* automounting
<Kamion> woo
<Kamion> (and it shows you them, so you can decide not to ...)
* pitti hugs Kamion 
<seb128> hum
<seb128> "Could not fin kernel image: /casper/filesystem.kernel-386"
<seb128> is daily build known to be broken or is that likely to be an issue with my CD?
<Kamion> seb128: is that daily or daily-live?
<seb128> daily-live i386
<Kamion> odd, /casper/filesystem.kernel-386 does exist
<seb128> maybe my CD then, let me try again :)
<Kamion> no
<Kamion> I'll investigate - it's almost certainly due to the changes I made yesterday to try to make DVD images work properly
<seb128> ok
<seb128> let me know if I can be useful
<Kamion> you already have been by reporting it :)
<Kamion> I'll do a rebuild once I figure out a fix
<seb128> ok, thank you
<pitti> carlos: hm, yesterday evening's tarball was again from May 15 - it seems the export didn't work? or was it just too late again?
* sivang allocates the CDROM to the new linux LPAR from the AIX one.
<Riddell> pitti: does pmount work for floppy disks?
<Riddell> it doesn't want to work for me
<pitti> Riddell: it should
<pitti> Riddell: but I don't have any floppy to test it
<pitti> Riddell: pmount -d /dev/fd0 ?
<Riddell> keeps trying to access the disk but never manages to mount it
<pitti> oh, wait, do you have an fstab entry for fd0?
<pitti> (-d (debug mode) will tell me anyway)
<Riddell> I don't
<Riddell> http://kubuntu.pastebin.com/722210
<Riddell> '-t' 'udf'  looks wrong
<pitti> Riddell: so this mount command never finishes?
<Riddell> corret
<Riddell> yes
<pitti> Riddell: welll, it tries all file systems until one works
<pitti> Riddell: so it seems the kernel just hangs when trying to mount a vfat floppy as udf?
<pitti> Riddell: does 'pmount -t vfat /dev/fd0' work?
<pitti> Riddell: and if so, does 'PMOUNT_DEBUG=1 pmount-hal /dev/fd0' work?
<pitti> Riddell: (the latter will work if hal can successfully figure out the file system on the floppy; if not, pmount will try all of them again)
<Riddell> using -t vfat works fine
<Riddell> that second command fails http://kubuntu.pastebin.com/722215  
<Riddell> well, hangs trying to mount
<pitti> fstype: (null)
<pitti> Riddell: ^ so hal doesn't attempt to detect the floppy fs (or can't)
<Riddell> that seems to be the case
<pitti> Riddell: hmmm; I don't believe it's generally broken, from the bug reports I believe that it works in most cases
<pitti> Riddell: is there anything in dmesg when attmepting to mount as udf?
<Riddell> yes
<Riddell> [768109.983213]  attempt to access beyond end of device
<Riddell> [768109.983274]  fd0: rw=0, want=2884, limit=2880
<Riddell> [768109.983320]  UDF-fs: No VRS found
<pitti> Riddell: hm, that looks fine; the idea is that the mount should fail and it will try the next one
<pitti> Riddell: let's try something else: if you leave the floppy in the drive and do 'sudo /etc/dbus-1/event.d/20hal restart', can you please do the pmount-hal with debug again?
<pitti> Riddell: hal probes all the devices on startup, so I need to know whether it just doesn't or can't figure out the floppy fs
<Riddell> no difference http://kubuntu.pastebin.com/722225
<pitti> Riddell: too bad; if you want to debug this further, please do a ful hal debug output (wiki.ubuntu.com/DebuggingRemovableDevices, second part of the page)
<pitti> Riddell: but this seems nontrivial to fix :(
<Riddell> ok, thanks anyway
<pitti> wb ivoks 
<ivoks> hi
<ivoks> btw, g-c-m at people has one bug :)
<pitti> ivoks: mdz rejected the patch anyway :/
<ivoks> pitti: oh, to late for inclusion?
<pitti> yes
<ivoks> ah...
<ivoks> :((
<ivoks> pitti: funniest thing is that patch was available 5 days ago :)
<pitti> ivoks: same result, though (btw, the current patch exists only since yesterday)
<ivoks> i know
<ivoks> well, better to respect policy than introduce this, no mather how trivial/small it is
<ivoks> then we'll have to make something flashy for edgy :)
<siretart> jdong_: ping
<lifeless> infinity: around ?
<infinity> lifeless: Vaguely.  I'm in the middle of some sort of "long lunch" before I go back to work through a chunk of the night.
<infinity> lifeless: 'sup?
<lifeless> I think there is a possible upgrade bug from breezy with smbget and smbclient
<infinity> lifeless: ?
<lifeless> if you have breezy smbclient on your machine - 'smbclient', '3.0.14a-6ubuntu1'
* infinity grabs it.
<lifeless> and in upgrading to dapper smgbet 0.6-1 is unpacked before the smbclient package, or if you are just installing the one thing, then the replaces line in smbclient 3.0.22 wont take effect
<lifeless> and the files that moved from smbclient to smbget will make dpkg complain
<infinity> Err.
<infinity> Other way around, you mean, I assume.
<infinity> Looks like smbget went from smbget to smbclient.
<infinity> And smbclient properly replaces it.
<infinity> So I'm not sure what the bug is you're actually seeing.
<lifeless> infinity: well, I was seeing a report that the smbclient in breezy has files that are in smbget in dapper.
<infinity> No, it doesn't.
<infinity> (smbget in dapper should just be dropped anyway)
<lifeless> let me pull the thing apart, one sec.
<infinity> smbclient in dapper conflicts/replaces smbget.
<infinity> lifeless: Do you have a bug report for this?
<infinity> lifeless: With angry dpkg output and such?
<lifeless> infinity: I'm considering whether to file one, or whether to try and make this failure happen to generate output
<lifeless> I dont have a breezy chroot handy to test with is all
<infinity> lifeless: I don't see how "it" can happen at all, unless it's someone complaining that the packages conflict (which they clearly do).
<infinity> Conflicting packages isn't a bug, however.
<infinity> Every time a package gets phased out, mind you, people report a bug on the "OMG, apt is trying to remove a package" behaviour.
<lifeless> infinity: I think you are presuming smbclient is upgraded at the same time
<infinity> I'm presuming no such thing.
<infinity> It doesn't matter who is upgraded when, as soon as smbclient is upgraded to a recent version, it will force the removal of smbget.
<infinity> lifeless: Anyhow, if you can get a coherent testcase to show me the actual bug in question, holler back.
<lifeless> yes
<infinity> lifeless: But it all sounds pretty non-buggy to me.
<lifeless> I have to look at why this cropped up, my diagnostics are still, uhm, primitive.
* Kamion is also talking about this with lifeless in /msg; I think his script is buggy
<Kamion> infinity: lifeless is putting together code to automatically detect file overwrite errors
<infinity> Contents.gz (breezy) -> Contents.gz (dapper) -> overlaps -> check for conflicts or replaces, apply same heuristics dpkg would, profit?
<Kamion> diversions are the hard bit ...
<lifeless> infinity: diversions, version skew, arch specific issues, deep history to warn of problems during development rather than just HEAD to HEAD
<Kamion> lifeless: it's always best to verify quickly with dpkg -c before coming to the distro team, BTW. :)
<infinity> diversions are going to be a serious pain, yes.
<sivang> infinity , Kamion : http://muse.19inch.net/~sivan/error.png
<infinity> Since there are dozens of ways to divert things.
<lifeless> Kamion: indeed. still tracking
* sivang thanks the gods of vmware to have added screenshotting of a VM's display.
<Kamion> sivang: may well be the same issue. Do you have time to try a real daily install CD rather than the one I stripped down by hand
<Kamion> ?
<Kamion> hang on. are you telling me that vmware can emulate a pseries?
<sivang> Kamion: nono :)
<sivang> Kamion: I just run the HMC remote client from a vmware image of win32 box under a 64bit ubuntu breezy host :)
<Kamion> ah
<Kamion> "just"
<sivang> heh
<sivang> yeah
<sivang> Kamion: anyway, I will try the daily. can you toss me the link or should I look for it myself?
<Kamion> http://cdimage.ubuntu.com/daily/current/dapper-install-powerpc.iso
<Kamion> (from memory, but I type that a lot, so it should be right ...)
* sivang hugs Kamion 
<janimo> hmm is the an unsubscribe from bug button in LP?
<pitti> janimo: only if you are subscribed directly
<janimo> pitti, xubuntu-team is subscribed and I am a member
<pitti> janimo: if you are sub'ed through a team, you have to use the email interface
<janimo> admin if it helkps
<pitti> janimo: ' unsubscribe xubuntu-team'
<janimo> does LP have an email interface? cool :)
<janimo> I mean other than reply to coments in bugs
<pitti> janimo: https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc
<janimo> pitti: thanks
<hunger> Is there a bug statistics page in malone somewhere?
<lifeless> Kamio, infinity - thanks for the patience.
<lifeless> found the bug in my code.
<jdong|coreduo> Kamion: ping
<Hobbsee> where do specs get discussed/written?  launchpad.net/specs, in here, or somewhere totally different?
<Hobbsee> got a person asking in -motu
<Kamion> jdong|coreduo: hi
<janimo> we should be starting the meeting
<ssam> Hobbsee, https://launchpad.net/distros/ubuntu/+specs
<CarlFK> Kamion: today's dapper-server: "Unable to install the selected kernel - an error was returned while trying to install the kernel into the target system.  Kernel package: linux-386"   details: http://dev.personnelware.com/carl/temp/May17/a
<Kamion> I'd really much rather you defaulted to filing bugs rather than defaulting to asking me on IRC; half the time when you ask me it's 4am or something and obviously I'm not around
<CarlFK> ok - i figured the ability to get more info right away was worth the cost... but your call, so launchpad it is
<infinity> CarlFK: ubuntu-server and I are going to have some long talks on Monday anyway.
<infinity> CarlFK: I'll make sure that things like the default kernel and LAMP actually work right then.
<infinity> (And bug Kamion for help when I get stuck)
<Kamion> FWIW in this case it may well be triggered by your mirror timing out
<infinity> Kamion: Lucky you.
<Kamion> but there's probably another latent bug in there, so I'd like a bug report
<CarlFK> what package?
<Kamion> debian-installer
<ogra> janimo, how did you solve the ltsp probelm in xubuntu ? is that documentable in wikiform ? i have some requests of people who'd like to do a cusdtomized CD with an ltsp option
<janimo> ogra: did not solve it, there's a whishlist bug in LP to add the required components to the CD
<siretart> mvo: what does urllib have to do with xfce? or the build-in apt_pkg package retrierer?
<ogra> janimo, oh, ok
<jdong|coreduo> #bzr
<janimo> as last time I put the clinet-builder in istaller seed and it broke regular install
<jdong|coreduo> (sorry bout that)
<ogra> so it will be a new additional seed file i guess
<Kamion> jdong|coreduo: you pinged me?
<ogra> s/seed/preseed/
<janimo> ogra: Kamion said there's no need for a seed if there's only a handful of packages iirc
<ogra> ah
<janimo> oh, preseed, you lost me again. Yes I still have not mounted the ISO and played with preseed :)
<mvo> siretart: sorry, my description was not clear. gnome-vfs is not a option for gdebi because we don't want gnome dependencies in it (for xfce). but urllib has some disadvantages compared to apt_pkgs retriever support (i.e. easy resue of the progress classes)
<siretart> mvo: aah, now I see. okay, your call
* Loiosh woos.
<OculusAquilae> carlos: ping
<carlos> OculusAquilae: pong
<OculusAquilae> carlos: about package wlassistant. It has a .pot-file in source, but it doesn't get imported into Rosetta. Have you got an idea why?
<carlos> OculusAquilae: there is a set of imports I need to do manually, and that one is one of them
<carlos> you can see a complete list of missing templates at https://wiki.ubuntu.com/MissingPotFiles
<carlos> OculusAquilae: I will try to import that one today, I usually add some of them from time to time
<carlos> until the list is empty
<OculusAquilae> carlos: so the same problem with keep (on that list too)
<carlos> right
<carlos> no updates were done to those packages after the soyuz migration so we didn't get the translation resources, that's why I need to upload them by hand
<OculusAquilae> would be nice to get it importet the next days 
<OculusAquilae> carlos: is it possible that there is the same problem with kwin-style-crystal, although it's not on that list?
* carlos checks
<carlos> OculusAquilae: does it build a .pot file on build time?
<carlos> the source lacks it
<OculusAquilae> it uses cdbs I and I think it should do it automatically 
<carlos> OculusAquilae: but it was not rebuilt after we added the .pot autogeneration
<carlos> OculusAquilae: that's why it's not imported
<OculusAquilae> possible
<carlos> or at least I don't have it available
<carlos> OculusAquilae: either force a new build of it, or send me a valid .pot file
<OculusAquilae> I could send you one
<carlos> it lacks .po files on the package so I could just do the .pot file upload by hand
<carlos> OculusAquilae: please, do it
<iwj> rsync++
<ogra> paramiko-- ?
<pitti> carlos: hm, yesterday evening's tarball was again from May 15 - it seems the export didn't work? or was it just too late again?
<iwj> Kamion: http://www.chiark.greenend.org.uk/~ian/d/yaboot-test-ordinary.iso and http://www.chiark.greenend.org.uk/~ian/d/yaboot-test-weird.iso
<iwj> Kamion: ordinary is the control sample; weird is the one built with gcc-3.3.
<iwj> I've provided both in case I've messed it up somehow.  I'm pretty sure the build process etc. for both is identical.
<Kamion> Thanks. I need to go out and run a couple of errands now, but I'll drop those into all the relevant bug reports when I get back
<Kamion> much appreciated
<iwj> No problem.  I wanted to know more about this kind of stuff anyway.
<carlos> pitti: I need to move the language packs generation to production ASAP
<carlos> pitti: the mirror server is being busy
<pitti> carlos: shall I move the cronjob again?
<carlos> I guess that's the problem
<carlos> pitti: no, don't worry about it
<carlos> you will get the tarball tomorrow
<carlos> it will not be completely daily snapshots... but sort of
<carlos> I will add it as a priority for my work tomorrow
<carlos> that way I will be completely sure it's done
<ogra> doko is alive !
<hunger> Any idea how I can get /etc/login.defs CLOSE_SESSIONS back on dapper?
<hunger> Or what is the recommended way to use libpam-mount now that CLOSE_SESSIONS is marked obsolete?
<wasabi__> Heh nice. Somebody removed the arm patches from the Ubuntu glibc.
* wasabi__ readds.
<infinity> wasabi__: Not so much removed, as they're just slightly forked currently and need to achieve convergence post-dapper.
<AlinuxOS> pitti, hello dear 
<AlinuxOS> I saw your message... so we must request Georgian language autogeneration?
<pitti> AlinuxOS: no, as I said, I build all languages now
<jsgotangco> yay
<AlinuxOS> pitti, so where is the problem ? :)
<AlinuxOS> pitti, GNOME + KDE right ?
<AlinuxOS> int the same time
<pitti> yes
<AlinuxOS> pitti, great :)
<pitti> AlinuxOS: no problem :)
<AlinuxOS> good Idea one update peer week...
<AlinuxOS> really rocks!
<AlinuxOS> in this way people is more motivated to work
<AlinuxOS> :)
<AlinuxOS> (accept if there is no exams for uni)
<wasabi__> infinity: I'm just going to compile up the base system, and whatever packages I need, and drop them in a person binary-only (unless I change source) repository. At some future point it can be the basis for an official port.
<jsgotangco> good night
<mdke> mvo: is it correct that the sun-java5-plugin is only available on i386? will that change before release?
<mdke> (or anyone) ^^
<siretart> mdke: sun could perhaps..
<siretart> mdke: there is a java plugin for java4 though
<mdke> for amd/ppc?
<mdke> j2re1.4-mozilla-plugin ?
<Taya> hi, anyone can help me with adding some default language in kde(kubuntu)?
<Apachy> kubuntu-devel
<Apachy> it's ubuntu-devel
<Apachy> pls /join #kubuntu-devel
<Taya> ok thx
<Egnygnok> when I try to click the advanced button on the package manager, it says "missing command to run"...any suggestions?
<Egnygnok> oops...no support...sorry didn't see the topic
<iwj> mdz: ping (re mail about overlapping files in /usr/lib/{mozilla-,}firefox
* Kamion spots the problem with today's daily desktop CD builds - the filename changes ran into ISO9660 8.3 limits
<Kamion> fixing ...
<Loiosh> Heh!
<gurumeditationer> the ubuntu cds don't use joliet extensions?
<Kamion> gurumeditationer: they do, but that doesn't mean syslinux understands them
<Kamion> at that level it's using BIOS calls and isn't smart enough to do Joliet
<Kamion> (or Rock Ridge)
<gurumeditationer> ahh, you learn something every day :)
<sivang> Kamion: I had network issues at work today, will try boot he powerpc cd tomorrow
<Kamion> no worries
<jcole> hey dudes, with this announcement, is suns sdk goinf to be in the repos sometime soon? -> http://www.vnunet.com/vnunet/news/2156210/sun-makes-java-license-linux
<Burgwork> jcole, already is
<jcole> Burgwork: cool
<sivang> Kamion: I hope you don't mind me asking, what knowledge would I have to know in order to help out putting a quality working ubuntu version on the pSeires? Is it just kernel adjustment or maybe some apps would need porting? (or even base packages..)
* jcole replaces netinstall of blackdown to sun!
<jcole> Burgwork: all i can find is Blackdown Java 2 SDK
<jcole> Burgwork: nm, found it!
<netstar> "Garbabe Bin" lmfao?!?!?
<netstar> *Garbage
<netstar> That's really international
<netstar> Wastebasket worked fine
<netstar> Why on earth would you want to change it to something like that?
<Kamion> sivang: make sure installer works properly (may involve grubbing around in the partitioner), make sure CDs boot properly (may involve mkisofs and/or debian-cd hacking), make sure machine-specific functionality like power management works fine
<netstar> The former was intelligent, unique and internationally acceptable.  Garbage bin is stupid.  Sorry I feel really strongly about this.
<Kamion> sivang: shouldn't need to port applications, but the odd bit of supporting software might need adjustment; for example anything that talks to /dev/pmu would need porting
<desrt> they renamed trash?
<netstar> Yes!
<desrt> classic.
<netstar> To "Garbage Bin"
<netstar> heh it's terrible
<desrt> it's still called Trash here
<desrt> what LC_MESSAGES are you in?
<Kamion> netstar: stop ranting on IRC please; neither seb128 nor dholbach are here, and it'd be them I'd expect to look at this; file a bug
<netstar> Kamion: okay. Thanks for the direction.
<desrt> netstar; also -- you know how easy it is to rename it back to trash, right?
<mvo> Mithrandir: do you know what the practical use for ia32-sun-java5-bin is? i ponder if I should include it in gnome-app-install
<netstar> yes I do, but do other users?
<desrt> netstar; it's pretty obvious
<netstar> To a geek perhaps.
<desrt> file a bug.
<netstar> doing so
<Kamion> rebuilding today's daily-live CDs now
* Loiosh pets a daily cd.
<netstar> nautilus or nautilus-data?
<mvo> is anyone here familiar with the sun java packages ? I'm probably not up-to-date with the java world, but what is the difference between jre and web-start?
* mvo wants to ingetrate it into gnome-app-install
<mdke> mvo: I thought you were familiar with em :(
<mvo> mdke: I wish I where :/
<mvo> mdke: and doko is having fun in the sun :P
<mdke> oh shit, when is he back?
<mvo> mdke: I'll try to find out
* mvo bites the bullet and installs java to find out
* mvo is shocked to find out that its a 20mb package
<mdke> mvo: don't you guys have a wiki with people's vacation times and such?
<mvo> mdke: yes, a internal one
<mdke> mvo: so that will tell you when doko is back?
<Kamion> BenC: there was a rumour that there's a new kernel upload pending with a new ABI; is this true?
<mvo> mdke: he is back to work next week, but I will try to reach him in his vacation 
<BenC> Kamion: the rumors have substance, yes
<Loiosh> The gods of relaxtion forgive you.
<mdke> mvo: if you do, can you ask him if -plugin is going to be shipped for amd64 pls?
<BenC> Kamion: probably in just a few hours
<Kamion> BenC: ok, I'll try to be around to shunt it through and do d-i
<infinity> Oh good, an ABI bump will give me an excuse to fix one last bug in LRM before I call it done.
<Kamion> but if not, it'll have to be first thing tomorrow
<infinity> Though I won't be alive for 8 or 9 hours.
<iwj> Damn, this build is _still_ going.  I need to increase my ccache size I think.
<infinity> Kamion: Did you ever sit down with Ben and make sure the component/section/priority was correct for everything in linux-source so that NEW is a no-brainer like it is for LRM?
<Kamion> nope, afraid not
<Kamion> I think I'd rather do it first thing edgy now
<infinity> Damn.  Do you have a cheat sheet of override disparities?
<infinity> (If I end up doing the kernel NEW before you...)
<infinity> If you don' thave a cheat cheet, I'll just do it the hard way, no big deal.
<Kamion> rtc-modules-*, ufs-modules-*
<mdke> Riddell: thanks for those -docs packages. Do I need to update the repo?
<Kamion> infinity: those go to universe
<Kamion> infinity: everything else goes straight through
<infinity> Kamion: Ahh, no section breakage, just component?  That's easier to check.
<infinity> Kamion: Since component is mind-numbingly obvious from poking at the pool. :)
<Kamion> infinity: 'grep modules ~/ubuntu/indices/override.dapper.universe.debian-installer' gives you the list too
<infinity> Kamion: Cool.  Then if you don't get to it, I'll do it when I wake up so I can do LRM and -meta.  Thanks.
<Kamion> good stuff
<mvo> mdke: will do, thanks
<Kamion> ah good, that live CD fix worked
* infinity heads to bed.
<AlinuxOS> hello people, what's difference between ttf and otf font ?
<Lypsis> https://launchpad.net/distros/ubuntu/+source/orage/+bug/45289
<Ubugtu> Malone bug 45289 in orage "Date-Bug when creating a new appointment" [Normal,Unconfirmed]  
<mdke> Riddell: nm, LaserJock has done it
<omeg> Hey guys
<omeg> Is there any way to add named external links in the wiki?
<omeg> E.g. [www.google.com Google]  like in Wikipedia?
<mdke> omeg: yes, like that, except with an http:// in front of the url. For future questions like that, please see the wiki help or ask in #ubuntu
<Kamion> https://wiki.ubuntu.com/HelpOnLinking
<iwj> Kamion: oh, sorry for that freeze exception request mail with no Subject.
<Kamion> no problem
<wasabi__> http://www.zdnet.com.au/news/software/soa/Sun_flirts_with_Ubuntu/0,2000061733,39256815,00.htm
<wasabi__> congrats.
<pygi> wasabi_, :)
<AlinuxOS> maybe somone knows good GPL font editor ?
<pygi> hey pitti 
<pitti> hello again
<AlinuxOS> pitti, hello
<AlinuxOS> a question: is .vfb font extension valid for ubuntu ?
<pitti> hey pygi, hi AlinuxOS 
<AlinuxOS> ore .otf type.
<AlinuxOS> I'm still searching the best solution for GNOME interface fonts :)
<AlinuxOS> and still no idea for monospaced font :/
<AlinuxOS> http://bpg.sytes.net/BPG-InfoTech/sppro/bpg/publication_view.asp?InfoID=146406&iabspos=1&vjob=vcat,167&vtkid=
<AlinuxOS> BGP font autor has made another great font (IMHO)
<AlinuxOS> I'll show you screenshot.
<AlinuxOS> http://alinuxos.no-ip.org/BGP.jpg
<AlinuxOS> I like very much this font!
<AlinuxOS> :D
<AlinuxOS> pitti, and you ? :)
<pitti> brb, telephone
<_ion> A JPEG screenshot?
<AlinuxOS> pitti, ok
<AlinuxOS> _ion, nex time .png :)
<AlinuxOS> my fault :)
<pitti> hey ivoks 
<pitti> ivoks: welcome to the printing team :)
<ivoks> i camed to thank you :)
<ivoks> so.. thank you :)
<pitti> AlinuxOS: beautiful!
<AlinuxOS> pitti, ;)
<AlinuxOS> I'm going to see the rest of ChampionsLeague :D
<ivoks> ah... the game
<jcole> is java now going to be a dependency of ubuntu-desktop?
<ivoks> totally forgot about it :)
<jcole> "This unlocks a new opportunity for Java developers that has been very hard to reach into in the past. You can develop applications and target Ubuntu [Linux]  and know that Java is present on the machine," Phipps said
<AlinuxOS> pitti, I like this font too... but I'll wait Guiasher to decide.
<AlinuxOS> folks... good evening :) 
<ivoks> jcole: no
<ivoks> jcole: java is in multiverse
<ivoks> jcole: it isn't totally free... yet
<jcole> ivoks: so "knowing that Java is present on the machine" is marketing bs?
<ivoks> jcole: yes and no
<ivoks> jcole: you really can have sun java on ubuntu without any hassle
<ivoks> jcole: but it's not standard package
<jcole> ivoks: he needs to s/present/installable...
<ivoks> jcole: power of speach is to talk a lot and to say nothing... that's what Phipps was doing :)
<ivoks> anyway... the game
<ivoks> bye all
<neutrinomass> Hello. I wrote up the sync-mount spec yesterday. If anybody is interested in it, you can find it at http://wiki.ubuntu.com/SyncMount . Thanks.
<infinity> neutrinomass: removable devices aren't mounted "sync" on purpose.
<infinity> neutrinomass: One of the rationales for that is because sync can cause undue stress and wear on flash memory devices, seriously reducing their lifespan.
<neutrinomass> infinity: But they are mounted sync under windows, aren't they ?
<wasabi__> Your spec is also slightly flawed. You have to umount on windows too
<wasabi__> Nope.
<wasabi__> You have to "Safely Remove Devices"
<wasabi__> with that little icon in the sys tray.
<infinity> Yeah, windows has the "safely remove devices" thing.
<neutrinomass> wasabi_ : I've never had to unmount on Windows :S ... maybe I am wrong though ....
<wasabi__> Well, for USB devices you do, or you have a big chance of losing data.
<neutrinomass> wasabi_: On the other hand, I haven't used windows in qutie a while ...
<infinity> I know for a fact that it doesn't always sync on write, since I just unplugged my cell phone from a WinXP machine yesterday and noticed nothing had been written to it. :)
<wasabi__> I do think explorer causes a sync at the end of a large file operation on it's own, though.
<infinity> I'm not sure how or when it decides to flush.  It obviously does eventually.
<wasabi__> Yeah, and I've done that too, so I'm not certain what it's rules are.
<Loiosh> It does peridically through an operation and at the end
<infinity> But not reliably.  Hence the "safely remove devices" applet.
<wasabi__> I guess syncing at the end of a large file operation would be a nice thing for nautilus to do.
<wasabi__> Depending on the size, etc.
<wasabi__> Dunno. ;)
<neutrinomass> infinity: : flash devices have limited read/writes or a limited size of that that can be written?
<wasabi__> limited read/writes.
<wasabi__> Actually, limited writes.
<wasabi__> Reads are unlimited, usually.
<infinity> neutrinomass: All megnetic media has a limited write cycle.  Flash memory just happens to be more fragile generally.
<infinity> neutrinomass: Floppies are even worse, but no one uses them anymore... <shrug>
<wasabi__> vfat also happens to be terrible at it for flash memory.
* Loiosh uses floppies!!!
<wasabi__> having the fat in a static place on the device.
<omeg> Hey infinity
<neutrinomass> infinity: I use floppies :P !
<omeg> I finished that font.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/Usplash_Mono.bdf <-- I hope that it works, xmbdfed is a very strange program and I don't trust it at all.
<infinity> omeg: It may well be too late to sneak it past the Powers That Be, but I'm happy to look at it anyway.
<neutrinomass> infinity: Then again I guess you are right regarding the life span of flash devices. I guess I was wrong :(
<infinity> omeg: Yeah, every free font editor I've found is pretty crap. :/
<omeg> Well, if you consider it too late to "sneak it past", maybe I'll just toss it on the ubuntu-art mailing list and beg for inclusion.
<trappist> noatime helps extend write life by not beating on the same part of the medium for every write
<omeg> Since I feel it's kind of important. The current font really sucks.
<infinity> omeg: ubuntu-art isn't uploading usplash.
<wasabi__> trappist: on vfat you have the FAT table in the same spot anyways.
<omeg> Well, you're right.
<omeg> devel, then?
<wasabi__> trappist: So any file additions modify that one part of the disk, always.
<trappist> wasabi__: yeah no way around it for vfat I guess
<infinity> omeg: The bikeshedding going on there is entertaining, but won't sway me a whole bunch in the end.
<wasabi__> Yeah.
<neutrinomass> Pffft, so much for my first spec. Thanks though :)
<wasabi__> Ther'es just not much way around that one.
<infinity> omeg: The biggest issue, of course, is that switching from a proprotional font to a monospace font, while desireable, may have an odd effect on some strings.
<infinity> omeg: I'd have to do a fair bit of testing to make sure we don't overflow the stupid text box, etc.
<omeg> Whatever feedback you still have, I can still work on for now. I think it's already a whole lot better than the current font, though.
<infinity> omeg: (And don't take that as any sort of criticism.  I WANT a monospace font, I just don't know if I can get it in this late)
<omeg> It would be awesome if you could find the time for it before the repackaging of usplash. The usplash images are about to be voted for, probably will be in the next few days.
<infinity> Voting?
<infinity> I was just going to upload v550's image and be done with it. :)
<omeg> I'm not sure, actually.
<omeg> Nooo, it's awful.
<infinity> Name one that's less awful.
<infinity> They're all horrible dithered ickfests.
<infinity> But so was the breezy one.
<omeg> Any of mine: http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_2_8_SCALED.png - http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_1_8_SCALED.png - http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED.png
<omeg> Full list here: http://omega.avalanchestudios.net/personal/dropbox/usplash/new/
<omeg> You know, it really may sound like I'm passing the ubuntu-art team here, and I actually am right now, but I really do think that v550's splash screen is awful, man. I mean, not even the gradient is correctly vertically aligned.
<omeg> My rationale was to make a splash screen that was similar to the old one, but with new colors and better dithering and while creating compatibility with both the LegacyHuman theme and Tangerine.
<infinity> 0 is okay.  The version number on 1 is horrid IMO, and the "logo only" thing, while super cool if we were doing a minimal splash, looks a bit lop-sided when you add the progress bar and text box to it.
<omeg> I think that 2 is very cool, but you're right that it would look kind of off.
<infinity> But, 0 is basically what we shipped in breezy, with new colours, and less poorly dithered, I think. :)
<omeg> I really hope that my 0 will get some support.
<tseng> 0 is pretty good
<tseng> cleaner than breezy
<omeg> Well, v550's is the same as what you shipped in breezy, except with a gradient that's off and without glow. Man, I sound awful, preaching my own stuff like that
<omeg> Anyway, you should probably just pick one from the list at the wiki... https://wiki.ubuntu.com/Usplash/DapperPropositions
<infinity> Yeah, I already did.  It was down to one of v550s, one of yours (0), and someone else's.
<omeg> I'll add a sample bar plus text and "fail", "ok" colors to mine later tonight.
* infinity checks who the someone else was.
<infinity> Oh, kwwii.
<omeg> Seriously, though, I'll ask v550 to fix his gradient.
<Loiosh> wii!
<omeg> Well, I'm going to make that last mockup then.
<infinity> I liked kwwii's "no gradient" one... Mainly because "no gradient" means "less dithering" means "we win".
<infinity> His first one (with a much more subtle gradient than v550) is nice too.
<infinity> Nevermind that his shadows seem a bit off, I'm just talking about the logo and the brand name in this case.
<infinity> kwwii clearly has the skills to fix those images if someone asks him to.
<omeg> I kind of like shadows and gradients and glows. It's not that difficult to get the dithering right.
<_ion> I like newsuggestion_0 the most so far.
<infinity> omeg: On your scaled ones, did you hand-tweak them after squishing the aspect ratio?
<infinity> omeg: Or work at them in the "wrong" aspect ratio from the get-go?
<infinity> (Which would work well, I guess, if you have a video card that can do, say, 1280x800)
<_ion> More than d_final_v550_ubuntu.png
<infinity> omeg: Anyhow, if I were uploading tomorrow (and hey, maybe I am), I'd probably just use newsuggestion_0_8_SCALED.png
<infinity> omeg: If the art people and anyone who signs my paycheque get together and agree to override me (or someone else comes up with something better RIGHT NOW), then so be it.
<infinity> omeg: Can you do matching ones for {ed,k,x}ubuntu?
<infinity> omeg: And can you help the poor xubuntu folk make their logo look.. Nice? :/
<omeg> infinity: Sure, I'll do matching ones for all three others. Tonight if it's required.
<omeg> Also, yes, I did hand-tweak them; I simply made a 16 color version of the original 32-bit layered image and then manually tweaked the dithering a little bit in those few spots where it didn't fully work out.
<omeg> I think that the original usplash image was scaled from the already 16 color image.
<infinity> omeg: Well, it shows.  They look a lot less crap than the ones I scaled 6 months ago. :)
<omeg> Strangely, it still looked pretty good, though... I didn't even notice that it was until I opened up the original version, actually.
<infinity> omeg: (In my defense, I expected them to be replaces pretty quickly... The fact that we had NO artwork contributed until, oh, a week ago was unexpected)
<omeg> I'll be back in 10 mins, gonna watch the end of Arsenal - Barcelona match :)
<omeg> Haha, that's too bad
<omeg> Do you have access to any original version of the old usplash?
<infinity> Define "original"... You talking GIMP files, or just the un-scaled PNG?
* _ion is thankful to omeg for getting a good usplash artwork done. :-)
<omeg> Well, either.
<infinity> I have the latter.  Not the former.
<omeg> You're welcome, _ion :) I'm glad that there's still time for inclusion...
<omeg> I thought we were _way_ past UI freeze already.
<omeg> infinity: unscaled and in 32-bit?
<omeg> Just wondering.
<infinity> omeg: No, 4-bit.
<omeg> Ah, so. Well, I'll be back in a few. v550 is editing the page now so I'll add my last mockup then.
<infinity> omeg: http://cerberus.0c3.net/~adconrad/usplash-artwork.png
<infinity> omeg: That's what we shipped in breezy (which used a 640x480 framebuffer)... And that's what I mangled to turn into the 640x400 image we have in dapper right now. :)
<jcole> the lemerou non-dithered boot screens look very nice
<jcole> btw, is x86 the only arch with boot screens?
<_ion> jcole: They seem to be 640x480
<_ion> IMHO they look somehow cluttered.
<jcole> _ion: hmm... i know that the hppa arch has /dev/fb0 available at 1280x1024
<_ion> jcole: I meant the lemerou pictures. The images should be 640x400 AFAIK.
<jcole> _ion: ya, you're right... i think i like the way the logo is presented here -> http://ftpmerou.free.fr/ubuntu/usplash3.png
<jcole> _ion: err, here -> http://ftpmerou.free.fr/ubuntu/usplash2.png
<_ion> Of course everyone is entitled to her own opinion. My personal, humble opinion just happens to like the one omeg made more than that. :-)
<sladen> jcole: that image does look good;  is it actually 16 colours?
<infinity> jcole: We have usplash on all the arches we ship.
<infinity> sladen: You're kidding, right?
* infinity swears to revert any "video game menu" usplash uploads in a matter of seconds.
<HiddenWolf> infinity: but pink is pretty. ;)
<omeg> Barcelona won!
<omeg> I'm glad. Their coach is Frank Rijkaart, who is Dutch. :)
<netstar> The game was a shambles with that sending off.
<netstar> French and English arrogance all the way!
<omeg> Yeah, it was.
<omeg> By the way, I just added that last mock-up with text: http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR.png
<omeg> Nevermind the sentence... Dutch pangram. :P
<infinity> omeg: Is that representative of the pallette colours that are indexed for text in your splash?
<infinity> omeg: If so, I think you picked ones that are a bit too bright.
<sladen> omeg: I making all of the text colours the same as the "ok" might improve it.  currently it "glares"
<infinity> omeg: http://www.ubuntu.com/testing/dapperbeta#head-89fe9d664e80740b5bd35bf704bd2a022548be06
<sladen> I think ...
<infinity> omeg: The current text colour is much less harsh.
<infinity> omeg: Also, did you include a reddish colour for fail in the pallette?
<omeg> Hmm.... maybe.
<sladen> infinity: I was hoping the red text could be made the same as the normal text colour
<infinity> omeg: (I know there's contention about "fail" being scary, but for dapper, humour me and let's keep it scary)
<sladen> but yes, there needs be a palette entry
<omeg> Let me alter that one more time.
<omeg> Also, as it is right now, there's not a red color for "fail". I didn't think it would be necessary, so I decided that it's best off being spent on the logo so the dithering looks as good as it can be.
<sladen> omeg: nope, it's a required palette entry
<ogra> omeg, i really like the logo only ones with black background you did, nice work :)
<sladen> omeg: "part of the spec"
<sladen> ogra: I'm hoping they get dropped in for edgy :)
<ogra> dropped for ? or dropped into ?
<omeg> sladen: does the spec say it needs to be red? If so, I'll add it... but I'll have to redither it.
<Trewas> btw, not all monitors are created equal... I installed flight 6 onto a computer with an old 15" crt monitor and the usplash colors are so dark that reading the text is almost impossible, so erring on the side of "too bright" would be sometimes preferable...
<ogra> oh, i misread .... didnt swee the "in"
<ogra> *see
<sladen> omeg: the spec is that it needs to be a separate colour.
<ogra> sladen, whats wrong with uding them now ? 
<omeg> Ah, okay.
<ogra> *using
<omeg> So it doesn't matter whether it's red or not; it just needs to be a unique color.
<infinity> omeg: No, it doesn' thave to be red.  Making it one of the really bright colours from your dithered image would work.
<omeg> One that's not used in the dithering in the image.
<omeg> infinity: er...
<infinity> It could be reused, there's no reason why not.
<omeg> Ah
<infinity> It just needs to be in a specific palette location.
<omeg> Okay then. I personally think that the brightest color would work.
<omeg> Do I need to arrange the palette myself, or can I just mention which color entries are the right ones?
<infinity> Less effort for me if you fix the palette yourself.
<sladen> omeg: might be easiest if you do, since then you're in control
<infinity> #define BACKGROUND_COLOUR 0
<infinity> #define PROGRESSBAR_COLOUR 1
<infinity> #define PROGRESSBAR_BACKGROUND 4
<infinity> #define TEXT_BACKGROUND 0
<infinity> #define TEXT_FOREGROUND 2
<infinity> #define RED 13
<infinity> Those are the palette locations.
<sladen> omeg: the locations are on: https://wiki.ubuntu.com/USplashCustomizationHowto
<omeg> I'm not sure if I can do that with Photoshop (yes, I'm not using gimp, hehe)
<omeg> I'll look aroaund
<omeg> *around.
<sladen> omeg: ahhh, that's why the dithered is ordered and looks crap compared to GIMP's dithering :)
<omeg> Tsh. It's "error in diffusion" dithering at 72% with manual tuning and tweaking... :P
<infinity> sladen: The wiki seems wrong.  The source doesn't actually reference palette location 8 at all.
<omeg> infinity, would it be easy for you to fix? I can't seem to be able to easily alter palette locations in Photoshop.
<omeg> Maybe if I first save it with the pixels lined up in order at the top-left of the image...
<omeg> Nope, can't fool it.
<omeg> Ah, looks like it always sorts the palette depending on how often a color is used (black is always first, white last).
<sladen> can't you just copy and paste the the #NNNNNN colour values into each location
<omeg> Or maybe that's just luminance.
<sladen> omeg: grab a copy of the GIMP and you should be able to fix it up fairly easily
<omeg> It seems not.
<sladen> omeg: it's on the LiveCD if you're using Windows
<omeg> I guess I could do that if it's necessary. Depends on if infinity is able to do it easily himself, that could save some time (and him some sleep) :)
<infinity> omeg: I can do it here.
<infinity> omeg: The GIMP for Win32 works well enough, though.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR.png <-- do you think these colors are better? (refresh)
<infinity> omeg: And if you're going to do versions for the derivatives, would be nice for you to mangle them yourself.
<infinity> omeg: That looks less offensive, yeah.
<omeg> Hmm, yeah, you're right. It would be nice if you could do this one, though. It's 23:30 here in the Netherlands.
<infinity> omeg: Bah, it's 7:30am in Australia, and I haven't slept yet. :)
<omeg> :)
<sladen> omeg: looks better.  what about with the most saturated orange in the palette
<omeg> Okay, you win.
<sladen> omeg: eg, the one just below the half-way point in the logo
<infinity> omeg: Try with colour #9 for "fail"
<infinity> (Assuming Photoshop shows the palette 0-indexed...
<infinity> #ff9e4d
<infinity> That one.
<omeg> Trying.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<infinity> Lovely.
<omeg> Yeah, that does look more "correct" than the white one.
<omeg> Less threatening, though, but I don't think it should necessarily be threatening. :)
<infinity> It sticks out enough to take notice.
<infinity> It doesn't need to hit you over the head.
<omeg> Definitely looks better than my initial choice of colors.
<infinity> If I need a break from heavy thinking later today, I'll reindex and upload this, I think.
<omeg> Yeah, if you have a palette-fixed version, I guess you could just edit the wiki page. Maybe you should leave a note in the "commentary" field saying that you sorted the palette, and that thus other propositions in my folder aren't palette-fixed yet.
<sladen> omeg: btw, have you tried putting a 1-pixel border around the progress bar?
<sladen> omeg: to something to create a similar 'glow' effect
<infinity> Given that the progress bar location is defined in the code, not in the image, he'd have a tough time doing that. :)
<sladen> infinity: nope.  the progress-bar location is fixed in the code (for the time being), so it's easy just to paint around where the progress bar is going to be drawn
<sladen> (and if the location isn't correct in that image, it can grabbed from one of the vmware screenshots and pasted over
<infinity> Oh, true, it is fixed, just meant that without looking at the code, he wouldn't know where.
<omeg> Yeah, I thought that it would be defined in the code.
<infinity> Anyhow, easy enough to test how it would look.
<infinity> I, personally, think the flat progress bar looks good.
<infinity> I suspect a border will make it too busy.
<sladen> omeg: I tried grabbing one of the two 'shadow' colours and drawing a 1 pixel bar, is 'softens' 
<omeg> I think it looks okay. I'd rather have something more graphical. As it is right now, though, the emphasis lies on the logo, which is okay. The bar serves to accompany the text rather than the logo, and it looks just as plain as the text.
<sladen> it softens it slightly
<omeg> sladen: are you sure that where I placed the bar, it will actually be placed in the code?
<sladen> omeg: yup okay.  Thanks for all your hard work on those images btw!
<sladen> if it isn't then we'll end up with two visible bars, one that works and one that doesn't!  
<sladen> omeg: if you grab: http://www.ubuntu.com/include/testing/flight5/usplash-shut-down-movie.gif  which is a vmware capture and overlay it, you'll have the exact location
<sladen> omeg: and that'll also give you some sample text in the correct location/font
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<omeg> That's how it looks like with a glow.
<omeg> Let's see
<sladen> omeg: I think it.  so subtle you can hardly see it (which is what makes the main logo and glow look so good
<omeg> Ah, looks like mine was in the right position anyway. I used an osdir screenshot to get the position, so I guess they too used a direct screendump.
<omeg> Hmm
<omeg> I'm still doubting.
<omeg> It does give it a little something extra.
<infinity> It makes is a bit fuzzy, IMO...
* infinity shrugs.
<sladen> btw, are the progress bar colours staying chocolate, or are you going to do those in dapper-orange to?
<sladen> too?
<infinity> I'm not picky one way or the other, though.
<infinity> The background of the progress bar is nice in the dark colour.
<infinity> The top colour might be nice in a slightly lighter orange than FAIL.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<omeg> Hmm
<omeg> I'm making it just a little darker (the glow)
<omeg> Er, actually, that's not possible with this palette. :P
<omeg> Can't really make it larger or smaller. It's either this or no glow at all, I think.
<sladen> what about index #13 for the progress hilight (ffa75a)
<omeg> Would do almost just as well as ff9e4d.
<omeg> Would you like me to change it to ffa75a?
<sladen> dunno, that was just the one I tried it with and it didn't seem too offense
<sladen> less saturated than "fail" and not as bright-white as the first colour you tried
<infinity> Anyhow, I've finished my breakfast, and I've just about had my bikeshedding quota for the morning.
<sladen> :)
<lifeless> launchpad going down in ~10 for about 30
<lifeless> shipit upgrade
* sladen going down in ~10 for about 500
* omeg going down in ~5 for about 700
<infinity> That's a long nap..
<Keybuk> nap?
<omeg> Okay, some more minor changes, changed color of the highlight in the bar to ffa75a and did some more manual dithering.
<omeg> Dithering is pretty much perfect now as far as I'm concerned.
<wasabi> Hmm. That's odd.
<omeg> Nah, night :P
<wasabi> jhaltom@station-1:~$ ping station-2
<wasabi> ping: icmp open socket: Operation not permitted
<infinity> omeg: Current link with the new dithering?
<wasabi> Soebody enable SELinux while I had my head turned? heh
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<omeg> Probably won't even notice it, though.
<omeg> Just one or two pixels here and there.
<infinity> Just want to make sure I use the right one if I upload it while you're asleep. :)
#ubuntu-devel 2006-05-23
<omeg> Just found three pixels that I want gone! Again uploading yet another version.
<infinity> Go to bed. :)
<sladen> go for it!
<sladen> <whisper> infinity: whack it up </whisper>
<infinity> That sounds dirty.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<infinity> omeg: If it needs tweaking after I upload it, we can do that.  GO TO BED.  :)
<omeg> Just to be sure, I confirmed the links and removed the non _ALT image that was old.
<omeg> Okay, see you tomorrow then...
<omeg> :)
<omeg> Later
<sladen> r.
<Keybuk> that splash is pretty
<Keybuk> infinity: going to upload it?
<infinity> Keybuk: That's the plan, yes.  I'll do it after I do some more Real Work.
<infinity> Need to reindex it and fiddle with this other font I have lying here.
<Kamion> Keybuk: oh, good catch on openssh
<Kamion> Keybuk: I'll get that fixed before RC freeze now, thanks a lot
<Keybuk> Kamion: it's always that way isn't it... you stare and stare and can't figure it
<Burgwork> infinity, are you aware of this? https://wiki.ubuntu.com/Usplash/DapperPropositions
<Keybuk> and sometimes someone else goes "look, it's that!" :p
<infinity> Burgwork: Yes.
<Burgwork> the art work team has been doing a lot of bikesheddinga bout it, but it would look really bad if we ignored what they said
<infinity> Kamion: What was wrong with openssh?
<infinity> Burgwork: I'm not ignoring them, I'm just uploading something. :)
* ogra still prefers that one http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_newsuggestion_2_32.png
<Kamion> infinity: the init script's restart action did sshd -t to check the config before creating /var/run/sshd
<infinity> ogra: The "just a logo" ones don't look as good with a giant text box under them.
<infinity> ogra: The logo+brand ones look more balanced.
<ogra> infinity, yeah, i can imagine ... 
<infinity> Kamion: Whoops.
<ogra> but with a non bold font they could work
<sladen> ogra: you've got your own diveritive to play with!  :-P
<ogra> sladen, not really, i had no choice about the artwork this time
<infinity> ogra: Anyhow, I did ask him to make edu,ku,xu versions of the one we were just refining here.
<sladen> ogra: that one does look particular good for edubuntu though.  It's more interesting because it's not-just-a-circle
<Kamion> and of course one of the things sshd -t checks is that the privsep dir is there ...
<ogra> sladen, yep, but still, i'll have to use a variation of the ubuntu splash
<infinity> ogra: Well, this, in the right colours, with the right logo won't offend you, will it? http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<ogra> it basically looks the same as the old one 
<infinity> ogra: Cause I think, unless ubuntu-art decides there's something amazingly better than something else gets forced on me, we'll ship with something like this.
<infinity> ogra: Yeah, but better dithering, less crappy scaling, and shiny new colours. :)
<ogra> so we could even stay with that in edubuntu
<ogra> i like the current gold of the edubuntu one ...
<ogra> but less dithering would be nice
<infinity> And somethat that wasn't scaled by me in 5 seconds in a fit of rage at 3am.
<infinity> This guy actually hand-tweaked it after scaling it, so it looks less ass. :)
<ogra> yep, his work is awesome
<infinity> In fact, when the scaling is hand-tweaked, it even looks pretty good "squished" at the wrong aspect ratio.
<infinity> Which is good, cause then I don't think anyone will be begging us at the 0-hour to include 4x3 artwork and aspect ratio auto-selection in usplash.
<ogra> the idea with th elittle highlights is also nice http://www.bootsplash.org/test7a.png
<infinity> Yeah, kwwii's were at the top of my list too.
<infinity> The fact that omeg has actually talked to me about it was helpful, though.
<ogra> kwwii was in #edubuntu twice now and talked to me ...
<infinity> Not that I'm playing favourites or anything, but after hearing N people tell me that it's "purely an artwork thing, and has no technical relevance", I was near homicidal.
<ogra> but since we're bound to the ubuntu decision i dont really care as long as i dont end up with a pastel pink/yellow logo
<infinity> ogra: Yeah, I know he's talked to you and to Riddell... So he's not pure evil. :)
<infinity> Anyhow, I'll upload this today, see if it fans the flames a bit, and if a Power That Is decides to override my decision, so be it.
<infinity> I'm happy with this, though, and sick of the whole topic.
<ogra> that one really scares me (colorwise) https://wiki.ubuntu.com/Usplash/DapperPropositions?action=AttachFile&do=get&target=v550_eduratio.png
<infinity> Makes your logo look like a little naked dude swimming in a pool of urine.
<ogra> lol
<Keybuk> infinity: knowing edubuntu, it was the logo that weed in the pool
<infinity> Other than that, it's nice.
<Keybuk> that's why it's putting it's hand up
<infinity> I thought it was drowning.
<Keybuk> "Misssss, I neeeeed to goooo!  Oh, too late"
<ogra> it would fit the nicname of our wallpaper the community found
<infinity> And flailing.
<Kamion> infinity: (kwwii was at the UI sprint in London)
<Kamion> (seemed like a decent guy)
<infinity> Kamion: *nod*... I like his stuff too... But I also like omeg's, so what can I say? :)
<infinity> I'll upload one, and ubuntu-art can give me lashings after the fact.
<infinity> If dholbach's 3000 icon uploads are anything to go by, ubuntu-art is incapable of making a decision and having it stick.
<mdke> write "This is the final artwork" on it
<sladen> hahaha
<ogra> i actually prefer omeg's his samples on the wiki look most professional
<infinity> ogra: Well, I get the feeling that kwwii's were more mockups with an implied "I can polish these if you like them", while omeg tried to deliver polish on the first go.
<Keybuk> mdke: that would be almost worth it for a 24 joke <g>
<mdke> or "Please let me get back to samba"
<infinity> ogra: So comparing them might not be entirely fair.  (On the other hand, with a release around the corner, I'm happy with stuff that's polished NOW)
<ogra> infinity, might be, but the "interim" one from kwwii could at least have been slightly polished
<infinity> mdke: "This *is* the final artwork, because I have real bugs to fix and none of *you* have main upload rights, nyah nyah"?
<Keybuk> before everyone floods #launchpad ... it just broke
<mdke> infinity: would that fit? maybe in small letters
<ogra> Keybuk, nope
<mjg59_> infinity: Dude, upload early, break your mail feed
<infinity> Keybuk: They announced it earlier.  Down for ~30 mins.
<ogra> <lifeless> launchpad going down in ~10 minutes for 30 minutes
<Keybuk> infinity: shouldn't be down for another 10 mins or so
<Keybuk> it's very down now though :)
<infinity> 15:55 < lifeless> launchpad going down in ~10 minutes for 30 minutes
<infinity> It's 16:23 now.
<infinity> I'd say it's down late. :)
<Keybuk> heh, the message on the server was wrong then
<ogra> infinity, you missed the "15:56 * Keybuk (n=scott@quest.netsplit.com) has joined ..."
<ogra> ;)
<infinity> mdke: It would fit, but I'm not in the mood to antogonize anyone.  It's just cathartic to pretend I do.
<infinity> s/do/would/
<wasabi> Heh. Nice. texinfo fails to compile because of a missing /dev/fd0 node.
<Keybuk> wasabi: W.T.F.
<Keybuk> you sure it's not /dev/fd/0 ? :)
<wasabi> haha eitherway
<Keybuk> /dev/fd0 != /dev/fd/0
<wasabi> oh? hmm
<wasabi> hmm i knew that
<Keybuk> /dev/fd/0 is stdout ;P
<wasabi> Recompiling, will tell you in a sec.
<Keybuk> uh, stdin
<wasabi> Well, /dev/fd/ is quite present.
<Keybuk> yeah, should be a symlink to /proc/self/fd
<Kamion> is /proc mounted?
<wasabi> Yup.
<Kamion> is there a process running? :-)
<wasabi> I'm in qemu. Compiling for arm. ;)
<wasabi> If that gives you a hint. heh.
<Keybuk> could be that whatever is running texinfo's build actually closes stdin
<Keybuk> I've seen very very stupid programs that do that
<Keybuk> (yes, zope, I mean you)
<wasabi> Interesting and completely unrelated error that time.
<wasabi> It can't clean itself properly. =(
<TheMuso> c
<jcole> did http://ubuntuforums.org take a crap
<jcole> ah, thre it goes
* netjoined: irc.freenode.net -> zelazny.freenode.net
<Kamion> BenC: ping, kernel?
<Keybuk> what did you do to the kernel? :p
<Kamion> Keybuk: I'm more wondering when BenC is going to do his promised stuff to the kernel
<Kamion> so I know whether or not I can go to bed soon
<infinity> Kamion: Just go to bed.  I'm up for the long haul at this point.
<infinity> Kamion: 11:23 local now, way too late to go back on the whole "not sleeping" thing.
<tritium> I don't suppose any patches for iMac G5 thermal mgmt from 2.6.16 made it into the kernel, did they?
<Kamion> I still need to mail all those yaboot bugs with Ian's test images
<jcole> is there an easy way to recompile all kernels (686,k7,server,etc.) with restricted modules, kernel header, kernel source, etc. packages? all i want to do is add one little kernel option
<jcole> this is driving me nuts
<jcole> and if possible, add -CUSTOM (or whatever) to all related packages 
<Keybuk> no easy way, no
<Keybuk> you can do the linux-* using make-kpkg and linux-source-2.6.15
<Keybuk> you have to do restricted-modules separately though
<jcole> Keybuk: i need to supply a kernel that has the gawd forsaken REGPARM enabled and related packages... i created a custom kernel, but i keep running into stupid stuff like creating modules for vmwareplayer...
<jcole> Keybuk: there's got to be an easier way than all this mayhem
<jcole> Keybuk: it's just too much hassle to maintain
<Keybuk> it's not that tricky
<Keybuk> there's just a lot of it
<jcole> Keybuk: "end users don't want to recompile kernels" is what i'm being told so i'm trying to provide them
<jcole> Keybuk: you'd think there would be something on the wiki for this kind of thing... all i see is simple, make-kpkg, dpkg-buildpackage, make menuconfig, etc. type stuff
<Keybuk> that's what there is
<Keybuk> it really isn't that hard
<jcole> Keybuk: apt-get source linux-image-`uname -r` linux-restricted-modules-`uname -r`
<Keybuk> there's plenty of docs on the wiki
<Keybuk> https://wiki.ubuntu.com/KernelCompileHowto
<TheMuso> jcole: I have to rebuild my own kernels because I need to include a kernel screen reader. What I do, is apt-get source linux-source-2.6.15, patch in the screen reader, make a minor changelog entry, enough so that the newer kernels override my one so I don't miss any important updates, and rebuild. It builds all kernel packages.
<TheMuso> Mind you I don't have to build restricted-modules as they are fine for my needs, but anyway.
<jcole> TheMuso: ya, i need to provide that for end users
<jcole> TheMuso: do you create source and header packages
<TheMuso> jcole: As I said above, I use apt-get source and get the source package that creates all kernels, headers, and source package.
<TheMuso> And docs.
<jcole> Keybuk: i already create a custom kernel for myself with this REGPARM enabled... it's just that i've got people asking for other arches, for the server kernel, restricted modules for their wifi/etc. cards, yada yada
<infinity> jcole: dpkg-buildpackage in the linux-source-2.6.15 source tree (note: apt-get source linux-source-2.6.15, *not* apt-get install linux-source-2.6.15) builds everything.
<jcole> infinity: linux-source-2.6.15 will build all arches and variations (server,bigiron)?
<infinity> jcole: Yes.  We build all the kernels from one source package.
<infinity> jcole: It would be unmaintainable if we didn't.
<jcole> infinity: YOU are a life saver
<infinity> jcole: And linux-restricted-modules-2.6.15 builds all the LRM packages for all the kernels.
<jcole> infinity: i knew there had to be some easy way!
<Kamion> builds all subarches. To build all arches (i386, powerpc, amd64, etc.), you need to dpkg-buildpackage it once on each architecture you care about
<infinity> jcole: (You just need all the headers packages installed from your kernel build, and need to make sure the ABI in debian/rules matches the ABI of your current kernel build)
<Kamion> s/subarches/flavours/ I guess
<infinity> Kamion: Well, yeah, I was hoping he'd assume that anyway. :)
<jcole> Kamion: gotcha
* Keybuk is having fun with Malone
<Keybuk> there are 7,000 duplicate bugs :p
<jcole> infinity: can i append something to them so they don't conflict with the stock kernels?
<infinity> jcole: Not without mangling a fair number of files in debian/*
<infinity> jcole: You could force the ABI to something unusually high, though, I guess.
<jcole> infinity: for example, for tora with oracle support we have a tora-oracle
<infinity> jcole: Since we're at -22- right now, you could start your ABI count at -100- and assume we'll never get there.
<jcole> infinity: gotcha
<jcole> infinity: that's probably the easiest hack
<infinity> Easier than renaming all the packages, yes.
<infinity> Though I don't recall all the places where the ABI is referenced, it may not even be important that it's an integer, so you could replace it with a string...
<infinity> Having it be something you can increment is good, though, in case you need to roll new packages with a broken ABI.
<jcole> infinity: but if you guys come out with -23- and i'm already providing a -100- they will never upgrade, right?
<jcole> infinity: exactly
<infinity> Upgrades never happen automatically anyway, unless you have the metapackages from linux-meta installed.
<infinity> If you're using custom kernels, you obviously don't want our metapackages (which force our kernels down your throat)
<jcole> infinity: i could go with -122- -123- etc. i guess
<jcole> infinity: right
<infinity> You can, of course, grab the source for linux-meta as well, and adjust it for your ABI versions, and also provide metapackages to keep upgrades working with your stuff.
<jcole> infinity: i'll do that
<jcole> infinity: the kernel select in the debian installer selects the meta
<infinity> Yeah, as it should.
<infinity> We'd have no way to get security upgrades to users otherwise.
<infinity> Anyhow, one more day before freeze, so I'll cut this short and wish you luck.
<infinity> If you get stuck on something weird in our build system and want guidance later, I recommend holding off for a while, since we're all a bit busy right now.
<infinity> (My excuse is that I'm refuelling with some lunch at the moment)
<jcole> infinity: ok, thank you so much for the info, i leave you guys be
<bddebian> Heya folks
<nictuku> where does the i18n .mo files for the "serverguide" goes in the lang package? 
<Keybuk> weird
<Keybuk> I'm missing exactly 400 bugs
<bddebian> Missing?
<Keybuk> http://people.ubuntu.com/~scott/reports/main.html
<Keybuk> ^ vaguely accurate
<bddebian> Ah
<infinity> Keybuk: Now, can we get it sorted by severity? :)
<Keybuk> infinity: yeah, yeah, in a minute
<Keybuk> let me finish fiddling
<infinity> Keybuk: Bonus points for sorting stuff with an Ubuntu-6.06 milestone at the very top.
<infinity> Keybuk: And a pony.
<infinity> Uh oh.  Starting to fade and I still have 11 hours to go.
<infinity> This calls for drastic sugar intake.
<Keybuk> I find walking outside for a bit helps
<Keybuk> assuming it's sunny
* Keybuk gets his Malone scheme crystal ball out
<infinity> That was part of the plan, since all the sugar is out there <waves vaguely outside>
<Keybuk> anyone remember how to do inverse ordering in sql?
<infinity> ORDER BY field ASC
<infinity> or DESC
<infinity> I can never remember which is which way.
<Keybuk> ah yes
<Keybuk> http://people.ubuntu.com/~scott/reports/main.html
<Keybuk> ^ ok, that's sorted
<Keybuk> milestone isn't trivial :(
<bddebian> >8500 :-(
<infinity> We sure have developed a lot of bug reporting users over the last 6 months...
<Keybuk> the amazing thing is compare it to the universe number
<Keybuk> bddebian: it's only 6986
<Keybuk> it goes down a lot if you remember that Debian != Ubuntu :p
* bddebian takes the credit.. ;-P
<infinity> Keybuk: Uhh, dude.  Pulling direct from the DB means you're showing private bugs.
<infinity> Keybuk: You might want to exclude those.
<Keybuk> infinity: I think I'm excluding those, no?
<infinity> 35821 is private.
<infinity> Second critical bug on your list.
<Keybuk> hmm
<Keybuk> oh, duh, got the logic backwards
<infinity> (It's also a worthless bug report, but that's not the point)
<Keybuk> http://people.ubuntu.com/~scott/reports/notforwarded.html
<Keybuk> ^ exactly 6000
<Keybuk> freaky
<Keybuk> http://people.ubuntu.com/~scott/reports/unattached.html
<Keybuk> *giggle*
<Keybuk> look at #15368, about half way down the page
<infinity> Keybuk: Cute.
<infinity> Need some sort of html entity escaping in your output. :)
<Keybuk> bah, it's only a quick script
<infinity> :)
* Keybuk now has ice cream
<Keybuk> infinity: remind me about how the ship seed works with the Live CD ?
<infinity> Keybuk: They don't.
<Keybuk> I see, so we don't include it there?
<infinity> Keybuk: LiveCD is just desbootstrap+ubuntu-base+ubuntu-desktop+ubuntu-live
<infinity> ship is for the install CD.
<Keybuk> that's what I thought
<Keybuk> which makes it kinda pointless now, no?
<Keybuk> given Live is the installer
<Keybuk> infinity: did we decide on the new usplash artwork?
<Keybuk> I was just grabbing the source for something else, I can upload it now if it's picked
<Keybuk> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<Keybuk> ?
<infinity> yeah, but I was going to tweak it a bit first.
<Keybuk> what were you going to tweak?
<infinity> The palette, for one. :)
<infinity> And I was going to play with another font, but that's not important.
<infinity> If you want to test it locally and upload, be my guest.  I have a full plate anyway.
<Keybuk> heh
<Keybuk> I'm continually unsure about changing font at this time
<infinity> You'll definitely need to reorder the palette, though.
<Keybuk> because it'll mean we'll have to go through all the messages and cut them to fit again :p
<Keybuk> indeed
<infinity> Yeah, I think it's too late to change the font, I just wanted to play.
<infinity> Anyhow, I should do something about that fresh air and lunch I've been promising myself.
<infinity> Back in a while.
<Keybuk> okies
<JunlgeB> hey
<sneex> greetings
<sneex> Regarding "apt-cache policy apache2" -- is there a way to get at the config.layout and buildconf for that -- or is it included in the source download?  I ask because I wish to build Apache 2.2.2 but using Ubuntu's specifics.
<infinity> sneex: The apache2.2 packaging is hosted at svn.debian.org (which appears to be currently unreachable)... This also really isn't the best time or place to be asking.
<sneex> =( Is there a Ubuntu PPC chan?
* sneex goes looks
<sneex> OK, ty
<Keybuk> right, let's try it with the new font too
<Keybuk> as I feared, that font is wayyy too big
<Keybuk> oh, wow
<Keybuk> I managed to run a test usplash during cron.daily
<Keybuk> and got messages from cups restarting <g>
<infinity> haha.  Awesome.
<Keybuk> oh wow
<Keybuk> this package uses quilt to apply patches
<TheMuso> /c/
<Keybuk> Good morning, Germany!
<Treenaks> Germany? Where? :)
* mvo yawns
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight-7 released | LAST DAY FOR BUGS!
<Treenaks> ooh, it's going to be officially Bug Free tomorrow?
<Treenaks> nice
<Keybuk> officially distro team free tomorrow
<Keybuk> anybody caught working has to buy everyone cocktails at UFK
<pitti> Good morning
<pygi> mornin' pitti 
* pitti waves to Great Britain
* pitti hugs Keybuk 
<pitti> so, let's get out my arsenal for bug killing and let's go hunting once more
<Keybuk> pitti: I made a custom bug-report-o-matic :)
<Keybuk> http://people.ubuntu.com/~scott/reports/
<jsgotangco> hey that's neat
<pitti> Keybuk: the purpose of that is to sort out bugs that are forwarded upstream?
<Keybuk> pitti: that was mdz's original request, yes
<Keybuk> cf. notforwarded.html
<Keybuk> I made reports of just main bugs too
<Keybuk> as well as just restricted, etc.
<Burgundavia> Keybuk, you had better thwack the LP devs over the head with those reports, as they look useful for other people as well
* pitti would appreciate main/universe/forwarded as advanced search filters
<infinity> Keybuk: "Don't hard-code the palette index of the scrolling text."?
<infinity> Keybuk: So now it just picks a random colour and prays?
<Keybuk> heh
<Keybuk> I meant that instead of hiding an 8 somewhere in the code, there's a #define for it <g>
<Keybuk> OBVIOUSLY :D
<Keybuk> just because _you_ have sugar
<infinity> Oh, picky, picky. :)
<Keybuk> I was quite impressed with my palette switching skills
<Keybuk> I'm sure there was a more efficient way of doing it though :p
<infinity> Let me guess, you copy and pasted all the colors to a test file, then reordered the palette? :)
<infinity> s/test/text/
<Keybuk> I wrote down all the colours
<infinity> Right, same thing. :)
<Keybuk> then I changed them all to 00 thru ff in the order I wanted them to be in
<Keybuk> then I went rgb/indexed on it, so gimp sorted the palette
<Keybuk> then I changed them back
<infinity> Heh.
<infinity> I really wish it would just let you drag and drop them around to reorder them.
<Keybuk> aye, agree
<infinity> But that would be, y'know, easy.
<infinity> And easy isn't the GIMP's forte.
<Keybuk> or that someone had thought ahead and made the colour indexes exported variables in the artwork .so file
<Keybuk> so each image could have different ones :p
<infinity> Making an interface worse than Photoshop's was a challenge, but they overcome that challenge and prevailed!
<infinity> I wish the people who work on Inkscape would give them GIMP some love.
<infinity> Inkscape is a joy to work with.
<Keybuk> I want to know what's up with this version of the gimp, and all of it's docking insanity
<Keybuk> yeah, I like inkscape
<Keybuk> heh @ #38836
<Keybuk> bug 38836
<Ubugtu> Malone bug 38836 in sane-backends "my scanner don't work" [Normal,Unconfirmed]  http://launchpad.net/bugs/38836
<Keybuk> GREAT TITLE!
<kagou> hi
* mvo wants a pony
<infinity> My computer done gone broked itself.
<infinity> Keybuk: So, if you're doing the artwork uploads for usplash, does that mean you're happy to take ownership of the flaming bikeshed?
<infinity> Keybuk: Cause I'm happy to give it to you.
<Keybuk> infinity: it seems like it might be related to something I might want to be doing in edgy
<Keybuk> so I guess it might make some sense for me to be the one ignoring the bugs on it
<infinity> I doubt you'll be as good at ignoring them as I, but we all have to have at least one hero to worship, don't we.
<Mithrandir> Keybuk: whimy do you think https://launchpad.net/distros/ubuntu/+source/casper/+bug/41980 is a casper bug?
<Ubugtu> Malone bug 41980 in casper "Fail, hardware detection in Acer 351TEV" [Normal,Unconfirmed]  
<Keybuk> yeah, I'm constantly in awe at initramfs-tools
<Mithrandir> s/im//
<Keybuk> it's bug list is only surpassed by acpi-support
<infinity> Keybuk: The great thing about initramfs-tools is that about half those bugs are closed in the last 4 or 5 uploads, I just haven't closed them yet.
<Keybuk> Mithrandir: uh, well, it wasn't a bug against a meta package ;)
<Keybuk> I sometimes just bat bugs at a package I know someone who cares is subscribed to
<infinity> Keybuk: Bug tracking systems and I don't get along when I'm deep in hack mode.  I'll go back and clean up later tonight.
<Keybuk> that one looked like it was something in your "find the CD-ROM code" though
<Keybuk> infinity: I tend to do the same
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/kde_newsuggestion_0_32.png
<Mithrandir> Keybuk: uh, hardware detection is past initramfs, so no.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/kde_newsuggestion_0_8_SCALED_BAR.png
<Keybuk> Mithrandir: "Detecting CD-ROM" isn't though, no?
<infinity> omeg: Good morning, omeg. :)
<Keybuk> I thought that was the bit in the initramfs where it mounted it
<Keybuk> omeg: how are your palette munging skills? :p
<infinity> Keybuk: So, you want to co-ordinate with Riddell and ogra to get derivative splashes uploaded and complete the coup? :)
<Keybuk> omeg: oh, btw, I found out today that the "Pa's wijze" bit is a different colour to the "ok" :)
<Mithrandir> Keybuk: : tfheen@xoog /tmp/casper-1.53 > grep -ri "detecting cd-rom" .
<Mithrandir> : tfheen@xoog /tmp/casper-1.53 >
<Keybuk> heh
<infinity> omeg: Is there any hope of making the Xubuntu logo look reasonable with that limited resolution and palette, do you think?
<infinity> omeg: Or is it time for someone to help them rebrand to something with more basic shapes, on the double? :)
<Keybuk> infinity: co-ordinate?  what's that? :p
<infinity> Keybuk: It's when you say "I'm uploading your package now, you have 5 minutes to yell at me to stop."
<Keybuk> infinity: ah, I met Lamont too early
<Keybuk> I'm more "oh, was that your package I just uploaded?"
<omeg> infinity: I think it's possible. It'd be heavily anti-aliased, but I think you might be able to tell it's a mouse. I could just make the Xubuntu one a little bigger if necessary.
<Keybuk> oh, it's a mouse?!
<Keybuk> I thought it was a hamster
<infinity> omeg: Would be awesome if you could.
<omeg> It's a hamster?
<infinity> Keybuk: See xfce.org.  Their logo is a bit more legible.
<omeg> Keybuk: "Pa's wijze" has a different color? That's strange. Maybe I messed up with one of the darkening layers... let me check.
<Mithrandir> it's a catmousedog, I think.
<infinity> omeg: No, he means it has a different palette location assigned in usplash.
<Keybuk> 8 :)
<omeg> Oh, so we need to give "ok" a different color
<Keybuk> omeg: on the other splash, I gave "ok" that colour and the text itself a darker colour
<infinity> Keybuk: Except that I thought I jimmied it to make them both the same colour, because the differeing colours were irritating..
<infinity> Keybuk: Perhaps I only dreamed of doing so.
<Keybuk> co-incidentally, the colour that ended up at palette index 8 after I sorted them
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<omeg> Is this better?
<infinity> omeg: He already uploaded. :)
<omeg> Uploaded?
<infinity> Yeah.  usplash with your artwork.  Uploaded to the archive.
<infinity> Over half an hour ago now.
<omeg> Wow, really? Is that final?
<infinity> It is if no one complains. :)
<infinity> If you get us the other 3 derivatives and we shove those in, we may win due to sheer inertia.
* infinity coughs.
<omeg> Well, I hope they won't. Thing is, I think that people are still thinking that usplash is going to be voted for.
<Coyctecm> that's pretty nice :)
<Coyctecm> I liked that more colorfull splash too
<infinity> omeg: They can vote.  And if their vote goes drastically differently, and I don't think the winner was totally crackful, we can always replace stuff.
<omeg> Also, I'm very glad. That means a splash screen I made might be seen on millions of computers as they boot up.
<omeg> Well, I guess that for now I'll just make that Edubuntu logo as well.
<infinity> omeg: But Keybuk, sladen and I like your stuff.  That's 3 votes, all of whom are in the -core-dev keyring.  Not sure what that counts for, but it must count for something. :)
<Coyctecm> why that colorfull splash was changed? 
<omeg> Thanks :)
<ogra> if the edubuntu one gets nice, you have mine as well ;)
<infinity> omeg: Note, try to avoid the "naked dude in a pool of urine" colour scheme for edubuntu, and ogra will love you. :)
<ogra> haha
<Keybuk> getting the vote of the people who don't mind touching usplash is kinda useful :)
<infinity> Yeah, add mjg59, mdz, and Kamion and I think you'll have everyone who ever uploaded.
<infinity> Oh, and lamont.
<Keybuk> omeg: that KDE one has a border around the progress bar
<Keybuk> was that intentional?
<Keybuk> 1px of colour index #4
<infinity> Didn't we end up with a border on the Ubuntu one in the end?
<infinity> (A shadowy one)
<Keybuk> don't think there is one
<Keybuk> nope
<Keybuk> definitely not one on the ubuntu one
<infinity> Looks like there is on http://omega.avalanchestudios.net/personal/dropbox/usplash/new/newsuggestion_0_8_SCALED_BAR_ALT.png
<Keybuk> oh, maybe I wiped that out accidentally when I cut it out of the iamge
<omeg> I think that it might be an idea to wipe out the shadows from both of the bars. It looks good on the Ubuntu one, but I'm totally not sure about Kubuntu.
<infinity> Anyhow, I'm indifferent on the 1px "glow" on the bar.  omeg and sladen were +1, I was -1.
<omeg> If it doesn't look good on Kubuntu, we should probably remove it for consistency.
<infinity> Agreed.
<Keybuk> it's not that it looks good or bad
<infinity> And if he already cut it out of Ubuntu by accident, we win. :)
<Keybuk> I just noticed it while dicking about with the palette
<infinity> I prefer it without, TBH.
<infinity> The fuzz screws with my eyes and throws them out of focus.
<infinity> Which kinda hurts.
<infinity> I don't like pain.
<infinity> Much.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/tmp.png
* omeg fixes up glow
<Keybuk> omeg: it helps me if you do the images with the text and progress bar on them, so I allocate the palette entries properly
<Keybuk> cause me is thick
<infinity> As thick as a whale omelette?
<omeg> Yeah, I'll do that when finalizing the palette.
<Mithrandir> infinity: whales don't lay eggs.  Can't make whale omelette.
<pitti> infinity: btw, shall I prepare a tbird 1.5.0.2 changelog snippet with CVE numbers and short descriptions?
<infinity> pitti: I was JUST going to ask for a list of CVEs. :)
<infinity> pitti: Please do.  I'm trying to finalise the package right now.
* pitti pats his mind reading capability
<Burgundavia> infinity, does Charles Majola still work for Canonical?
<infinity> Burgundavia: No, he works for Impi Linux now.
<Keybuk> urgh
<Keybuk> I've uploaded something in kubuntu
* Keybuk has a quick wash
<Keybuk> ;)
<Burgundavia> infinity, ah, wondered
<infinity> Keybuk: I lost that purity point long ago.  You'll get over it.
<Keybuk> infinity: I'm surprised it's taken me this long
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_newsuggestion_0_32.png
<omeg> I'm late for work, so I'll fix this one up tonight.
<omeg> And then I'll also make a Xubuntu one if someone can tell me where their logo can be found, since I haven't been able to find it so far :P
<Keybuk> omeg: grab me on monday if nobody's around when you get back
<Keybuk> we're all on holiday over the weekend
<Keybuk> and tomorrow
<infinity> omeg: xubuntu.org
<infinity> omeg: It's not pretty, though.
<infinity> omeg: You may want to suggest a change. :)
<omeg> Ohh.. their top banner isn't set to background-repeat: no-repeat;
<omeg> It loops on my screen (1920x1200)
<Keybuk> heh
<Keybuk> http://people.ubuntu.com/~scott/reports/unpublished.html
<omeg> I do think the mouse is kinda cool.
<Keybuk> 182 bugs on source packages that "don't exist"
<omeg> It's just better off being a silhouette.
<Mithrandir> Keybuk: most of them are binary packages that exist, so I'd argue they are malone bugs.
<omeg> Anyway, time to go to work. Long train journey ahead of me. Maybe I'll Be Bold (TM) and install an IRC client on my OSX computer at work. Anybody know a good OSX IRC client?
<Keybuk> Mithrandir: they're all because of that Malone bug
<Keybuk> which may actually be a publisher bug
<pitti> infinity: http://paste.ubuntu-nl.org/14202
<omeg> Ah well, I gotta get going now ;)
<omeg> Later
<Keybuk> right
<Keybuk> I have actually gone through the bugs of every package I have ever touched now
<infinity> pitti: Many thanks.
<pitti> you're welcome
<infinity> Now, I wonder if this thing still builds...
<pitti> infinity: good luck! (although I never had many problems with the 1.0.x packages, they are packaged quite nicely)
<infinity> Compared to the other mozilla products?  Yeah.
<infinity> But that's not saying much. :)
<pitti> I meant the Debian bits
<infinity> asac's had a lot of help recently making the 1.5 packaging more sane (from me and from another guy whose name escapes me), but I'm not merging those changes, since they're a bit drastic.
<infinity> So, I get to merge the Debian changes we need into our old build system and cross my fingers.
<pitti> like renaming the source package and such?
<infinity> \o/
<infinity> No, like completely overhauling the debhelper usage to be sane.
<infinity> The rename is easy to work around.
* Keybuk eyes all the xubuntu things sitting in anastacia
<Keybuk> really should get around to those at some point
* infinity fires up a build and prays.
<Keybuk> infinity: why is openoffice eternally in outdate?
<infinity> Keybuk: Because it's sufferring from the world's most bizarre FTBFS.
<infinity> Keybuk: If we can't sort it soon, I'll upload hand-built binaries. :/
<Keybuk> why does this not surprise me?
<Keybuk> it's openoffice!
<pitti> Keybuk: can you please promote ttf-bpg-georgian-fonts to main? I'll add a l-support-ka dependency to it; I reviewed the package, it's just a harmless and tested font
<infinity> pitti: I made a PHP 5.1.2 upload to polish off a couple of dapper-blocking bugs under the assumption that I may not have time for 5.1.4, so don't be surprised if I end up having to backport security patches to 5.1.2 instead.  <shrug>
<Keybuk> . o O { man, chinstrap is slow ... all those launchpad guys converting their archives, I guess }
<infinity> pitti: But if I can convince mdz to let me slip 5.1.4 in next week (or I can find the time tonight), I'll do it.
<pitti> infinity: ok, sounds sane
<infinity> pitti: But, given upstream's love of breaking things on new versions, and the fact that we know 5.1.2 works, I'm in no rush to prioritise it over anything else.
<pitti> infinity: if we upload a patched 5.1.2 to dapper, that's fine for me
<Keybuk> pitti: done
<infinity> pitti: Yeah.  We'll see how it pans out.
<pitti> infinity: that should still be possible next week, since we do the patches to current stables as well
<pitti> Keybuk: thank you
<Keybuk> anyone else need anything promoting or demoting while I'm logged in?
<infinity> pitti: There's exactly one change in 5.1.4 that I would like to see in 5.1.2 (other than the security fixes, of course), and I can backport that if the upstream bump looks too hairy.
<Keybuk> Riddell: ping?
<sivang> morning all
<Keybuk> infinity: who runs xubuntu?
<infinity> Keybuk: janimo and... Some other poeple.
* pitti points Keybuk to janimo
<infinity> people, too.
<Keybuk> ah, that's it; knew it began with j :)
<infinity> Right, I think I'll wander off while this tbird build warms my ccache...
<infinity> Must have flushed the poor thing with all the OpenOffice testing.
<desrt> keybuk++
<Keybuk> desrt: what did I do?
<desrt> Something Good
* desrt off to bed now -- nite.
<pitti> Keybuk: can you please sync myspell-sk from Debian?
<infinity> Clearly, you're just an all-round stand-up guy.
<pitti> Keybuk: I'll review it and if it's sane, add it to language-support-sk
<desrt> actually
<pitti> Keybuk: oops, ignore me please; it's not yet in Debian
<desrt> is sebastien, jeff, daniel or mark here?
<pitti> desrt: seb128 usually gets up later
<pitti> dholbach too
<desrt> bah.
<Keybuk> pitti: was about to say :p
<Keybuk> desrt: which daniel?
<desrt> german one :)
<infinity> Do we have employees that aren't German?
<Keybuk> ogra: WAKEY WAKEY!
<Keybuk> infinity: nein
<desrt> dholbach uploaded some icon theme badness
* ogra yawns
<Keybuk> ogra: any particular reason that schoolbell isn't supported anymore?
<sivang> morning ogra :)
* pitti waves to ogra and gives him a strong tea
<desrt> pitti; hmm.  that's nicer than what i was about to do
<ogra> Keybuk, dunno, doesnt schooltool depent on it anymore ? 
<Keybuk> no, apparently not
<ogra> Keybuk, i never explicitly seeded it
<mvo> ogra: how, you are up early!
<Keybuk> schooltool depends on python2.4-schooltool which depends on python2.4-schoolbell
<ogra> mvo, *still* up :)
<mvo> *ick*
<jsgotangco> doh
<ogra> Keybuk, yep, thats fine
<Keybuk> ogra: should I add it just to edubuntu?
<Keybuk> server?
<ogra> its not needed
<Keybuk> supported?
* desrt falls into bed
<ogra> schooltool brings all needed deps
<pitti> desrt: did your idea involve a bucket and cold dihydrogenoxide?
<Keybuk> ogra: except the schoolbell package?
<ogra> hmm, well, why not, add it to supported
<ogra> it works fine without schoolell
<ogra> *schoolbell
<ogra> we never used it in edubuntu
<Keybuk> yeah, just tidying up anastacia :)
<ogra> yup :)
<infinity> Gah, when did Debian start serving Packages diffs?
<Keybuk> infinity: a while back, apparently
* infinity is not used to "apt-get update" downloading 148 files...
<Keybuk> you've stopped paying attention to Debian too, huh? :p
<infinity> No, I just don't update my sid chroots that often.
<Keybuk> I don't even have those
<sivang> Keybuk: so how do you do debian work? :)
<Keybuk> sivang: what debian work?
* pitti uses a sid pbuilder
<pitti> and I still regret that Debian mandates binary uploads...
* ajmitch still has a sid chroot or two that gets used every few days/weeks
<sivang> pitti: so you have to upload both binary and source?
<sivang> Keybuk: :)
<Keybuk> sivang: yeah, to "prove" you've actually tested it
<pitti> sivang: yes
<pitti> sivang: the bad side is that most packages are uploaded with i386 binaries, and god knows how many of them are not built in a clean sid pbuilder :/
<sivang> pitti: oh bad :-/
* Keybuk makes sure he doesn't push the edubuntu seed over top of the ubuntu seed this time
<pitti> sivang: so the majority of Debian users uses packages which have never seen the rigid process of a clean buildd build
<sivang> pitti: I see, given that, ubuntu packages are basically much higher quality then?
<Keybuk> pitti: or, looked at another way, all Ubuntu users use packages that the uploaders never bothered to test first <g>
<sivang> hehe
* pitti assumes irony tags around Keybuk's comment :)
<infinity> Hey, I tested an upload once.
* sivang tests every upload he has done so far.
<Keybuk> infinity: lies
<sivang> s/tests/tesded/
<infinity> It was back in aught five.
<infinity> I remember it clearly.
<sivang> I can actually imagine uploading something without testing it :-)
<sivang> infinity: heh
<sivang> s/can/can't/ 
<infinity> Murphy always gets you anyway.  It's the one upload in 10 where I DON'T test, just cowboy a fix and say "yeah, that's going to work" that always ends up being FTBFS.
<Keybuk> \ [===============                                            ]  fetch phase 1/4
<sivang> (fruedian thinking ;)
<Keybuk> TODAY BZR, TODAY!
<sivang> Keybuk: hehe, aren't you using knits? 
<Keybuk> didn't we write bzr because baz was slow?
<ogra> the day is young :)
<Keybuk> sivang: dunno, this is the seeds
<Keybuk> I don't think we've made knitwear out of them yet
<pitti> Keybuk: however, I must admit that knit pushing is much faster than weave pushing
<sivang> Keybuk: ah
* pitti converted all his branches to knits for that
<Keybuk> infinity: or does something hideous, like that kino upload I did that you had to correct repeatedly
<Keybuk> "oh, this is easy ... *BLAM*"
<infinity> Keybuk: Yeah, I was a good boy and didn't mention it once. :)
<infinity> Keybuk: Have you seen the icky hack to fix it?
<Keybuk> infinity: you probably would have mentioned it, if you didn't muck up your own fix upload :p
<infinity> Keybuk: dpkg really, really doesn't like directories turning into conffiles.
<Keybuk> the funny thing is, I've been bitten by that dh_install bug at least two or three times now
<infinity> It's documented behaviour, not a bug. :)
<infinity> So says Joey and the manpage.
<Keybuk> it's a bug
<infinity> It's an unfixable bug at this point, of course, cause you can't go and change how it works or the world may end.
<infinity> Standard tools are a pain that way.
<Keybuk> this is me you're talking about ;)
<Keybuk> that's what dh_compat is for :)
<Keybuk> compat 6? now it works *this* way
<Mithrandir> Keybuk: what dh_install behaviour?
<infinity> Like the "update-rc.d defaults" bug that will never ever be fixed, cause it would blow up every postinst with an init script.
<infinity> \o/
<lifeless> dh_compat 5.1keybuk
<Keybuk> Mithrandir: you can't rename a file
<infinity> LIMITATIONS
<infinity>        dh_install cannot rename files or directories, it can only install them with the names
<infinity>        they already have into wherever you want in the package build tree.
<infinity> That one ^^^
<Keybuk> ie. debian/kino.rules etc/udev/rules.d/45-kino.rules
<Keybuk> does BAD THINGS
<Keybuk>  Source and binary demotions to universe 
<Keybuk>  --------------------------------------- 
<Keybuk>  o ttf-bpg-georgian-fonts: ttf-bpg-georgian-fonts
* Keybuk tsks at pitti
<Keybuk> NOT FAST ENOUGH
* pitti can't help LP having a long turnaround
<infinity> Bah, dapper doesn't need 'em.
<Keybuk> infinity: php5-mysqli
<infinity> Just remove them from the archive and let him start over.
<infinity> Keybuk: re-run germinate.
<infinity> Keybuk: It's caught by %php5
<Keybuk> dunno how often Kamion's cron runs that
<infinity> Every 30 mins?
<infinity> I don't recall.
<Keybuk> something like that
<pitti> Keybuk: ok, I reviewed, tested (!!) and uploaded myspell-sk; can you please NEW it to main once it's there?
<Keybuk> yeah
<Keybuk> I'm about to embark on NEW
<Keybuk> a few SONAME changes
<Keybuk> oh, wow, did somebody finally approve or reject the fluendo plugin?
<infinity> SONAME changes this close to release?
<infinity> Someone's got big balls.
<infinity> Or they were from the backlog of syncs. :/
<Keybuk> syncs I suspect
<pitti> Keybuk: ispell-sk will follow soon, too
<infinity> Oh, ffs, thunderbird... BUILD FASTER.
<infinity> I gave you a fast CPU.  I gave you 2GB of RAM.  WHAT MORE DO YOU WANT?
<lifeless> *YOUR SOLE*
<Keybuk> a pony
<Mithrandir> infinity: ccache.
<infinity> Mithrandir: Well, yeah, it's priming ccache right now. :/
<infinity> Mithrandir: Which is, no doubt, slowing it down.
<infinity> Mithrandir: But I'm pretty sure I'll need another build in an hour, so hopefully it'll be less grumpy then.
<Keybuk> oh, that's kinda neat
<Mithrandir> infinity: yeah, should be.
<Keybuk> this package build-deps on the -dev
<Keybuk> but not binary deps on the lib
<infinity> lifeless: It wants my shoes?
<Keybuk> I like soname changes like that
<lifeless> infinity: yes
<Mithrandir> Keybuk: not versioned build-dep on the -dev, even?
<Keybuk> mith: not even
<Mithrandir> eww
<Keybuk> infinity: why hasn't kolab-cyrus-admin built on !i386
<Keybuk> that's a bit kooky
<infinity>   There is no current release for this source package in Ubuntu  
<infinity> Come again?
<Keybuk> https://launchpad.net/distros/ubuntu/+source/kolab-cyrus-imapd
<Keybuk> the kolab-cyrus-admin binary on built on i386
<infinity> Because it's arch:all.
<Keybuk> oh, yeah
<Keybuk>          | * kolab-cyrus-admin/2.2.12-7/i386 Component: main Section: mail Priority: EXTRA
<Keybuk> why does that say /i386 then? :p
<Keybuk> is it just being annoying
<dholbach> good morning
* dholbach hugs Keybuk
* Keybuk hugs dholbach
<infinity> Keybuk: Because the queue view just gives you the arch of the .changes, cause it's dumb.
<infinity> Keybuk: I'm sure Kamion's probably already filed a bug about it, but if not, go nuts.
<infinity> Keybuk: cprov and I will be spending much quality time together in Paris, so I'm hoping we can kill some of these irritants.
<infinity> Also, why did Tbird just FTBFS?  *cry*
<Keybuk> because you were watching it
<infinity> A watched build never succeeds?
<Keybuk> exactly
<infinity> I've not heard that one before.
<pitti> hi ivoks 
<pitti> ivoks: I'm just building a new ffox-locales with your croatian xpi
<ivoks> ok, thanks :)
<Keybuk>          | * libgarlic3.15p/3.15p-10/i386 Component: main Section: devel Priority: OPTIONAL
<Keybuk> oh, wow
<Keybuk> these library names from the GNOME camp just get better and better
<ivoks> um...
<ivoks> xfsprogs have problems
<pitti> shawarma: hi! I just replied to bug 8125, thanks for working on this ancient one!
<Ubugtu> Malone bug 8125 in gnome-cups-manager "username for smb printer is not  shown on printer properties" [Unknown,Unconfirmed]  http://launchpad.net/bugs/8125
<pitti> ivoks: works just fine here, will upload now. thank you!
<ivoks> pitti: no, thank you :)
<TheMuso> dholbach: ping
<dholbach> TheMuso: pong
<dholbach> heya seb128!
<seb128> hi dholbach
<TheMuso> dholbach: I have been thinking about the BrlTTY turned off by default stuff, and have it turned on for the live CD. I know it may be a little late, but I was thinking perhaps a simple /etc/default/brltty file could be checked for a variable to start brltty or not, and the /etc/default/brltty file could easiy be written if accessibility is enabled on the live CD gfxboot menu.
<shawarma> pitti: Er... What's mysterious about the patch?
<dholbach> TheMuso: why turned on with livecd?
<pitti> shawarma: it looks just a bit weird to completely remove the password field contents
<shawarma> pitti: the only mysterious thing about it is how that weird line ever was allowed into the code and why noone has removed it yet. :-)
<shawarma> pitti: Well, actually it's not
<pitti> shawarma: heh :) as I said, I didn't yet look at it, but I will today
<TheMuso> I also looked into that conffile bug for brltty, and also looked at dbus, after what you said in that email to ubuntu-accessibility@. I think I know what you are referring to as to what needs to be used for brltty.
<shawarma> pitti: gnome-cups-manager requests the deviceURI from cups, which only has e.g. smb://host/printer .
<TheMuso> dholbach: To quote your email: * brltty is currently turned off. We have to think of a clever way to enable it
<TheMuso> (persistently?) if somebody chooses to do this in the gfxboot menu
<shawarma> pitti: It never returns the password, so there's nothing sensible to put into the password field.
<dholbach> TheMuso: ah yeah
<shawarma> pitti: The best thing would be a descriptive text explaining that you should only enter anything if you want to change it, but as we're in string freeze..
<dholbach> pitti: I do the asterisk merge (cve-2006-1827) is handled that way
<ivoks> um,,, gparted is broken :/
<pitti> dholbach: parse error :) but if you want to merge asterisk, great :)
<shawarma> pitti: Otherwise, we could add a button that says: "Change username and password" which would show a dialog. That way noone accidentally changes anything.
<TheMuso> dholbach: But since we are so close to freeze, and we haven't had users demand it, I am wondering if we should just wait till edgy is open.
<dholbach> pitti: hm?
<Keybuk> dholbach: did you ever decide what to do about brltty-flite, brltty-x11 and flite?
<TheMuso> But that conf file bug is something I think we need to sort, although other than dist-upgrading from breezy, I don't know how else to reproduce it.
<dholbach> Keybuk: i asked the a11y folks
<TheMuso> I don't think they need to be worried about atm, unless something from main pulls them in when they shouldn't be.
<dholbach> pitti: 1.2.7.1 fixes cve-2006-1827
<Keybuk> dholbach: did they answer?
<TheMuso> Keybuk: Someone stated the usefulness of one of them, but it wasn't implicitly asked for I don't think.
<dholbach> Keybuk: Samuel Thibault indicated that brltty-x11 was useful
<Mithrandir> seb128,dholbach: can either of you change the error text when gnome-keyboard-properties fails to enable a keyboard layout for me?  I want it to ask for the output of setxkbmap -print too.
<dholbach> Keybuk: that's the best i could find out
<seb128> Mithrandir: no
<Mithrandir> seb128: since it's locallised?
<Mithrandir> localised, even
<seb128> Mithrandir: I'm looking to be sure, but yep
<Keybuk> ogra: heh, have you been at Mark's photo collection?
<shawarma> pitti: There. i just posted the cupsys patch. Have fun. :-D
<seb128> I don't know if they did that smartly enough to no localize the command though
<ogra> Keybuk, ?
<ogra> ah, heh
<Mithrandir> seb128: if so, it'd be nice to have, but if not, I can always ask submitters for it.
<ogra> yes, he snet them to me 
<pitti> shawarma: thanks!
<ogra> *sent
* pitti goes off for breakfast before continuing the bug rave
<Keybuk> ogra: screensaver-default-images
<ogra> yup
<seb128> Mithrandir: they have been smart, I'll change that ;)
<ogra> Keybuk, feel free to add intresting photos :)
<seb128> Mithrandir: just one extra line with "setxkbmap -print" then?
<Keybuk> dholbach: ok, I'll seed the x11 one, and drop the flite things
<Mithrandir> seb128: excellent.  Yes, please.  Just an extra line.
<dholbach> Keybuk: thanks a lot.
<Keybuk> lifeless: if I bzr upgrade a local copy to knit, what happens if I try and sftp push into a copy that's not knit?
<seb128> Mithrandir: np. Hum, I've a question maybe for you ... do you know what is the best way to get the user locale? I want it for the localized epiphany startup page
<seb128> Mithrandir: setlocale (LC_ALL, NULL)? of better to g_getenv (LANGUAGE) or something like that?
<lifeless> Keybuk: it does a full rediff of the inventory while pushing to the weave.
<lifeless> Keybuk: aka. SLOW.
<Keybuk> lifeless: so not a good idea then
<lifeless> Keybuk: so do a 'bzr upgrade sftp://foo' first
<Keybuk> lifeless: won't that be slow too? :p
<lifeless> Keybuk: you only pay the cost once :)
<lifeless> Keybuk: rather than on every push
<Keybuk> lifeless: I just mean wouldn't it be faster just to do the bzr upgrade in the directory on chinstrap? :)
<lifeless> oh sure
<lifeless> you didn't say you had ssh access to the branch ;)
<Keybuk> ogra: hmm, the names of these aren't very good
<Keybuk> ogra: and why does it depend on xscreensaver-data ?  shouldn't it be the other way around?
<lifeless> though, with your access to chinstrap, and chinstraps CPU, doing it over sftp might be faster ;)
<Tetralet> pitti: ping
<seb128> Mithrandir: hum in fact no, adding a command would break the translations :/
<Keybuk> ./usr/share/backgrounds/DSC_0002-TIF.jpg
<Keybuk> is a weeeee bit icky
<ogra> Keybuk, space1-4 ?
<lifeless> thats horrible
<Keybuk> ogra: something like that would be preferable
<ogra> ok
<Keybuk> or just name them
<caleb-> pitti: https://launchpad.net/bugs/43991 # language-pack-kde-zh-base_6.06+20060511.tar.gz has not zh_TW entry.desktop
<Ubugtu> Malone bug 43991 in language-pack-kde-zh-base "Can't select Traditional Chinese" [Normal,Confirmed]  
<ogra> it depends on xscreensaver-data because xscreensaver-data has the interpreter (xscreensaver-getimage/xscreensaver-gl-helper) that uses these pics
<caleb-> pitti: upstream has those files for Taiwan, but tarball of Ubuntu has only zh_CN
<Keybuk> ogra: right, but wouldn't that mean that xscreensaver-data should depend on these to get the images it needs to display?
<Keybuk> the package just contains the images, after all
<ogra> yep
<ogra> but xscreensaver-data can live fine with the default wallpaper as well ... they are additional pics
<Keybuk> recommends/suggests ?
<ogra> so either no dependency at all or one on -data
<Keybuk> but yeah, I get what you mean now
<Keybuk> given the description of "install these to get default images for your screensaver" it makes sense that they haul in the screensaver
<Keybuk>  Source only demotions to universe 
<Keybuk>  --------------------------------- 
<Keybuk>  o myspell-sk
<Keybuk> pitti: !!
<pitti> Keybuk: I'm uploading a new l-support-sk now
<pitti> Tetralet: pong
<Keybuk> pitti: too slow for _this_ cat ;)
<Tetralet> pitti: https://launchpad.net/bugs/43991 #language-pack-kde-zh-base_6.06+20060511.tar.gz has not zh_TW entry.desktop
<Ubugtu> Malone bug 43991 in language-pack-kde-zh-base "Can't select Traditional Chinese" [Normal,Confirmed]  
<ivoks> pitti: untill when I have to create myspell-hr to get it uploaded? :)
<Tetralet> The missing files are exist in upstream,
<Tetralet> but the tarball of Ubuntu don't have them.
<pitti> ivoks: until today
<ivoks> pitti: ok, you'll get it
<pitti> Tetralet: that's what caleb- just said, will look at it after breakfast
<Tetralet> pitti: thanks!!
<ivoks> pitti: you need whole package or just dics?
<pitti> ivoks: a complete tested source package please, I don't have time for packaging today
<ivoks> pitti: no probs
<herzi> dholbach: can you take a quick look at https://launchpad.net/bugs/35825
<Ubugtu> Malone bug 35825 in gq "Does not appear in the menu" [Normal,Confirmed]  
<dholbach> herzi: cant you assign that to motu? or ask in #ubuntu-motu - i'm a bit busy
<pitti> Tetralet: I replied to the bug and marked it as milestone dapper; will be fixed in next langpack update
<Keybuk> heh
* Keybuk wonders how he makes a sync on behalf of "Debian Bug Importer"
<Tetralet> pitti: Got it. Thanks!!
<Keybuk> "-b debzilla" I *guess*
<sladen> infinity: I think the Kubuntu people have a new usplash and may want to keep it (it also looks fairly good)
* Keybuk wonders whether that would work <g>
<Keybuk> sladen: yes, I uploaded it a few hours ago
<jinty> Keybuk: SteveA tells me you have some questions on schooltool/schoolbell?
<sladen> Keybuk: you shouldn't need to cut the progress-bar out;  it's in the right place so would just be overwritten
* sladen wonders where the glow disappeared from the Ubuntu one
<Keybuk> sladen: yeah, but there was also text that needed cutting out
<sladen> okay.
<Keybuk> and there was a partial progress bar there, which would confusingly appear before one was set
<Keybuk> sladen: it was a _very_ dark glow, which is why I didn't notice it :)
<sladen> Keybuk: yup, along with the glow on the main part of the logo;  it's the fact that it's so subtle that (IMHO) opinion makes it work
<Keybuk> it was too subtle :D
<sladen> btw, why are we doing uploads of usplash to change the usplash artwork;  shouldn't that just be another alternative
<caleb-> pitti: Thank you!
<Keybuk> sladen: the default artwork is in usplash
<sladen> keybuk: yeah, it's a rhetorical question
<infinity> usplash needs to have a default image.  One could argue that it should just say "Usplash", and the "Ubuntu" one should ship in ubuntu-artwork or something.
<infinity> But I'm not fussed.
<sladen> Keybuk: like, ...shouldn't it actually be in a separate package, just like everything else
<sladen> infinity: indeed.
<infinity> Oh yaya, thunderbird FTBFS sorted, back on track..
* infinity hacks away some more.
<Kamion> Keybuk: cron.germinate is run by lp_publish now, at :30
<Keybuk> Kamion: and takes about 30 minutes to run?
<Keybuk> it seems to show up on the hour
<Kamion> Keybuk: I gave in on -fluendo-mp3 after noticing that (a) Debian had let it in and (b) it was no worse than all the other mp3 crap in universe already
<Keybuk> damn, ogra's fast
<ogra> :)
<Mithrandir> seb128: (re adding command would break stuff): grr.  About locale, setlocale is probably what you want.
<Kamion> Keybuk: takes like two minutes or something
<Kamion> anastacia's a separate cron job though
<Keybuk> ogra: are you intending to seed this in main?
<seb128> Mithrandir: ok, thank you
<sladen> Keybuk: with Xubuntu, what are they using for the Volume control?
<ogra> Keybuk, yep, its small, we can put it at least into supported
<Keybuk> sladen: sodomy non sapiens
<ogra> 200k or something
<Keybuk> at some point we need to pin janimo down and find out about all these xubuntu packages he's seeded
<Keybuk> Kamion: I punted git-email out, it didn't seem "useful" and dragged in too much
<Kamion> cjwatson@rookery:~/public_html$ ls -l anastacia.txt
<Kamion> -rw-rw-r--  1 cjwatson warthogs 2551 May 18 09:29 anastacia.txt
<Kamion> oh, I forgot to move the cron job after splitting out cron.germinate
<Kamion> right, should show up around :35 now, sorry about that
<Keybuk> :)
<Mithrandir> so, when did the "log out" symbol turn into something that looks vaguely like a door?
<Keybuk> Mithrandir: always has been?
<pitti> Keybuk: to me it looks like a power switch or a wall calendar :)
<Mithrandir> Keybuk: nope, it has looked like a somewhat-open door with a red arrow out.  The new one is a power switch looking like a door front-on with a power symbol.  Or maybe a wall calendar, as pitti says.
<ogra> guys, just use edubuntu :) in gartoon the icon is pretty clear ;)
<pygi> ogra, hehe :)
<Keybuk> Mithrandir: which icon theme are you using?
<Mithrandir> on that machine?  Whatever's todays default.
<Keybuk> hmm
<Keybuk> it hasn't changed to my eye
<infinity> Mithrandir: That's a door?... I thought it was meant to be a tower PC with a power off logo.  Either way, "power off logo" and "log out" don't work for me.
<Keybuk> Tangerine is the same as GNOME, just smaller
<Mithrandir> infinity: the power icon is too low anyway.
<dholbach> it's supposed to look like a power switch but will change again
<dholbach> we have a bug open about that
<infinity> Keybuk: Err, I thought we did the main inclusion dance for the git-email stuff?
<Keybuk> infinity: did we?
<infinity> Keybuk: git-email's sort of the canonical way to submit kernel patches.
<infinity> (little c, not big C)
<Keybuk> infinity: I grepped MIQ
<infinity> Hrm.
<Keybuk> all the Perlish bits it needs
<Keybuk> none of them had MIRs
<infinity> pitti: Did we once again forget to actually do the MIR dance for the git-email junk? :/
<pitti> arrrrgh
<infinity> Keybuk: We did a group "on IRC" thing, but then never actually formalised anything, it would seem.  Feh.
<infinity> pitti: Do you want me to do formal reports after I do tbird, or can we just sneak it in based on our past conversations?
<Keybuk> asciidoc, libemail-valid-perl, libmail-sendmail-perl, libnet-dns-perl, libnet-domain-tld-perl, libnet-ip-perl
<Keybuk> that's the list of sources it wants
<infinity> Keybuk: Yeah, we know.  We audited the bunch of 'em way back when.
<infinity> Keybuk: And none have changed since then, ttbomk (but I can check again)
<pitti> infinity: I'm fine with sneaking it in without MIRs, if you are sure that the Debian RC bugs don't affect us (I don't remember the details any more)
<infinity> pitti: The Debian bugs affected new versions in Debian that we didn't ship.  I'll double-check that no one's done a boneheaded sync where they shouldn't have and then call it gold.
<pitti> Keybuk, infinity: I'll do a formal MIR for asciidoc
<Keybuk> slap me when ready
<infinity> Keybuk: Verified again that the lib*-perl group is fine.
* infinity goes out shopping for snacks and such now.
* Keybuk giggles at today's Dilbert
<`6og> is this an ok place to ask about the licence attached to sun-java5? 
<`6og> i noticed it just made it into ubuntu and Debian, but Debian -legal and -devel are not to impressed with the licence, is that something ubuntu is happy to ignore?>
<infinity> We're distributing it in multiverse.  We're not exactly saying it's "free and wonderful and will solve the world's problems"
<infinity> We're just saying "Sun explicitely told us that we can distribute here, so here you go"
<pitti> Keybuk: https://wiki.ubuntu.com/MainInclusionReportAsciiDoc approved
<Keybuk> "Sun won't sue us, we're happy"
<kgoetz> hm. infinity, Debian don't think they can include it in non-free even.
<pitti> Keybuk: I also added it to https://wiki.ubuntu.com/UbuntuMainInclusionQueue, pleaes move it when you promote it
<kgoetz> Keybuk: mmmm.
<infinity> kgoetz: The license is sketchy, but OTOH, Sun has told us directly "Yes, you may package and distribute this", so it doesn't need to get much more free than that to hit a non-free archive.
<ivoks> pitti: ok, i have the source, luke :)
<pitti> ivoks: also tested in OO.o and found working fine?
<ivoks> pitti: yes
<pitti> cool
<ivoks> pitti: it's myspell-hr and openoffice.org-hypblabla-hr
* pitti pats Keybuk and excuses for neverending NEW requests today
<kgoetz> infinity: yes, it's free enough. from what i see the problem is if sun decide to not like us in the future - we have a problem in that case (having to remove the package or change the os). sorry, i just live my package inclusion life by what Debian say is allowed usualy :/
<ivoks> pitti: http://mentors.debian.net/debian/pool/main/m/myspell-hr/
<Keybuk> remove-package.py -m 'SUN turned evil again :-(' java*
<infinity> kgoetz: Removing the package from the archive isn't the end of the world if they reneg on the license.
<Keybuk> *shrug*
<infinity> kgoetz: We make no guarantees that non-free stuff (in Debian or Ubuntu) is mirrorable, distributable, or usable.  Just that we, the originating archive owners, are allowed to distribute it for the duration that it's on our machines. :)
<Yagisan> infinity: we can't comply with the license on sun-java. reading it seems we need to make a choice, sun java, or python, perl et al
<kgoetz> infinity: yes, but the licence also causes Ubuntu/Debian to be legaly covering suns arse if something goes wrong (from what i see). 
<pitti> carlos: will we get a tarball today?
<Keybuk> hurrah
<Keybuk> that bout of ftp-mastery should clean up the queue somewhat
<infinity> Yagisan: Yes, the license appears to say that.  The word from Sun themselves is "that's not really what we mean, and you're okay to distribute it"
<Keybuk> there will only be one thing in S/B promotions, and only two things in B demotions
<infinity> Yagisan: If their opinion changes, we stop distributing it.  Easy.
<carlos> pitti: yes, we got an update yesterday
<pitti> cool
<carlos> pitti: and I guess it will be the same for today, because the mirror update is disabled to test new shipit
<Yagisan> infinity: I'm sorry, that is not what the license says. legally, I can not operate on that. If they don't mean that, they can re-word the license.
<infinity> Yagisan: What they apparently are trying to prevent with that license is people distributing crazy gcj/sun-classpath hybrids and such.  Which we're not doing.
<Yagisan> infinity: then they have a bad choice of words
<infinity> Yagisan: Legally, it doesn't make a difference to you, since you're not the one distributing it.
<kgoetz> infinity: i am if i mirrror it :), which i'm plainning to do :)
<infinity> kgoetz: Then read the license and decide for yourself if you mirror it.  Neither Debian nor Ubuntu has EVER guaranteed that downstream distributors would have the same rights to non-free as the orignating distributors do.
<infinity> If non-free/restricted/multiverse scare you, don't mirror them.  Or mirror selectively.
<Kamion> it's easy to rsync --exclude pool/multiverse/ and dists/*/multiverse/; that's why the components are split out that way on the filesystem, to make that trivial to do
<kgoetz> infinity: i accept that ubuntu doesnt guarantee you can mirror stuff, but it does try to be open to being derived off. *thinks of fuss over firefox icon*
<Kamion> kgoetz: that's main
<Kamion> which is a somewhat different scenario
<infinity> kgoetz: We *do* make guarantees about freedom in main.
<infinity> kgoetz: I'm only talking about the non-free components here.
<infinity> kgoetz: If you want to throw firefox in multiverse just to get the icon back, go nuts. :)
<Yagisan> infinity: will the alternatives system be crippled to comply with the wish to prevent gcj/sun-classpath hybrids and such ?
<kgoetz> infinity: np ;)
<infinity> Yagisan: How would it need to be?  By default, we don't attempt to install crazy hybrid scenarios.
<infinity> Yagisan: If you make one yourself on your system, that's not the distributor's fault, that's your choice as an end user.
<Keybuk> Kamion: http://people.ubuntu.com/~scott/reports/
<Keybuk> (switching window)
* infinity really goes to the store for snacks now.
<sivang> kgoetz: pong (although a bit late)
<sivang> infinity: get some tim tams :)
<kgoetz> sivang: hi :) 
<kgoetz> mmm. timtams
<Keybuk> pitti: eww
<kgoetz> sivang: i was havving issues connecting to your bzr main-devel branch on LP.  
<Keybuk>  o qt4-x11: libqt4-core libqt4-gui
<Keybuk>    [Reverse-Depends: libqt4-gui, lsb-qt4] 
* Yagisan prefers doublecoat tim tams
<Keybuk> lsb dragged in qt4-x11
<sivang> kgoetz: oh, whcih one where you trying to fetch?
<Keybuk> pitti: can you audit that?
<pitti> Keybuk: audit what?
<Kamion> Keybuk: I saw, nice
<Keybuk> pitti: qt4-x11
<pitti> Keybuk: qt4? argh, we had this discussion months ago, I wouldn't be happy about it
<pitti> Keybuk: I'd rather not have it in main, especially not if we don't need it for core KDE apps
<Keybuk> now this leaves us in an interesting pickle :)
<Keybuk> I can drop lsb to universe <g>
<pitti> Keybuk: that was due to the recent merge with Debian?
<Keybuk> seems so
<Kamion> or just butcher lsb not to depend on lsb-qt4, or whatever it is that's pulling in that one binary
<Keybuk> Kamion: is that ... legal? :p
<Kamion> I'm just looking up the specs
<pitti> Keybuk: it apparently was legal in our previous lsb package...
<Kamion> # 1.3 Optional modules
<Kamion>     * 1.3.1 LSB Qt 4
<pitti> *phew* :)
<Keybuk> can drop it to a recommends
<Kamion> http://freestandards.org/en/Download
* Keybuk does that now
<pitti> Keybuk: suggests rather?
<Keybuk> yeah suggests
<Keybuk> thought the same just as I edited control
<Keybuk> Kamion: while you're there, is lsb-desktop optional?
<Keybuk> that was the other NEW
<Kamion> there's only one optional module ...
<Keybuk> that drags libqt3-mt
<Keybuk> but I guess that's ok?
<Kamion> we didn't have that already?
<Keybuk> it's in main, yeah
<Kamion> hmm, I don't want to have to suck libqt3-mt into Ubuntu ship
<Keybuk> that's what I was thinking
<Keybuk> though ship doesn't mean much now?
<Kamion> sigh, awkward people
<Kamion> see my mail about that
<Keybuk> ref?
<Kamion> https://launchpad.net/products/ubuntu-cdimage/+bug/44313
<Ubugtu> Malone bug 44313 in ubuntu-cdimage "build-essential not on Dapper Flight7 ISO" [Major,Confirmed]  
<Keybuk> ah right
<Kamion> hmm, rather than butchering lsb-desktop out of lsb (which would mean lsb wouldn't be LSB 3.1 any more), I'd rather either just put individual elements of lsb into ship, or leave it out entirely
<Kamion> lsb-{core,cxx,graphics} shouldn't be too unreasonable though
<Kamion> and then put full lsb into supported
<Kamion> I can see why they're doing it, but I don't think it's sustainable for a single-CD distribution
<Kamion> also, I'm making decisions before coffee, which is a bad idea
<Keybuk> it could be worse
<Keybuk> rumour has it infinity is shopping for something a little stronger ;)
<Kamion> I don't blame him
<Keybuk> OK!  WHO UPLOADED FIREFOX?!
<pitti> Keybuk: can you please NEW mozilla-firefox-locale-all for the new m-f-l-hr package?
* Keybuk leaves the new queue alone and goes to have lunch instead
<pitti> oh, oops :)
<Keybuk> pitti: all into main? :)
<pitti> Keybuk: yes, and 'all' is just the -hr package
<pitti> Keybuk: this time, the l-support-hr package is already updated :)
<Keybuk> pitti: yeah, well, our new queue tool doesn't bother to tell you what's new or not :)
<TheMuso> Mithrandir: Is it ok to squeeze a final accessibility related bugfix into casper? If so, I'll file a bug straight away and fix it in my casper tree.
<Mithrandir> TheMuso: please do file it at least and give me the url of your tree and I'll take a look
<TheMuso> ok.
<mdke> can someone who has access to this information tell me whether henrik is on vacation at the moment?
<Mithrandir> mdke: he's on IRC which he tends to just do when he's around.
<TheMuso> mdke: He is online atm. I was talking to him a few minutes ago.
<mdke> ah, thanks
<Kamion> iwj: I was trying to work out how you'd built your yaboot-test-ordinary.iso
<Kamion> isoinfo diff says:
<Kamion> --r--r--r--   1    0    0          145604 Apr  1 2006 [     68 00]   yaboot
<Kamion> +-r--r--r--   1    0    0          145504 May 17 2006 [    348 00]   yaboot
<Kamion> between dapper-install-powerpc-stripped.iso and yaboot-test-ordinary.iso
<Kamion> what happened to the last hundred bytes? :-)
<iwj> I don't know.  I rebuilt yaboot.
<iwj> That is, I rebuilt yaboot _twice_.
<iwj> Once on davis using whatever the dapper chroot had installed, and once with gcc-3.3 on the PATH.
<infinity> pitti: How do you feel about doing a thunderbird-locales update for 1.5.0.2?
<pitti> infinity: I'll try to do it today (since it's today or never)
<pitti> I'm currently at printing bug fixing (again...) but it shouldn't take that long any more
<infinity> pitti: Currently, they all claim to be incompatible with 1.5.0.2, but I'm unsure if that's easily solved or a serious pain.
<pitti> infinity: but it takes a lot of time to test the XPIs
<Kamion> iwj: oh, right. I might have to point them to all three then.
<iwj> Yes, I'm afraid so.
<pitti> infinity: oh, usually you can hack the install.rdf in the xpi to just select a maxVersion of 1.5.0.99
<pitti> infinity: but grabbing the latest ones from upstream can't hurt either
<infinity> pitti: Then that's probably our better bet.
<iwj> Kamion: I did that because you said you wanted to know whether it was really gcc-3.3 that solved the problem :-).
<Kamion> damnit, I'm going to push to get bsdtar into base or something in edgy so that I stop having to mess around with isoinfo
<infinity> pitti: But whatever you feel is best.  You put it together, not me.  I'm happy with an English-only Tbird. :)
<Kamion> iwj: sure, it makes sense - just wanted to make sure it was intentional
<iwj> Right.
<Kamion> Anyone with a powerpc around who could do a couple of quick test-boots of small ISO images before I punt these out to bug reporters?
<pitti> Kamion: I can, depending on what 'small' is (limited bw here)
<TheMuso> Mithrandir: http://www.themuso.id.au/ubuntu/casper - For bug #45376
<Ubugtu> Malone bug 45376 in casper "Large print fonts are not enabled for the lesser visual impairment accessibility profile." [Normal,Unconfirmed]  http://launchpad.net/bugs/45376
<Kamion> <30MB
<pitti> Kamion: that sounds fine
<Kamion> pitti: http://www.chiark.greenend.org.uk/~ian/d/dapper-install-powerpc-stripped.iso <- stripped-down version of yesterday's daily build; should boot the installer but not actually install anything
<Kamion> pitti: http://www.chiark.greenend.org.uk/~ian/d/yaboot-test-ordinary.iso <- same, but with yaboot rebuilt on davis
<Kamion> pitti: http://www.chiark.greenend.org.uk/~ian/d/yaboot-test-weird.iso <- same, but with yaboot rebuilt on davis with gcc-3.3
* pitti downloads
<Kamion> 22.5MB each
<Kamion> thanks a lot, just want to make sure there are no thinkos before confusing an already confused situation :-)
<Kamion> NOTICE: please do not attempt seed commits in the next 20 minutes
<Kamion> (converting to knits)
<Kamion> in fact, I'm going to move the repository so you can't commit easily :-)
<lifeless> Kamion: no need
<lifeless> Kamion: the upgrade is safe
<lifeless> Kamion: it takes out locks where needed.
<Kamion> lifeless: not if somebody rsyncs over the top while it's running :P
<lifeless> Kamion: you use rsync to commit ?!
<Kamion> I just want to be safe, no harm in that
<Kamion> lifeless: *I* don't
<lifeless> being safe is fine
<pitti> MEH, why does cd burning suddenly fail here?
<Kamion> moving the repository is not harmful; the publicly-viewable archive is elsewhere, mirrored by cron
<lifeless> was just letting you know that it shouldn't be needed.
<Kamion> FURTHER NOTICE: if you have a local seed branch (even one with no local modifications), you should run 'bzr upgrade' on it with bzr 0.8
<Kamion> (I'll send out mail when I'm finished)
<Riddell> Keybuk: please don't change kubuntu artwork without asking me
<pitti> Kamion: dapper-install-powerpc-stripped.iso boots fine, language selection works, now stops at 'no valid Release file'
<Kamion> right, that's expected, good
<pitti> Kamion: yaboot-test-ordinary.iso behaves exactly the same
<Kamion> excellent
<pitti> 3rd CD just finished burning, booting now
<Keybuk> Riddell: any particular reason?
<pitti> Kamion: yaboot-test-weird.iso: again, no observable difference, install stops with invalid Release file
<Kamion> pitti: excellent. Thanks a lot for the help
<pitti> you're welcome
<Riddell> Keybuk: we do plan our kubuntu artwork.  did you ask our artist?
<Keybuk> Riddell: the usplash changes are across the board?
<silbs> hi folks. shipit for Dapper  has quietly gone live (shipit.ubuntu.com. shipit.kubuntu.org, shipit.edubuntu.org). There is still an important feature to be added (ability to order large numbers of CDs) so the launch is relatively low key until that's in place. But it's been open for about 2 hours and NO ONE has placed an order for Dapper CDs.  Who will be first....
<kgoetz> heh. I'm going there :P
<Riddell> silbs: excellent
<tseng> silbs: heh, crashed my firefox
<kgoetz> LOl
<tseng> 10 Ubuntu CDs (8 PC Edition, 1 64-bit PC Edition, 1 Mac Edition)
<tseng> i have a dozen amd64 servers
<silbs> tseng: really!  maybe that's why there are no orders! https://launchpad.net/products/shipit/+filebug please :)
<tseng> silbs: heh working better now!
* kgoetz will wait for the big orders bit
<Riddell> Keybuk: that usplash goes quite against the artwork we're using in dapper, I'm going to revert it
<Yagisan> silbs: how do I make an order for 1 i386 + 1 amd64 ? I don't want excess cds
<Keybuk> Riddell: it's not much different than the old one, other than slightly shinier
<Riddell> Yagisan: make two orders, it'll put them together
<Riddell> Keybuk: it's not much different from the breezy one, it is from the dapper one we were using
<Keybuk> it didn't look much different when I changed it
<kgoetz> silbs: any idea how long untill the builk orders start?
<Yagisan> Riddell: I only get an option to change my order, not add to it
<Keybuk> Riddell: otherwise kubuntu is going to look rather different to Ubuntu
<Riddell> Yagisan: hmm yes, I'm wrong
<Riddell> Keybuk: yes, our artwork is not related to ubuntu's artwork
<pitti> infinity: I'll wait with the tbird-locales update until the new tbird is in the archive; I like to actually test the new l10n debs :)
* pitti goes to fix his last real bug in his dapper bug list
<infinity> pitti: Fair enough.  It should be up in another hour or so, I'm hoping.  Down to my last set of changes and tests.
<Mithrandir> pitti: so now you get to slack the rest of the day?
<pitti> Mithrandir: unfortunately not :(
<pitti> Mithrandir: I still need to wade through the cupsys and g-c-m bugs again to check whether anything urgent and new has popped up
<Mithrandir> pitti: sounds !fun
<pitti> Mithrandir: the postgresql bug fixing can happen tomorrow, since I can upload to Debian and sync, to avoid giving too many cocktails :)
<pitti> (to mdz)
<Mithrandir> pitti: you workaholic
<pitti> na, I have always considered psql a free time project; it's fun
<pitti> Mithrandir: much more fun than doing my overdue fiscal paperwork and tax declaration in any case
<Mithrandir> pitti: I get to do those tomorrow.  Joy.
<Mithrandir> pitti: not overdue, though.
<pitti> Mithrandir: me too, for that I welcome the free day
<pitti> Mithrandir: we have to hand them in by May 31
<Mithrandir> pitti: on the other hand, it means money back, which is always nice.
<pitti> Mithrandir: oh, does it? for me it means paying all the 2005 taxes in one big chunk
<pitti> and on top of that, an advance for Q1 and Q2 of 2006
<Mithrandir> pitti: I did that some weeks ago and overpaid by a fair amount to be sure.
<silbs> kgoetz: next week, probably Wed-ish
<Usiu> Hi
<kgoetz> silbs: thanks. i'll try and hang on that long :)
<Usiu> Plz help how to build packages for Ubuntu on debian.. :(
<silbs> Yagisan: we will tweak the options as we discover what combos people need. You can wait till the special request feature (next week).  You can also suggest different pre-set combinations at https://launchpad.net/products/shipit/+filebug
<Usiu> Ok the thing is I have packages for Debian, but I have a problem with setting up pbuilder for Ubuntu, I dont have much  time to play with that... It works for me for Debian packages.. But pople are asking for Ubuntu's as well... but dependences need newer packages which are not in dapper yet..
<Kamion> ok, seed migration to knits done, belatedly
<dholbach> Kamion: I'll do a system-config-kickstart upload with dh_iconcache added to debian/rules - are you ok with that?
<Kamion> dholbach: go ahead, thanks
<dholbach> Kamion: thanks
<Kamion> I'd been meaning to get around to that
* dholbach hugs Kamion
<dholbach> it's ok :)
<dholbach> the list in main is 29 source packages - which is ok
<dholbach> i'd just prefer to get it done before "restricted main uploads" phase has started
<Kamion> janimo: could you upgrade to bzr 0.8 (if you haven't done so already) and 'bzr upgrade' the xubuntu seeds to knits? I've just upgraded all the others; see ubuntu-devel-announce@
<janimo> Kamion: will do, thanks
<Kamion> let me know when you've pushed that and I'll do the same to my mirror
<Kamion> the first push will take a while, subsequent ones should be faster than they were with the previous format
<janimo> Kamion: it will probably not happen in the next couple hours as the server with the seeds is a friends FC4, but I'll try to do it soon
<Kamion> janimo: ok, no problem
<jordi> Kamion: does man-db hqave an internal table of supported locales or something? Do you kknow offhand of something in it that would make it not use a "valencia_ES" locale (non-standard)?
<jordi> Kamion: I saw your reply re: nano. I'll have a look in the evening
<Kamion> jordi: yes, it has its own table
<Kamion> jordi: file a Debian bug report about problems with it
<jordi> ok
<seb128_> Kamion: daily liveCD boots again ;)
<seb128_> just FYI
<Kamion> seb128_: yep, thanks - non-8.3 filenames bit me
<Kamion> I fixed that last night
<Kamion> (but you weren't around so I couldn't tell you at the time)
<Keybuk> Kamion: that does seem somewhat faster
<Kamion> a commit was reasonably fast; although I haven't tried edubuntu which has traditionally been the weirdly slow one
* Kamion wonders what's happening with the (lack of) kernel upload
<Keybuk> Riddell: actually, while you're here, kwifimanager
<Riddell> Keybuk: demote it please
<Keybuk> it keeps wanting to skip into universe because nothing depends on it
<Keybuk> ok
<Riddell> we have a better alternative (wlassistant) that's not so broken
<Keybuk> done
<Keybuk> janimo: ping
<janimo> Keybuk: pong
<Keybuk> janimo: xubuntu-artwork
<Keybuk> it wants to live in universe too
<Keybuk> should that not be seeded somewhere?
<janimo> Keybuk: fine by me, it's a metapackage
<Keybuk> which bit was fine? :)
<janimo> depends on xubuntu-artwork-usplash which we have in main
<Keybuk> you want it demoted?
<janimo> being in  universe is fine :)
<Keybuk> ok, that's easy then
<Keybuk> yay
<janimo> Keybuk: yes since it is not seeded. It was meant to be a metapackage for most artwork but that eventually landed in xubuntu-settings-default
<Keybuk> that'll make anastacia very clean :p
<Keybuk> Kamion: a push of ubuntu seed just took a second or so
<Keybuk> I'm used to it taking at least 20 minutes
<Keybuk> this is an "improvement"
<janimo> hmm, if that's the case I may consider doing local edit + push instead of logging in via ssh for editing.
<Kamion> Keybuk: :-)
<Keybuk> lifeless: well done.  you can have my nan award for knitting
<lifeless> danke
<Mithrandir> Seveas: thanks for you comment re svizzer.
<Seveas> de nada
<janimo> Kamion: bzr upgraded. .bzr dir is also about 4 times smaller :)
<Kamion> janimo: thanks; upgraded my mirror too
<Kamion> Riddell: could you eyeball the ubiquity kde-ui changes I just pushed (matching similar gtkui changes)?
<Riddell> Kamion: sure
<Keybuk> janimo: oh, and evince-gtk needs an MIR
<infinity> pitti: Okay, I *think* I'm on my last testbuild now... Maybe.
* pitti crosses fingers
<infinity> Could take me another 30 mins to correlate changelog enries with LP bugs and get all the LP bugs in the changelog...
<infinity> I might pass on that.
<janimo> Keybuk: what's a MIR?
<Keybuk> janimo: MainInclusionReport
<janimo> Keybuk: oh it had one but was postponed to the further work needed section because code duplication
<janimo> it is mostly the evince package rebuilt with --disable-gnome
<Keybuk> ah right
<janimo> plus apatch which is not upstream
<janimo> same with xubuntu-system-tools
<Kamion> Riddell: actually, there's another couple of changes I just pushed that affect kde-ui too
* _ion just looked at the new usplash artwork in action. It and the text colors were very good overall, but IMHO the progress bar foreground color could have been a little darker.
<Riddell> Kamion: looking
<sladen> _ion: it was toned back slightly.  If you find another colour already in the palette that works better, mention it to omeg
<_ion> I'd say any color that is a little darker.
<_ion> Not too dark, of course.
<infinity> pitti: I WIN!
<infinity> pitti: Just let me polish the changelog and upload.
* pitti ^5s infinity 
<pitti> iwj: do you plan another firefox upload in the near future? I'd like to have some new CVEs retroactively added to the changelog
<dholbach> ogra: anything new about dia?
<iwj> pitti: I don't know if I have one planned, but if you mail them to me I'll include them if I do.
<pitti> iwj: will do
* Kamion creates a ship-live seed and hopes he can make it work
* sivang goes to try dapper-install-powerpc.iso on the pSeries
<Mithrandir> sivang: what kind of console do you have on your pseries?
<KaiL> nice, Novell is working on some post-release-driver-update-support...
<tseng> is it still the plan to drop LinuxThreads in edgy?
<sivang> Mithrandir: HMC
<sivang> Kamion, Mithrandir : same error as on the stipped CD - http://muse.19inch.net/~sivan/error.png
<Mithrandir> sivang: what can I plug into that?
<sivang> Mithrandir: what do you mean ?
<Mithrandir> sivang: I have a pseries and I have no idea how to get a console on it. :-)
<sivang> Mithrandir: oh, nice, where did you get it from? :)
<Mithrandir> sivang: IBM dropped it on me.
<Mithrandir> (loan, not gift)
<sivang> Mithrandir: oh coo, /me woudl also love one at home :)
<sivang> Mithrandir: try to find the serial ports at the back of the machine,
<sivang> Mithrandir: use a laptop and connect using RS232 cable
<Mithrandir> sivang: ok, that should just work?
<sivang> Mithrandir: power down the machine, plug out the machine from the outlest
<sivang> Mithrandir: outet
<sivang> Mithrandir: err, outlet! damn latency :)
<sivang> Mithrandir: make sure you are connected with a minicom
<Mithrandir> what settings?
<Kamion> sivang: could you please try these three images?
<Kamion> sivang: http://www.chiark.greenend.org.uk/~ian/d/dapper-install-powerpc-stripped.iso
<Kamion> sivang: http://www.chiark.greenend.org.uk/~ian/d/yaboot-test-ordinary.iso
<Kamion> sivang: http://www.chiark.greenend.org.uk/~ian/d/yaboot-test-weird.iso
<sivang> Kamion: all of them? :)
<Kamion> sivang: yes please, they're 22.5MB each
<sivang> Kamion: ah, now you're talking :)
* sivang wgets
<Kamion> thanks
<sivang> Mithrandir: make sure it's on 14400 N81 IIRC
<Mithrandir> 14400 8n1?  That's weird settings, but ok, I'll try.
<sivang> Mithrandir: shoudl work, if not reduce the baud rate to 9600
<Mithrandir> sivang: usb-serial dongles should work fine?
<sivang> Mithrandir: no idea :-/ I have only used RS232 wiring on both ends
<sivang> Mithrandir: could :)
<Mithrandir> sivang: ok, thanks.  I'll try that.
<sivang> Mithrandir: np, let me know what you find 
<sivang> Kamion: did ian prepare those? :)
<Kamion> sivang: yes
<Kamion> well, I prepared the first one
<Riddell> Kamion: you missed a set_current_page call, but otherwise it all looks fine
<Riddell> Kamion: I've added that and fixed a crash I made in return_to_autopartitioning
<Riddell> so good to merge
<janimo> ogra: hi, can you look at bug 42890 for a moment, maybe you know the fix
<Ubugtu> Malone bug 42890 in xubuntu-meta "Screensavers are enabled but not installed in Xubuntu Dapper" [Normal,Confirmed]  http://launchpad.net/bugs/42890
<Kamion> Riddell: could you 'bzr upgrade' your branch to knit format, please?
<ogra> janimo, that would be very intrusive to fix, since the default config handling is very tricky among the differnt xscreensaver packages
<Kamion> will make merges quicker
<janimo> ogra: so is it a known thing? what package are the selected but not installed savers in?
<ogra> janimo, your problem is /etc/X11/app-defaults/XSceensaver
<ogra> janimo, we dont do any preselection in the config anymore, so you get what debian enabled
<ogra> which probably might be *all*
<janimo> ogra, so it was done in breezy but not anymore?
<janimo> too intrusive?
<Riddell> Kamion: I already have
<ogra> no need anymore, since gnome-screensaver handles the hacks through .desktop files, not thirough a user or system config
<ogra> yes, way too intrusive at this point
<Kamion> Riddell: not on your kubuntu.org mirror
<janimo> ogra: ok, thanks. Although where are the screensaver that debian or uptsteam enables? for example anemone
<ogra> you'd have to rewrite the postinst prerm scripts and also make sure the linking of the config files doesnt break on upgrades
<Kamion> Riddell: you may need to upgrade that branch separately
<Riddell> bzr upgrade
<Riddell> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<Kamion> Riddell: or just rsync over the top of it this time if you prefer ...
<Kamion> Riddell: probably bzr too old on kubuntu.org
<Kamion> format 1 is pretty elderly
<janimo> ogra, I am fine with leaving as is, but am curious why are these enabled, and what can be installed to have them all?
<ogra> janimo, apt-file is your friend ;) but likely in either xscreensaver-data, -data-extras, -gl or -gl-extras
<janimo> ogra, whenever I tried apt-file it failed to wget the package list :(
<Riddell> Kamion: I have 0.8-0ubuntu1 installed
<janimo> was last year though
<Kamion> Riddell: http://kubuntu.org/~jriddell/espresso/ubuntu/.bzr/ definitely shows stuff like inventory.weave though
<Kamion> oh
<Kamion> you have knits *and* weaves in there
<Kamion> weird
<Kamion> maybe not using rsync --delete?
<Riddell> mm, yes, that'll be it
<Kamion> Riddell: heh, I'd already fixed 45396
<Kamion> Riddell: oh, I thought on_steps_switch_page would take care of calling set_current_page, since you don't call set_current_page after doing raiseWidget elsewhere
<Kamion> merged and pushed
<maswan> Hmm.. I forget, do we have a ballpark date for the release? (For mirror planning over here..)
<Mithrandir> maswan: June 1st?
<maswan> Mithrandir: Ok. Eek? :)
<sivang> argh. why can't perl use sys.argv like python does? 
<Mithrandir> because that would make it harder to use @ARGV sensibly in perl?
<sivang> Mithrandir: I can't seem to find the sensible way to do so at the mooment, probably a brain lock down.
<Mithrandir> for $f in (@ARGV) in perl is roughly for f in sys.argv[1:]  in python
<Kamion> except that you leave out the 'in' in perl
<Kamion> $0 is sys.argv[0] 
<_ion> ARGV.each {|a| ... }
<Mithrandir> Kamion: true.
<sivang> Kamion: weird, tried to use $0,.... but it all fails
<sivang> that is, (if -e $1) etc..
<Keybuk> Kamion: not to mention the "$f" :)
<Riddell> Kamion, Mithrandir: are we doing flight 8?
<Kamion> Riddell: no, I don't think so, not with the mandatory holiday tomorrow
<Kamion> sivang: well that's illegal perl syntax ... 'if (-e $1)'
<Kamion> sivang: er, and not $1 either
<Kamion> sivang: $0 is sys.argv[0] , $ARGV[0]  is sys.argv[1] , $ARGV[1]  is sys.argv[2] , etc.
<Kamion> $1 is something entirely different
<Keybuk> for (@ARGV) { ... if -e }
* Keybuk likes "miss out all the code"-y perl
<Mithrandir> Keybuk: ... is valid in perl. :-)
<Keybuk> http://people.ubuntu.com/~cjwatson/anastacia.txt
<Keybuk> ^ ah
<Keybuk> now, nobody upload anything and ruin it :p
<Coyctecm> what th ehell is wrong with open office
<Coyctecm> x64
<sivang> Kamion, Keybuk : thanks.
<Coyctecm> it's slow, too slow
<_ion> coyctecm: What isn't? ;-)
<Coyctecm> _ion: :P
<Riddell> Kamion: is pkgsel/language-pack-patterns the choice for installing language packs?  is there any way to get kde language packs installed?
<Keybuk> Coyctecm: you're expecting openoffice to be fast?
<Kamion> Riddell: you mean in ubiquity?
<Riddell> Kamion: yes
<Kamion> Riddell: there's a bug
<Kamion> it's all set up, but is broken for some reason
<Kamion> I will look at it
<Coyctecm> Keybuk: no, but with amd64 it's so damn slow. with x86 it's usable
<Coyctecm> well...
<Coyctecm> abiword :)
<Keybuk> Coyctecm: there is no amd64 version of openoffice
<Keybuk> on amd64 you are running the i386 version
<Coyctecm> Keybuk: yes, that's true. but with x86 version of ubuntu it's faster than with x64 ubuntu. I quess it has something to do with gnu java
<BenC> Ok, final build test for final dapper kernel is finally running, and should be finalized in about 1-2 hours, upon which I will finally upload this final kernel
<zul> and then you can work on 2.6.16 :)
<Kamion> well there goes my evening
<zul> BenC: we can do some training this late afternoon as well 
<pitti> BenC: this is finally your final finalization? :)
<ajmitch> pitti: sounds quite final to me :)
<Keybuk> Kamion: meh, take the evening off anyway :)
<BenC> pitti: finality is so...finite...let's see how it goes :)
<Keybuk> you deserve it!
<Kamion> Keybuk: I *can't*, I have to get the final installer in
<Keybuk> :(
<Kamion> it is *not possible*
<BenC> Keybuk: what's involved in the installer build...is it something I can do for you?
<BenC> s/Keybuk/Kamion/
<Kamion> not really, it needs me to sync in new translations which is messy
<tepsipakki> mithrandir: the new user-setup broke preseeding "passwd/make-user boolean false"
<tepsipakki> it still asks for the username
<Kamion> BenC: #ubuntu-meeting
<tepsipakki> Mithrandir: nevermind.. there's the passwd/root-login now that I also need to preseed :)
<Mithrandir> tepsipakki: I'm really busy now, please file a bug if you need me to look at something.
<tepsipakki> Mithrandir: no need to, there is no bub
<tepsipakki> _bug_
<Mithrandir> no bubs.  check.
<tepsipakki> :)
<Mithrandir> :-)
* tepsipakki was thinking of "buubs"
<tepsipakki> ..
<pitti> Keybuk: can you sync from any URL or just from Debian?
<Keybuk> I assume any URL
<Keybuk> I've not tried it though
<pitti> Keybuk: can you please sync http://mentors.debian.net/debian/pool/main/m/myspell-hr/myspell-hr_1.0-2.dsc to main?
<pitti> Keybuk: I just tested the package, works fine
<Keybuk> is there a packages file alongside that?
<iwj> pitti: There will be another firefox it turns out.  Can you send me those CVEs ASAP if you haven't already ?
<pitti> iwj: I didn't yet; if I prepare it right after the meeting, is that soon enough?
<pitti> Keybuk: no, just the source
<Keybuk> in theeeory, I do this
<Keybuk> *hits enter*
<iwj> pitti: Yes, that's absolutely fine.  I meant just today really; I probably won't be able to get a release out until Monday anyway.
<iwj> Thanks.
<pitti> alrigh, you'll have it today
<Kamion> you can always synthesise a Sources file and sync from that ...
<Keybuk> ok, that didn't work
<pitti> Keybuk: if it's too much trouble, I just do a normal upload, I was just curious
<Keybuk> Kamion: I have a sources file, can't work out how to sync from it though
<Kamion> Keybuk: oh, it needs to be in sync-source.py
<Kamion> there's a big dictionary of URLs and stuff
<Keybuk> yeah
<Keybuk> I'm just trying again now after copying and modifying it
<Keybuk> well, blow me, it worked
<pitti> Keybuk: great, thanks! I'll update l-support-hr then
<bddebian> Howdy peoples
<yogi>  I have asked --more than once or twice-- about wmv9 codec on the e-mail forum & received no response, so am hoping you can help.  It seems that no video player (kaffeine, xine, totem) can/will play wmv9 encoded videos.  I have received same from a friend running SuSE & am wondering if or why ubuntu does not seem to support this...?
<Keybuk> yogi: ubuntu does not support this
<yogi> keybuk:What the devil...?  Are we going to let SuSE eat our lunch?!
<Keybuk> yogi: yes
<pitti> yogi: if you are on i386, installing the windows DLLs might help; for !i386, you are screwwed
<thoreauputic> yogi: you have w32codecs installed?
<yogi> Keybuk:(1)How come? (2)I'm on a P4 (installed i386 kubuntu) (3)I have w32codecs installed, yes.
<Keybuk> yogi: in all seriousness, unless Microsoft give us the source to and/or a patent licence for the WMV9 decoder, then we can't ship it
<Keybuk> we have no particular desire to go to jail
<HiddenWolf> yogi: install totem with the xine-backend/libs and w32codecs or gstreamer-0.10-pitfdll and w32codecs
<yogi> Do tell.  Hm.  I wonder if SuSE paid the royalty.  They don't support DVD reading, which made me really sit up & take note when I got the wmv9 file. Their xine, etc, come broken right out of the box.
<Keybuk> yogi: they may have done
<yogi> HiddenWolf:Okay... will give that a shot.  Did it work?
<HiddenWolf> yogi: that works, better with xine than with gstreamer, but you'll have to pull the w32codecs from somewhere
<yogi> Keybuk: Possibly...  Thanks for the info, at any rate.  I'm not about to leave kubuntu on that flimsy excuse.  This is the first distro that hasn't broken each & every time it is updated. :-)
<HiddenWolf> yogi: this isn't apropriate for -devel tho.
<Keybuk> yogi: certainly if you don't mind breaking the law, there's no reason you can't grab the DLLs and use those
<Keybuk> that works on i386
<Keybuk> but sadly not on amd64 :(
* Keybuk has to watch porn on his laptop now
<Keybuk> which, logistically speaking, is not ideal
<kgoetz> er....
<yogi> HiddenWolf:Thanks.  I wondered if it was appropriate... last ditch effort since I could get an anser nowhere else.  I tried other avenues first, of course.
<Riddell> yogi: try installing libxine-extracodecs
<HiddenWolf> Keybuk: that depends on the law. :)
<yogi> Riddell:Roger.  Thanks.  I may not have that installed... though I thought I did.  Will check.
<yogi> Have a wonderful day, all. :-)
<pitti> Keybuk: seems that the sync has worked, I got an 'is NEW' mail
<Keybuk> oh, I SUPPOSED you want me to do THAT now, don't YOU!
* Keybuk tries to find it amongst the soname changes
<Keybuk> I only emptied this damned queue this morning
<pitti> Keybuk: it's not that urgent, but if it could be newed today, that would rock
<Keybuk> done :p
* pitti hugs Keybuk 
<pitti> Keybuk: anastacia output looks great now!
<pitti> Keybuk: wrt the two last entries, I wouldn't like to see them in main; it's hideous source package duplication
<Keybuk> aye, I saw your comments already
<janimo> pitti, instead of evince-gtk should I write an MIR for epdfview then?
<janimo> and it's not that hideous, just duplication :)
<bddebian> Who is: Bjoern Brauel 
<pitti> janimo: if nothing else helps, then so be it; I can live with evince-gtk...
<bddebian> ?
<pitti> janimo: I just hoped for a better upstream solution
<pitti> janimo: let's talk about this after the meeting
<janimo> pitti, upstream are not serious imho. after they said cointinue with the patch it is interesting, they truned around and gave me a great technical argument: 'it's better with gnome'
<pitti> bah
<bddebian> heh
<janimo> they talk about maintainabilkity issues because of the ifdefs, but they have ifdef on libgnomeprint
<janimo> which is a single small lib and a lot morelikely to be around than gnome libs
<janimo> oh well
<janimo> meanwhile I get mailed personally for keeping the patch uptodate wrt CVS by various peoppl interested in  it for fbdev,windows etc :(
<seb128> janimo: not nice to bash on upstream like that
<seb128> janimo: they are just few people and busy
<janimo> seb128: it';s not bashing, I am telling what I have been told
<seb128> janimo: and evince is the a GNOME project, you can't blame them to not want to spend their time to get GNOME away for it
<seb128> janimo: "upstream are not serious imho"
<janimo> busy people saying NO upfront is a lot better than people saying yes and after work hav=s been done saying no
<janimo> or just not responding
<seb128> janimo: did you get a reply from the exact same person?
<janimo> seb128:  yes, Nick
<janimo> the other's don;t even comment
<lamont> Keybuk: heh
<janimo> last september when I first asked about the feasability of such a port jblandford said it's too much work and not recommended
<seb128> Nick? I'm not sure than this guy is upstream
<seb128> he's a busy guy
<janimo> after a few days it was done, being my firts contact with glib/gtk
<janimo> so not that hard
<seb128> he didn't do a lot on evince for some months now
<janimo> Nickolay Shmiryev
<Keybuk> lamont: @ ?
<janimo> I know blandford is busy
<seb128> he's upstream ;)
<lamont> your discussion with infinity wrt coordinated  uploads
<janimo> just saying they dismiss this issue woithout _real_ techincal arguments
<seb128> anyway I think they probably don't care about making it build without GNOME since that's a GNOME project
* lamont eats
<seb128> sure they have not
<seb128> they just have better to do
<janimo> telling people 'use gnome you'll like it' is not always the right thing to say
<seb128> and don't really care of anti-GNOME people
<seb128> telling to GNOME upstream "GNOME sucks" is not really too
<janimo> seb128: who are anti-GNOMEpeople?
<janimo> and who said GNOME sucks?
<seb128> people who want to get GNOME out of the code :p
<janimo> I think there are waaaay to many hotheads in both gnome and kde camps who on hearing anyone mention the other start fibrilating and putting words in others mouths
<janimo> I am not anti GNOME but they have responded to me as if I was
<seb128> that's not that true for GNOME
<seb128> people don't start on KDE as soon it's mentioned
<janimo> seb128: it is not for gnome as a whole. It is so very true for some devs
<seb128> but they just don't care
<janimo> seb128: come on, even to you when I mention anything xfce (and more so some moths ago), you don't always read the whole sentence and answer some stock 'go away gnome hater' :)
<seb128> not really
<jsgotangco> lol
<jdub> guys, guys
<seb128> I just hate to have overwork because we are trying to make GNOME apps stop using GNOME
<janimo> I encountered this with some xfce upstream poeple too so it's all ok
<jdub> hack on ridley, make the gnome platform suck less :)
<seb128> hey jdub ;)
<jdub> we can dodge all of this crap soon
<seb128> jdub: when we will be here GTK will be too heavy for those xfce people :p
<jdub> heh
<janimo> seb128: yup, that's why I never whined or made someone work, but did it myself
<seb128> janimo: even if you do yourself we are in a situation where gnumeric, etc are not syncable on Debian now
<kgoetz> hi jdub
<janimo> seb128: Ray dassen said he'd sync gnumeric from ubuntu, but not do the changes himself
<janimo> seb128: as for not compiling with gnome libs, as I said above, evince does have a configure switch for libgnomeprint. How do you explain that?
<seb128> GTK does printing now
<seb128> so it's fair to not build with deprecated lib :p
<jdub> hi kgoetz 
<kgoetz> :)
<janimo> seb128: it's not fair to config a lib which is so small and spinkle ifdefs around, and in the same time say we won;t block-iifdef the rest of ~30 libs 
* jdub spanks seb128 :)
<seb128> jdub: heh
<jsgotangco> oohh jdub digs spanking
<janimo> jdub: ridley is still far (>1 year I'd say) from making these go away
* kgoetz diggs it :P
<hunger> Any idea how I can get CLOSE_SESSIONS back into /etc/login.defs? libpam-mount doesn't make too much sense without that.
<Mithrandir> echo CLOSE_SESSIONS >> /etc/login.defs ?
<hunger> Mithrandir: It is marked as obsolete in dapper.
<hunger> Mithrandir: So I guess it is not that simple.
<pitti> hunger: hm, obsolete means it should still work?
<hunger> pitti: "These options are no more handled by shadow." does not sound like those will still work.
<pitti> oh, hm
<pitti> mdz: argh, I'm afraid I might not manage to finish tbird-locales update today; would next week be enough?
<mdz> pitti: I don't know what's involved; send email?
<pitti> mdz: I start today, and possibly continue tomorrow, but it takes a fair amount of testing time
<mdz> pitti: if it's 100% safe and we are building a new candidate anyway, perhaps
<pitti> mdz: update all the xpis to 1.5.0.2 version and test them
<hunger> pitti: According to the Changelog of login "CLOSE_SESSIONS" is always used now, so the config option was removed.
* Keybuk giggles at the gnome-screensaver bug
<pitti> hunger: oh, so it resolved itself into thin air? :)
<ogra> lol
<Kamion> seb128: I meant like the way installation-guide-* is unpacked into /doc/install/ on our CD images so that you can read it before installation
<hunger> pitti: Yes... so I must have messed something else up to break unmounting of my pam-mount stuff:-)
<ogra> mdz, i think its fixed, Keybuk saw that the environment gets filtered before the var is even used
<ogra> (gnome-screensaver that is)
<seb128> Kamion: ah, ok
<ogra> mdz, so it turns out to be a one line change to get the screensaver fixed for the liveCD :)
<Keybuk> ogra: yeah, definitely fixes it
<ogra> yep
* dholbach hugs Keybuk
<jsgotangco> goodnight
<Riddell> pitti: did you pick up on the langauge-pack-kde-xx issue?
<pitti> Riddell: I don't know about that, what's the problem?
<Riddell> pitti: kde needs an entry.desktop file in /usr/share/locale-langpacks/xx ...
<Riddell> pitti: that's only there if there's a kde-i18n-xx package to extract it from
<pitti> Riddell: right, that shuold be there for most packages already
<Riddell> pitti: but people have been translating in rosetta in langauges that don't have kde-i18n-xx and so miss the entry.desktop file
<pitti> Riddell: and I added the zh_TW one today
<pitti> Riddell: do you have a list of the missing ones?
<Riddell> no, was about to go through them all and check
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight-7 released | Distro Team Holiday 19/05 -- Don't expect life
<Keybuk> ah, comedy
* Keybuk watches with amusement as his neighbours run out into the garden to get their washing in
<Keybuk> sudden unexpected downpour
<ogra> hehe
<pitti> mdz: nevermind, I'll do my best to finish the tbird locale stuff today
<pitti> infinity: bah, 1.5.0.2 source is not even there yet :(
<infinity> pitti: Yeah, I'm seeing that...
<pitti> infinity: how much can we trust the upstream XPIs to actually work?
<infinity> pitti: The fact that I missed the published run 1.5 hours ago by all of 2 minutes was irritating.
<pitti> infinity: I have the new tbird-locales package ready, but I didn't test the debs yet
<infinity> pitti: I dunno.  You tested all the 1.5 ones.  Did they all work?
<pitti> yes
<infinity> That's about the best answer you're going to get, then. :)
<infinity> I expect most of them didn't even change.
<Kamion> mdz: I now know roughly how to fix the fact that if you select the auto-resize option in partman, other partitions don't get automounted
<pitti> infinity: one possibility is to assume the best, upload, and fix possible breakage in a followup upload
<Kamion> mdz: unfortunately it's not entirely simple
<infinity> I doubt any strings changed in Tbird itself.
<infinity> pitti: If one of us remembers to go and test all the debs later, I'm cool with that approach.
<Kamion> mdz: given that breezy had this bug too, I'm inclined to defer it and do it first thing edgy now that I actually understand it, if you agree
<mdz> Kamion: what's the issue?
<pitti> infinity: I will do
<bddebian> Kamion: Thx for all the syncs/removals, etc
<Kamion> mdz: when partman does autopartitioning, it clears out all the old state that you selected in the manual partitioner, to avoid serious complications if they overlap in weird ways (e.g. two mountpoints the same)
<infinity> pitti: Since there's no correlation whatsoever between upstream XPI versions and the source package version, it's nice and trivial for you to roll back one or two broken ones, so I say "go for it"
<Kamion> mdz: unfortunately that includes the preset /media/* mount points
<pitti> infinity: I agree
<Kamion> bddebian: no problem, needed to catch up
<pitti> infinity: since the current debs won't work at all, it can't be a regression :)
<mdz> Kamion: if you're not comfortable with fixing it at this point, I'm with you
<Kamion> mdz: the fix is to just do the automounting again after applying the autopartitioning recipe, but I either have to duplicate a big wodge of code, or move it to somewhere common
<bddebian> Kamion: Do you know if you have more?  I thought I had some for libspoon-perl, libspork-perl etc?  Or maybe they are still UVFs?
<Kamion> probably move it to an update.d script protected by an "only run once" flag that we clear out on autopartitioning
<Kamion> but yeah, it's too late really, and for a non-regression I think I'll leave it
<Kamion> bddebian: I believe the archive admin queue is pretty much clear now; I certainly don't remember seeing the ones you mention
<bddebian> Kamion: OK, thx, I'll check
* infinity sure would like to know what drescher did to that Tbird upload...
<mdz> gar, debconf network has just gone back to shit mode
<infinity> 15:03:13 ERROR   Failure processing queue_item 33675
<infinity>  -> http://librarian.launchpad.net/2732016/7GJT1LOnsOKQGxmoLcyhgJDEsQy.txt (ERROR:  could not serialize access due to concurrent update
<infinity> \o/
<mdz> infinity: one for #launchpad perhaps?
<infinity> mdz: I suspect the next publisher run will go fine anyway.
<infinity> (And there are no soyuz folk around at the moment)
<infinity> Kamion: I need to crash (40 hours up now, whoops)... Can you watch the next publisher run and see if it does that again?
<Kamion> infinity: ok
<Riddell> pitti: lanaguges missing an entry.desktop file are am az be co fa fo gl hr id ka km ko ku lo lv mn ms mt no rw sq ss th uz ve xh zu
<Riddell> pitti: what's the best form for me to give them to you in?
<sivang>  Kamion -weird does not work, moving to the other 2
<phanatic> pitti: bug 45144 - i've uploaded a possible fix. if you have some time, please check it. thanks!
<Ubugtu> Malone bug 45144 in sysinfo "sysinfo returns garbage when opened without gcc installed" [Normal,In progress]  http://launchpad.net/bugs/45144
<sivang> Kamion: -ordinary also errors same way
* sivang is moving to the last one (-stripped)
<zul> pitti: i can take a look at it tonight if you want for the sysinfo
* bddebian gives Kamion more work :-)
<Kamion> Mithrandir: still around?
<Kamion> sivang: damn, might be worth testing breezy as well when you have time to see if that works ...
<Kamion> bddebian: won't be me, I imagine
<Kamion> Mithrandir: I need a casper upload RSN
<bddebian> Kamion: What do you think the possibility of getting a Universe archive admin might be?
<bddebian> Obviously not for Dapper :-)
<sivang> Kamion: can't we just bug fedora people to let us into the correct magic for booting there? :)
<sivang> or to hand hold us until we're on our feet..
* HiddenWolf hugs keybuk
<Kamion> bddebian: requires significant improvements to the Soyuz UI; once that's done I expect we'll look into it
<Kamion> because at present archive administration involves shell access to the master archive system and essentially total archive write privileges
<Kamion> needs to be doable remotely before we can farm it out reasonably
<Tonio_> hi everyone
<bddebian> Kamion: Fair enough, thx
<sladen> ...how do you debug an application that uses ptrace...?!
<sivang> Kamion: now testing the last -stripped
<Kamion> I doubt it will differ from -ordinary
<sivang> Kamion: yes, it did not. failed the same :-(
<Kamion> damn
<Kamion> well, with any luck the yaboot/gcc-3.3 thing will at least fix G3s; we'll see
<bddebian> yaboot ugh :-(
<sivang> Kamion: you mean, it needs to be built with 3.3 to work ?
<sivang> (rather then 4.x)
<pitti> Riddell: that's fine, I add it to my todo list
<pitti> zul: that would be great!
<Kamion> sivang: I don't know
<Kamion> sivang: that's what I'm trying to find out
<pitti> zul: I have some nitpicks, I'll answer in the bug
<sits> sladen: interesting question...
<pitti> zul: answered
<sits> sladen: I guess you need a kernel debugger
<sivang> Kamion: would you think there would be any point in checking IBM's docs for an example/suggestion how to configure yaboot to boot there?
<Kamion> sivang: no
<Kamion> I think it extremely unlikely that anything useful would be found there
<zul> pitti: great ill take a look at it tonight
<Kamion> I mean don't let me stop you if you want to
<pitti> Riddell: jeez, that's a huge list :(
<sivang> well, I don't want to waste my time there if we already have all the right mkisofs flags and yaboot config set, and are puzzled by why it won't find boot.msg or boot, just if we're not sure about everything :)
<Riddell> pitti: most of them have entry.desktop files in SVN that I'm extracting
<Kamion> sivang: I'm sorry, I just can't deal with it right now :(
<pitti> Riddell: so for this list, the kde-i18n-XX package has entry.desktop, the flag picture, and so on, but l-pack-kde-XX-base hasn't?
<sivang> Kamion: sure thing, I apologize for having bugged you even. let's talk about this after release :)
<Kamion> if the possible fix we had in hand had fixed it, that would've been great, but ...
<Kamion> sivang: I'm still interested to know whether breezy boots
<Riddell> pitti: no, for this list the KDE translations is below the level needed for KDE to release a kde-i18n-xx, so there is no package with the required entry.desktop file
<pitti> Riddell: aaah, I see; that explains the issue
<sivang> Kamion: I'll have an answer for you next sunday then. 
* sivang wgets a breezy powerpc
<sivang> s/next/up-coming/
<sladen> sits: it's working now.  It injects some rootkit into the parent process to make it chdir().  *evilgrin*...
<sladen> sits: or some reason keybuk said he wanted a  /bin/cd  to speed up dpatch
<Kamion> sivang: thanks
<sivang> Kamion: you're more then welcome.
<sivang> using wget -c http://releases.ubuntu.com/5.10/ubuntu-5.10-install-powerpc.iso
<sivang> hope this is okay (the url)
<Riddell> pitti: http://kubuntu.org/~jriddell/tmp/lang-extras.tar.gz  that's from KDE's SVN for a good number of them
<Riddell> the rest will just have to do with simple entry.desktop files if you can make them
<pitti> Riddell: thanks, I'll add them
<Kamion> Mithrandir: [fairly urgent]  could you please merge and upload http://people.ubuntu.com/~cjwatson/bzr/casper/preseed/ ? Thanks
<pitti> Riddell: hm, they just have the language name, but not a full locale
<pitti> Riddell: hm, ok, that should be fine
<Kamion> Riddell: ^-- should fix KDE language pack installation in ubiquity, along with a cdimage fix I made recently
<Riddell> Kamion: excellent, thanks
<Kamion> I think decent handling of install.py crashes will just have to wait until after dapper now :(
<Mithrandir> Kamion: yes, willdo in a second.
<Kamion> thanks
<pitti> Riddell: I added your tarball, that leaves us with 4 missing ones
<Riddell> pitti: want me to make up simple entry.desktop files for them?
<pitti> Riddell: that would be nice
<zul> mdz: ping
<pitti> Riddell: is 'charset' important?
<Riddell> I think it defaults to utf-8
<pitti> Riddell: today's packs are already built. I'll test the ones from tomorrow or Saturday and if they are good, ask cprov to upload them during the weekend, so that we have good ones at Monday; does that work for you?
<mdz> zul: yes?
<zul> mdz: sorry unping
<Riddell> pitti: that's good for me
<pitti> carlos: any chance to further reduce the number of missing domains until tomorrow?
<Riddell> pitti: what are the 4 you're missing?
<pitti> Riddell: am co no ve
<sivang> does anybody know if usermod -d $HOME will create the hom folder even if this is a new user and not changed one? after invetigating some more around bug #18632 it appears that the problem is the s-t-b thinks that the last user-conf xml entry (holding the new user after another one was removed) belong to the removed users, and uses usermod instead of adduser on the current user details. this results in the home dir not created. 
<Ubugtu> Malone bug 18632 in gnome-system-tools "Users and groups-tool failed to create home folder after deleting user and adding a new user in the same operation" [Normal,Confirmed]  http://launchpad.net/bugs/18632
<sivang> now acocording to usermod's manpage, -d $HOME will instruct it to create the home. checking the code I see that s-t-b does use this flag
<mjr> 33
<Riddell> pitti: looks like kde has 'no' as 'nn' and 'nb'
<Riddell> Mithrandir: what's the relationship between those languages?
<Mithrandir> nn and nb are forms of no, but no as a language code is deprecated and shouldn't have been used in any translations for the last couple of years.
<Riddell> pitti: and ve is ven
<sivang>      $command = "$cmd_usermod" . " -d \'" . $$new_data[$users_prop_map{"home"}]  .
<Riddell> ah, but still no ven release from KDE
<pitti> Riddell: ok, so AFAICS the lack of a desktop file in -no is just fine then?
<Riddell> pitti: does rosetta export to no or nn and nb?
<Riddell> pitti: I've added am co ve http://kubuntu.org/~jriddell/tmp/lang-extras.tar.gz
<Riddell> oh, we have language packs for all three no nn nb codes
<Riddell> that's fine, the person can just pick the norwegian of preference and ignore no
<pitti> Riddell: right
<phanatic> pitti: applied your suggestions to bug 45144
<Ubugtu> Malone bug 45144 in sysinfo "sysinfo returns garbage when opened without gcc installed" [Normal,In progress]  http://launchpad.net/bugs/45144
<pitti> phanatic: great!
<mdz> 79% packet loss
* ..[topic/#ubuntu-devel:bddebian] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight-7 released | Distro Team Holiday 19/05 -- Don't expect life
<bddebian> Hmm, I'm not getting any accept/reject messages.  Is that known?
<mdz> so if I don't respond, that's why ;-)
<pitti> Riddell: added
<pitti> Riddell: shall I crank up new daily builds right now for you to test? or will tomorrow's be good enough for you?
<Riddell> pitti: great, our Georgian translators will be most pleased
<Riddell> I'm about to go out canoeing, tomorrow is fine
<pitti> alright
<pitti> I'm off to the cinema, too
<pitti> BenC: the current kernel does not list CVE numbers; can you mark the fixed ones in the wiki page so that I can mark them as fixed manually in ubuntu-cve?
<Riddell> whoever's approving NEW queue: can you tell me what happened to kexi-mdb-driver?
<BenC> pitti: Yeah, that's what I was going to do
<Kamion> Riddell: nothing in particular, I'll do it now
<Kamion> sorry for the delay
<Riddell> Kamion: ah, still there, that's fine
<Kamion> accepted
<Riddell> thanks Kamion 
<BenC> Kamion: linux-source should show some finished builds in the next hour, and I'll upload l-r-m and l-m
<desrt> mm.. new linux-source
<desrt> BenC; my employer compels me to ask if it contains hugepages
<BenC> desrt: damnit...too much going on and I forgot...really sorry dude
<BenC> I can put it in for the first update
<desrt> as in, won't make it for dapper?
<jdong|coreduo> BenC: dapper will get updates?
<BenC> desrt: it wont be in the initial dapper release
<desrt> BenC; :(
<desrt> BenC; any idea how long the wait will be?
<BenC> jdong: there are always security updates, and we tend to sneak some minor things in with them
<jdong|coreduo> BenC: I see
<desrt> if too long i'll roll my own
<BenC> desrt: I don't expect more than a week or so before pitti will be emailing me with some dapper CVE's :)
<jdong|coreduo> BenC: do you know if we'll be using dapper-updates for providing bugfixes in general?
<desrt> ok.  cool.
<desrt> does this mean that dapper will be shipping with a -23 ABI?
<BenC> jdong: outside my realm of knowledge
<dholbach> jdong|coreduo: for eyeballable, critical fixes
<BenC> desrt: yeah, -23 is the final ABI
<desrt> BenC; awesome.  looks like i win the pool :)
<jdong|coreduo> dholbach: cool
<dholbach> jdong|coreduo: dapper-backports for the general "good to have / user cry for" backports
<BenC> desrt: there's a pool, and no one let me play it? :)
<desrt> BenC; you're not allowed :)
<jdong|coreduo> dholbach: wonderful :). I'm pumped :)
<HiddenWolf> BenC: Congrats on the last? kernel. :)
<BenC> thanks, and congrats to everyone else for dapper
<BenC> the whole ubuntu team defnitely rocked this release
* Mithrandir sighs
* bddebian consoles Mithrandir
<HiddenWolf> BenC: still rocking, really. :)
<jdong|coreduo> BenC: likewise; congrats on the kernel work. You guys have done a great job with this release
<Mithrandir> Kamion: uploaded, finally.
<mdz> janimo: is xubuntu-docs (and thus the xubuntu livefs build) fixed now?
<janimo> mdz: should be as of last night
<janimo> mdz: did not check the actual livecd build log though
<janimo> mdz, yes. http://people.ubuntu.com/~lamont/liveLogs/dapper/xubuntu/20060518/livecd-20060518-i386.out
<mdz> janimo: great, thanks
<Kamion> Mithrandir: thanks
<desrt> ogra; ping
<ogra> desrt, pong
<ogra> oh, right
<desrt> :)
<ogra> thanks fotr reminding
<desrt> i have a new version of the patch
<desrt> should i put it on launchpad?
* ogra jumps on g-s-s
<ogra> yeah
<desrt> k
<desrt> uploading now
<ogra> great, thanks
<Kamion> meh, publisher still blowing up
<BenC> Kamion: ok, amd64 built successfully, the rest should follow soon, uploading l-r-m and l-m now
<Kamion> yep, amd64 already newed :)
<jdong|coreduo> Kamion: does Backports go through ubuntu-archive now?
<Kamion> publisher seems to have refrained from blowing up this time
<Kamion> jdong|coreduo: if there's a process for it, I'm not aware of it
<Kamion> I suspect the auto-backport tool has not been ported to soyuz yet
<jdong|coreduo> Kamion: who should I go to to figure this out?
<Kamion> elmo, cprov, or Kinnison
<Kamion> (Kinnison is on holiday this week so not him)
<BenC> Kamion: everything uploaded...I leave it in your capable hands now
<BenC> Kamion: ping me if you need anything
<Kamion> righto, thanks
<setuid> I'm trying to take an upstream kernel from kernel.org and build it as an installable .deb package with the exact same features/.config as my running Dapper 2.6.15-22 kernel. What is the best way to do this? 
<mdke> setuid: see the numerous guides on the wiki. If in doubt, ask in #ubuntu
<desrt> setuid; you should know that the ubuntu kernels have some extensive patching done to them so an upstream vanilla kernel will, by definition, not have the same features
<mdke> https://wiki.ubuntu.com/KernelBuildpackageHowto
<setuid> I know there's a dance with the config in /boot, renaming some dirs in the debian source tree, then copying ./debian recursively into my clean tree. 
<setuid> But its not straighforward. 
<BenC> setuid: no, you are wrong so far :)
<setuid> desrt: Its specifically the patches I want to remove from the build process
<BenC> setuid: cp /boot/config-`uname -r` .config
<setuid> BenC: Then the people in #ubuntu+1 are wrong, as of a month ago 
<BenC> make silentoldconfig
<desrt> setuid; file bugs :)
<BenC> make-kpkg kernel-image
<setuid> BenC: And the weird initrd that dapper seems to require (even though in 10+ years of using Linux, I have never ONCE run a distro that required an initrd) 
<desrt> woh.  that's easier than i thought.
<BenC> you will lose _a lot_ of features (mainly drivers)
<setuid> Why would I lose drivers, if the kernel .config turns them on? 
<BenC> setuid: weird? initrd's are the prefered way to boot
<jdong|coreduo> setuid: initramfs? It's one command to generate an initramfs!
<BenC> setuid: because the vanilla kernel doesn't have all the drivers we do
<desrt> setuid; because the drivers do not _exist_ in the kernel
<setuid> BenC: initrd is not required, unless you are booting from esoteric hardware (booting from RAID, or AFS or such) 
* mdke waves the off topic flag
<setuid> desrt: Oh, binary-only stuff, sure. 
<setuid> I don't use that. 
<desrt> ...
<desrt> setuid; are you trying to troll?
<BenC> sedtuid: it's not a requirement, it's the prefered way to boot a system, especially a distro
<BenC> setuid: no, not binary-only stuff, real open-source drivers that are just not in the vanilla kernel
<setuid> Not at all, I've been building thousands of kernels for Debian for years (I _did_ write the HOWTO on it), so I'm not exactly a stranger to this. It works cleanly everywhere, but Dapper (and Red Hat) are very unique beasts. 
<setuid> BenC: My Thinkpad does not require any non-kernel drivers. 
<setuid> So that's fine. 
<BenC> setuid: if you wrote a HOWTO for Debian, then how do you not know how to use make-kpkg for all of this already?
<setuid> Upstream vanilla kernel source works fine here, just that it refuses to boot because of the weird hooks Ubuntu has put into the initrd
<mdke> setuid: regardless of how good you are, you're still off topic
<setuid> BenC: Kernel howto, not kernel howto for Debian
<BenC> yeah, that's true too
<setuid> mdke: How is Ubuntu kernel development off topic here? 
<desrt> setuid; how about modules for the root filesystem so that they need to have drivers for every filesystem/scsicard/etc/etc built-in to the kernel that everyone who runs ubuntu is then forced to use?
<mdke> setuid: you're asking for help with building a kernel
<BenC> you aren't talking about development of anything
<mdke> setuid: #ubuntu can definitely help. As for this channel, see the penultimate paragraph of https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-May/000136.html
<BenC> nor are you talking about the ubuntu kernel
<Kamion> the reason we use an initramfs is because there is no other reasonable way to build a generic kernel that supports all the stuff our users might try to use, simultaneously
<setuid> I'm not asking how to build a kernel, I'm asking how to build a proper kernel package for Ubuntu, so I can test our usb drivers against it. 
<setuid> er, usb support (not drivers)
<mdke> setuid: right, it's the same thing. Go to #ubuntu
<Kamion> if you're building a custom kernel that has just what you want, sure, you don't need an initramfs then
<BenC> setuid: why not build the drivers against the stock ubuntu kernel?
<setuid> BenC: Because the kernels in Ubuntu (and most of the packages) are several months behind current
<BenC> setuid: all you need for that is the linux-headers-2.6.15-* packages
<setuid> udev, libusb, things like that are quite a bit behind most other distros
<setuid> And the kernels are a month or two back 
<BenC> take it to #ubuntu or #ubuntu-kernel
<setuid> Yep, will do 
<setuid> Didn't know about #ubuntu-kernel
<mdke> phew
<setuid> #ubuntu is all entry-level noobs, hard to cut through the noise to get useful responses
<desrt> something to add to the HOWTO, perhaps :)
<setuid> desrt: Where's the #ubuntu-channel-fu HOWTO? 
<desrt> setuid; on the web?
<mdke> setuid: on the wiki
<setuid> Teh Intarweb? ;) 
<setuid> I'll poke around in there
<desrt> setuid; try googling "ubuntu irc channels"
<desrt> you'd find https://wiki.ubuntu.com/InternetRelayChat pretty quickly
<mdke> Kamion: spiv has told me that he's got a cvs file filled with all people who have edited the wiki and their email addresses, ready for sending the WikiLicensing email. What shall I do with it when he sends it to me, who is a good person to send the email?
<Kamion> mdke: oh, grief, I'd forgotten entirely about that
<mdke> yeah, time has gone by
<Kamion> mdke: would you be willing to do it? I see no reason why you'd be inappropriate
<Kamion> you've been spearheading the effort
<mdke> Kamion: sure, no problem. I have the text, after all
<desrt> GFDL4U?
<mdke> desrt: you'll have to read the spec.
<mdke> wiki:WikiLicensing
<lemsx1> can i pick somebody's brains for a second? i have an issue with applications running from initramfs that is driving me nutz
<Kamion> mdke: thanks
<lemsx1> when Ubuntu's unicode_start (or stop) app is launched, it seems to corrupt something that causes the whole boot process to stop (that's early rcS.d level)
<desrt> oh man.  public domain.
<desrt> mdke; people will scream.  loud.
<Kamion> can we not go over this *yet again*?
<mdke> desrt: feel free to discuss in /query or #ubuntu-docs or something
<mdke> bearing in mind again https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-May/000136.html
<lemsx1> infinity: ping
<desrt> mdke; i don't care.  i'm only a trivial contributor to the wiki.  just saying, others probably will care.
<Kamion> lemsx1: that's well post-initramfs
<desrt> (end of topic)
<mdke> ok
<lemsx1> Kamion: yes. it makes me think that a filehandle is kept open from the daemon that is launched (our process) inside initramfs by the time that rcS.d keymap.sh or whatever is executed
<lemsx1> Kamion: i know you guys don't have those issues with USplash, and the only difference between usplash and what we are doing, is that we are listening for keyboard events (ESC and F2 keys)
<ogra> omeg, around ? 
<lemsx1> Kamion: turning off the code for the key event loop doesn't fix the issue though
<Kamion> lemsx1: ah, you probably will need infinity then, sorry
<Kamion> or at least somebody with a clearer head than I have right now
<lemsx1> Kamion: yep. infinity promised me some time to deal with that issue...
<lemsx1> Kamion: no problem. i'm not hoping to get this problem fixed today. today's Thursday after all ;-)
<ogra> desrt, uploaded, in case you missed it ;)
<desrt> ogra; awesome.  thx :)
* desrt just waiting on seb for an upload now :)
<ogra> do you want to close the bug ? 
<desrt> sure.
<ogra> great, thanks :)
<janimo> dholbach: hi, you seem not to be able to reproduce the gnumeirc bugs?
<dholbach> janimo: no
<dholbach> janimo: you are?
<janimo> so it may be somehting borked at the reported
<janimo> reporter
<janimo> I did not try, just wanted to make sure before investigating that it's not somthing invalid
<janimo> it would be another issue if it was clearly gnumeric vs gnumeirc-gtk instead of some misconfiguration
<Gloubiboulga> I try to read the file with gnumeric, but with the 2 libgoffice variants
<janimo> Gloubiboulga: good thinking.
<desrt> dholbach; save my icons!
<desrt> <ahem>
<desrt> dholbach; i seriously have two shutdown icons on my System menu
<Gloubiboulga> janimo, dholbach, I can't reproduce the bug using gnumeric/goffice or gnumeric/goffice-gtk
<dholbach> Gloubiboulga: me neither
<dholbach> desrt: ?
<desrt> dholbach; the bug i asked you to look at
<desrt> dholbach; the problem is taht there are now two pictures of a power switch in the icon theme
<desrt> dholbach; one is called "gnome-shutdown" and the other called "gnome-logout"
<desrt> the "gnome-shutdown" one is a bit ugly and ought to be replaced with the nice-looking new power switch (which unfortunately got called "logout")
<dholbach> desrt: I know - I get mail for bugs sent by launchpad already
<dholbach> let's do the discussion at the bug report
<desrt> dholbach; i just don't understand how this isn't seen as a bug
<dholbach> I didn't reject it and there are more important bugs flying around - sorry if this is annoying for you.
<desrt> true.  mark rejected it.
<Spec> heya, anyone wanna help with the discussion on how one(I?) would go about implementing: https://wiki.ubuntu.com/AutoUnmountNotifications
<neutrinomass> Spec: As you already know, I agree with this spec. Probably the way to implement it would be through g-v-m which AFAIK is responsible for mounting stuff. You will want to distinguish between various device types because it is OK to remove usb audio devices while they are working .
<mdke> Spec: it's something to discuss when the developers have finished with dapper
<neutrinomass> mdke: Are suggestions for new specs postponed until after dapper ?
<mdke> neutrinomass: no, but it's best to discuss elsewhere until then
<Spec> true, it's most certaintly not going to be included in dapper :p
* sivang -> back
<wasabi> I'd very much like to see g-v-m go away, and the mounting job be taken up by another type of service.
<wasabi> Perhaps g-v-m stay on as a per-user policy engine. But I want to be able to auto mount things without a desktop present.
<wasabi> Makes sense to me that you should always be able to plug in a removable device, and have it appear in /media, regardless whether you're at a console or what.
<Burgwork> wasabi, isn't that what fuse is supposed to solve?
<wasabi> Not really.
<wasabi> Fuse is pretty much totally unrelated.
<Spec> wasabi: I agree with you. Automagic mounting should be a service not dependent on gnome
<_ion> ivman - daemon to auto-mount and manage media devices
<wasabi> I don't think there is really a need for a daemon for that either. Probably just some hot plug invoked action.
<Kamion> fuse solves the problem of "I want to mount this thing as a filesystem but it's not in the kernel yet / is too complicated to ever go in the kernel"
<wasabi> I'd like to see Fuse used for smbfs and friends.
<wasabi> Or maybe just smbfs get better. Either one. :0
<wasabi> I'd really like it to work as smoothly/integrated as windows. You just have a path, and you use it... and it works in all apps.
<wasabi> Because it's implemented in the kernel VFS.
<wasabi> I sort of visualize a namespace for smbfs/other network/temp mounts, /media/smbfs/$ip/share.  Mounted only once, on demand, and umounted on idle.
<wasabi> gnomevfs smbfs just being a wrapper that initializes the maps that path.
<wasabi> Some sort of per-FS type policy engine that handles that, including knowing whether it is Fuse, or kernel based, and if so, whether it needs to mount once-per-user or once-per-system.
<ogra> wasabi, have a look at ltspfs and ltspfsd :)
<wasabi> Would very much like to use that for NFS as well.
<wasabi> I do not like having to set up static mappings on all of my boxes in fstab... or use the hack that is autofs
<wasabi> Would prefer to be able to browse to nfs://systemname/export  and have it Just Work.
<ogra> thats the aim of ltspfs 
<wasabi> Or maybe I wouldn't have a problem with autofs if it didn't suck so bad. ;0
<wasabi>  /media/auto/nfs/server/share, and it auto maps that on demand.
<wasabi> I like autofs.. just don't like it's configuration and staticness. You need to be able to make up paths.
<wasabi> Sounds like a fun fuse project actually.
<omeg> Does anybody have the Xubuntu logo for me in SVG (or high quality 32-bit PNG)? There's a link to it on the Wiki somewhere, but when I try to save it, it tries to save the HTML page instead.
<ogra> oh, omeg !
<ogra> omeg, the edubuntu plash will need some love for the fonts
<ogra> *splash
<ogra> the "ok" and progressbar are way to dark
<crimsun> omeg: nice work on the splashes, btw. :-)
<ogra> absolutely !
<omeg> ogra: you mean the one I just added to the wiki? You guys sure are on top of the current events... :)
<ogra> i'd still have preferred the "logo only" varinat though
<omeg> Thanks, crimsun.
<ogra> omeg, the one you added this morning
<omeg> I added an edubuntu logo this morning? Depends on which morning you mean. It's evening here. This is the image I just put up on the wiki: http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_newsuggestion_0_8_SCALED_BAR.png
<ogra> omeg, i sit in germany :)
<ogra> perfect !
<bddebian> Bah, where's pitti :-(
<omeg> Do you think it's okay? I think the "OK" text needs to be a little brighter.
<ogra> bddebian, we're all expected not to work tomorrow :)
<bddebian> pfft :-)
<omeg> For some strange reason, it actually ended up being 15 colors instead of 16. I have no idea where that extra color went. I thought I forced a hand-picked palette of 16.
<ogra> omeg, i dont mind its already more readable than the breezy one ;) 
<ogra> i'm fully in your hands here :) 
<omeg> I wonder if 15 colors would be a problem. I'll just add an arbitrary color to the palette.
<ogra> yep
<janimo> omeg, https://wiki.ubuntu.com/DapperXubuntuLogo is this good?
<Kamion> BenC: amd64, powerpc, sparc all through; I'm off for dinner now, so if somebody else is around to shepherd the rest, that'd be ideal, if not I'll do it and upload my pending d-i source when I get back
<omeg> janimo: yeah, thanks, but when I try to save the image, it just tries to save the HTM file.
<omeg> Hmm
<AlinuxOS> hile, Im searching for cjwatson :) Is he sometimes present here?
<Burgwork> AlinuxOS, cjwatson is Kamion 
<ogra> AlinuxOS, yes, he's at dinner now
<AlinuxOS> :)
<AlinuxOS> ogra, thank you
<AlinuxOS> are you together somewhere  ? :)
<AlinuxOS> I mean Ubuntu team ?:)
<AlinuxOS> devel-team :)
<ogra> yes, here in that channel :)
<ogra> and in paris in 4 weeks
<AlinuxOS> :) hehe
<AlinuxOS> Paris why ?
<AlinuxOS> some meeting ?
<ogra> https://wiki.ubuntu.com/UbuntuDeveloperSummitParis
<AlinuxOS> hehe great
<AlinuxOS> ogra, ;)
<omeg> Hmm
<dholbach> mdke: heya! are you aware of scrollkeeper saying: I/O warning : failed to load external entity "/usr/share/ubuntu-docs/zh_TW/preface.xml"?
<omeg> I just can't seem to grab that transparent PNG nor the SVG due to the way it's attached to the wikipage.
<ogra> dholbach, heh, i just wanted to ask you about it 
<AlinuxOS> All notifications should be sent by May 15th. No more sponsorship requests are being considered.
<AlinuxOS> eh, too late for me :(
<omeg> Anybody want to help me grab that Xubuntu logo so I can make a splash screen for it?
<omeg> I feel really dumb for not being able to!
<mvo_> Kamion: still up? are you interessted in dvd test results?
<dholbach> mvo_: he's off for dinner
<bddebian> omeg: What site are you trying to pull from?
<mdke> dholbach: yeah, i fixed it in the repo
<dholbach> ok cool
<mdke> dholbach: you can upload if it's causing bug reports, but otherwise we can wait until next week
<dholbach> waiting till next week is fine
<mdke> cool, I should have our last batch of translations in the repo by the end of sunday
<dholbach> can anybody help me with finding out while powerpc is giving scrollkeeper a bad time:  https://launchpad.net/+builds/+build/195893 ?
<dholbach> it fails for me too, but I don't exactly know why
<mvo_> dholbach: ah, thanks
<omeg> mdke: https://wiki.ubuntu.com/DapperXubuntuLogo
<mdke> thanks but no thanks
<mdke> omeg: got the wrong guy
<dholbach> urg, ok - can somebody tell me, why the build on powerpc prefers to have a /usr/lib/libscrollkeeper instead of /usr/lib/libscrollkeeper.so ?
<bddebian> wtf?
<omeg> Er
<omeg> Yeah
<omeg> bddebian: https://wiki.ubuntu.com/DapperXubuntuLogo
<mdke> omeg: what's the problem?
<bddebian> omeg: You can't just click on the Inkscape source link?
<dieman> Kamion: poke
<dholbach> dieman: he's out for dinner
<dieman> oh
<dieman> he was saying an autorepsponder i was using wasn't detecting malone messages right and ignoring them
<dieman> but i can't quite figure out where an autoresponder is sposta figure out what the heck to do with malone mail
<omeg> bddebian: it tries to save a HTM page when I do that.
<mdke> omeg: https://wiki.ubuntu.com/DapperXubuntuLogo?action=AttachFile
<mdke> click on "get"
<omeg> Thanks.
<omeg> Well, that sure was simple.
<omeg> :P
<bddebian> Hey, steal my thunder.. :-)
<reconcilliation> The Update manager is cool but when it opens initially the whole interface opens. This is not needed because sometimes there is no updated available. What would be better is if  the whole interface opened after the dialog box with a progress bar checks to see if there are updates and not at the same time.
<dholbach> reconcilliation: Hello
<reconcilliation> hello there
<dholbach> reconcilliation: It might make more sense to look if there is already a bug filed and if not to file a bug with your suggestion
<dholbach> http://launchpad.net/distros/ubuntu/+source/update-manager
<dholbach> things tend to get lost on IRC
<ogra> bddebian !!
<ogra> root <root@archive.bddebian.com.bddebian.com>
<dholbach> rock on
<reconcilliation> Ok, cool. 
* ogra shakes head+
<dholbach> ogra: nevermind - Matt did that too, once :)
<ogra> wow, the changelog is even better *g*
<dholbach> <somebody>@localhost
<mvo_> reconcilliation: thanks for your suggestion, please file a wishlist bug, but patches are very welcome too :-D we will not be able to do this for dapper I'm afraid
<ogra> .
<ogra>    [ root ] 
<ogra>    * GNU config automated update: config.sub     (20050422 to 20050708),
<ogra>      config.guess     (20050422 to 20050803)
<ogra> :)
<dholbach> bddebian: ogra is sooo picky :-p
<ogra> nope, i just didnt sleep since 40 or more hours
<mdke> hard ass
<mvo_> ogra: that is a bit verbose, no ;)
<ogra> and am just hanging around before falling in my bed :)
<dieman> aha
<mvo_> what is todays deadline? 12utc?
<dieman> Kamion: n/m
<bddebian> ogra: What was that for?
<ogra> mvo_, yep, then we'll get auto-logged-out
<mvo_> ogra: woah!
<ogra> ALL OF US !
<bddebian> ogra: No, I meah which package?
<dholbach> bddebian: httrack
<dholbach> or htcheck, whatever :)
<bddebian> htcheck?
<bddebian> Why did it use that?  That was Hobsee's patch?  WTF?
<ogra> bddebian, dont worry
<bddebian> No, I'm trying to understand?  It was Hobbsee's changelog entry and I used -kbddebian@comcast.net??
<dholbach> bddebian: i swear: if we find that guy who hacked your machine, we'll make him pay :-p
<ogra> thats only the signing key
<ogra> haha
<dholbach> bddebian: what did you type?
<ogra> bddebian, 	Accepted gnome-screensaver 2.14.1-0ubuntu5 (source) ... Changed-By: Ryan Lortie <desrt@ubuntu.com>
<ogra> bddebian, i did upload that one  ...
<ogra> -k only uses your key but doesnt touch the maintainer and changed by fields
<mdke> Kamion: having some issues with sending this email: evo isn't handling a 4500 strong addressbook very well. I will try cutting it down into chunks. Do you think it is sensible to do a To: community-council, and Bcc: the rest?
<Kamion> AlinuxOS: hello?
<Kamion> mvo_: definitely interested
<dholbach> bddebian: look at sistpoty's newest changelog entry on dapper-changes
<dholbach> hey thom
<thom> hey
<Kamion> dieman: pong, I don't remember saying that though
<mvo_> Kamion: I had no luck with the i386-dvd unfortunately
<AlinuxOS> Kamion, buon appetito :)
<AlinuxOS> Kamion, done ? :)
<mvo_> Kamion: the live-system does not boot, it complains that it can't find a casper kenrel (I can recreate the exact error, need to reboot for this)
<dholbach> thom: that music site you suggested is shipping to germany too expansive - I should make sure to visit you every once in a while :-p
<Kamion> mvo_: meh - am interested in what the exact error is though, and what the screen looks like when it appears
<thom> heh, seems like a good plan
<dholbach> thom: although their amount of good music is simply amazing
<Kamion> AlinuxOS: yes, although hopefully not hanging around for too much longer
<thom> or just bribe keybuk or kamion to bring you stuff to paris :-)
<Kamion> mdke: sounds sensible
<mdke> Kamion: thanks.
<AlinuxOS> https://launchpad.net/distros/ubuntu/+source/language-support-ka/+bug/30671
<Ubugtu> Malone bug 30671 in language-support-ka "ttf-bpg-georgian are GPL ttf fonts for language-pack-ka and GNOME interface." [Wishlist,Fix released]  
<thom> dholbach: yeah, it's a great site
<dholbach> thom: they'll be asked if "what? that big record case is all your luggage?"
<mvo_> Kamion: ok, give me some seconds
<AlinuxOS> thank you for your reply
<AlinuxOS> so can you explain me better what means "getting glyphs into unifont"?
<Kamion> AlinuxOS: I'm not getting involved with the bug in general - just thought that comment was worth making before somebody got sidetracked
<AlinuxOS> I'll refer it to our font maestro.
<Kamion> AlinuxOS: we use the font in the 'unifont' package for d-i
<bddebian> dholbach: I did dpkg-buildpackage -S -kbddebain@comcast.net.. ?
<Kamion> AlinuxOS: I don't know how it's maintained - I believe it's a GNU package
<HiddenWolf> mvo_: since the updates today update-notifier-popups started being misalligned again.
<mvo_> HiddenWolf: garr, do you have a screenshot or something?
<dholbach> bddebian: hum... well anyway - look at sistpoty's recent upload
<AlinuxOS> unifont - X11 dual-width GNU unicode font.   this one right?
<HiddenWolf> mvo_: send me a message in 10s and I will. :)
<bddebian> dholbach: Yeah, he just told me :-)
<Kamion> AlinuxOS: erm, sorry, wrong one, I meant bterm-unifont
<dholbach> ah right :)
<Kamion> which is built from bf-utf-source
<mvo_> HiddenWolf: please just email it to me, otherwise it will probably get los anyway :/
<Kamion> Description: Source for fonts needed to build Debian installers
<AlinuxOS> so what should we do to have georgian font support ?
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_32.png <-- do you think that this would adhere well enough to the Xubuntu colors in the logo?
<HiddenWolf> I will, but I need to trigger that popup. :)
<AlinuxOS> modify this source?
<AlinuxOS> adding our characchters?
<omeg> Hmm, might want to give maybe a little blob gradient to that mouse to make it stand out better.
<mvo_> Kamion: exact error is a error box with blue heading (looks a bit like win95) and: "Could not find kernel image /Casper/filesystem.kernel-386" (image is latest available via rsync)
<Kamion> mvo_: oh, ok, that one's fixed but the DVD hasn't been regenerated
<dholbach> heya seb128
<seb128> hi dholbach ;)
<Kamion> mvo_: I've started a DVD build now - shouldn't take too long to rsync once it's done
<mvo_> Kamion: ah, cool. let me know when I can rsync again
<Kamion> AlinuxOS: I believe so, you'd have to grab the source and look into how it seems to work though
<Kamion> AlinuxOS: I don't have any specific knowledge other than knowing where to point you
<AlinuxOS> Kamion, ok.
<ogra> seb128, its nearly friday, be careful or you have to pay drinks :)
<AlinuxOS> Kamion, thank you.
<seb128> ogra: that's friday to mdz's timezone, right? ;)
<seb128> so we still have time :p
<ogra> heh
<dieman> Kamion: i thought it was you, but i figured it out anyhow
<dieman> Kamion: gnarwl stupidly trys to work with reply-to
<HiddenWolf> mvo_: which e-mail adress do you prefer?
<mvo_> HiddenWolf: mvo (at) ubuntu.com should be fine
* ogra finally calls it a day
<bddebian> Gnight ogra
<omeg> There are bots that grab e-mail addresses from IRC chat?
<pygi> night ogra
<omeg> Night
<ogra> omeg, these channels are publically logged :)
<ogra> night all
<HiddenWolf> omeg: most people here have their e-mail adressess in half a dozen mailing list archives in plaintext
<seb128> mdz, Kamion: I would appreciate if one of you approved that intltool UVF exception request today so it can be upload before the some non-working days we have ;)
<HiddenWolf> omeg: launchpad lists e-mails in plain text too.
<Burgwork> omeg, http://people.ubuntu.com/~fabbione/irclog <-- these channels are all loggedhere
<AlinuxOS> http://www.teutonici.com/Alinux/BGP_Rioni.jpg  Simply a Georgian Ubuntu :)
<AlinuxOS> sorry for jpg extension.
<AlinuxOS> :)
<HiddenWolf> mvo_: sent. 
<nickrud> I'm running into some really wierd behavior while trying to change the icon on a panel launcher; for example, if I add the calculator the the panel via the right click option and examine the launcher, it claims there's no icon. I click the change icon button, it reads /usr/share/pixmaps, and then immediately selects the mozilla-firefox icon. Clicking again, I can then change the icon.
<mvo_> HiddenWolf: thanks
<Kamion> seb128: I'll have to read the diff through
<Kamion> seb128: you reckon it'll be required for dapper-updates anyway, though?
<Kamion> or just for edgy?
<seb128> Kamion: the situation is that no upstream GNOME tarball will build on dapper if we don't have it
<seb128> Kamion: so yeah, having it for dapper or dapper-updates would be appreciate
<Kamion> yeah, but are those tarballs ones we'll want to build on dapper?
<seb128> or some GNOME people will hate us for it
<seb128> many GNOME upstream guys use stable Ubuntu for some months and roll their tarballs on it
<Kamion> I see
<wasabi> Hey I like the logout dialog in xubuntu.
<wasabi> Smaller, more compact.
<seb128> wasabi: screenshot?
<dholbach> if we're going to get the 2.14.x tarballs into dapper-updates (as I heard of), we'd need it as well
<wasabi> one sec
<nickrud> I also looked thru launchpad, but can't really tell if any of those apply (is there a text search?)
<jdong> dholbach: ooh, gnome point-releases will be able to get into dapper-updates? :)
<dholbach> jdong: that was discussed, but I'm not 100% sure
<jdong> dholbach: cool. sound promising
<jdong> dholbach: btw, thanks for the quick response on that gnome mixer bug I filed. You guys never rest :)
<dholbach> jdong: seb128 never rests.
<seb128> lol
<jdong> lol
<dholbach> jdong: we had to make him work on upstream bugs and debian packages too, so launchpad could cope with him
<seb128> Kamion: if that's of any use for taking your decision they rolled most of GNOME 2.15.2 this week using the new intltool so they would likely have noticed a regression
<seb128> hi pitti
<wasabi> haha. man.
<wasabi> that is freaking weird.
<wasabi> this session stuff is making desktops not right.
<wasabi> Started xfce in a vncserver.
<wasabi> Different display. Launched it up. Tried to hit logout.
<wasabi> And my main X faded out.
<wasabi> And showed me my normal logout screen.
<pitti> hi
<Kamion> seb128: you have mail
<omeg> Anybody here able to give some feedback on a possible Xubuntu usplash screen?
<mdke> omeg: #xubuntu
<mdke> ?
<omeg> Well, most of the discussion regarding usplash screens has been going on in here, and I've gotten some helpful advice before, so I'll try my luck here first.
<omeg> #xubuntu also sounds like a giant channel with hundreds of people that would have the most arbitrary opinions about it. I'd rather get advice from here.
<seb128> Kamion: got it, thank you
<BenC> Kamion: sweet, only ia64 remains
<mdke> omeg: sounds like? try /who #xubuntu, or join it
<wasabi> seb128: http://akita.larvalstage.net/~wasabi/xubuntu.png
<wasabi> Looks cleaner.
<wasabi> Yeah, I just noticed it's missing some buttons though
* Kamion goes to fix up the seeds
<seb128> wasabi: right, sort of nice
<wasabi> Also the fade to a lighter color is nice.
<wasabi> Instead of fade to black.
<mdke> that is nice
<Burgwork> vuntz,  think upstream could agree on something like this for 2.16? --> http://akita.larvalstage.net/~wasabi/xubuntu.png
<seb128> Burgwork: upstream will not move of the current design they have I think
<seb128> they have no reason to do so
<wasabi> Also Xubuntu calls their logout item "Quit"
<wasabi> Heh.
<wasabi> I wish ours was called "Exit"
<seb128> it doesn't exit though
<wasabi> Because that's what it does. It's just an Exit menu item, like any other, it's just session wide vs app wide.
<seb128> it allow to lock screen, switch user, etc
<wasabi> Sure it does. The user leaves the environment, regardless what happens.
<mdke> seb128: that's a bug though *hides*
<seb128> wasabi: you can call everything exit then :p
<wasabi> Maybe even "Leave Desktop..."
<wasabi> Something. Log Out is wrong too. :0
<seb128> starting a new app change your environment too
<seb128> right
<seb128> but we didn't figure a nice word for it
<wasabi> Well, whatever option is chosen, the currently focused desktop becomes unavailable.
<wasabi> Has to be a nice simple understandable word for that. :0
<mdke> stop working
<wasabi> Go Away
<mdke> heh
<mvo_> pitti: any thoughts on #42002? should we just ask for the seed change?
<mvo_> (or rather ask if we can do the change)
<pitti> bug 42002
<Ubugtu> Malone bug 42002 in language-support-ko "Korean fonts are so ugly." [Normal,Fix released]  http://launchpad.net/bugs/42002
<mvo_> oh, fixed already?
<mvo_> cool :)
<mvo_> sorry for bothering you
<pitti> mvo_: I added them to l-support-ko
* mvo_ hugs pitti
<wasabi> Anyways I think the logout box is a monstrousity.
<pitti> mvo_: since I didn't get a really satisfying answer, this seemed like the least intrusive approach
<pitti> mvo_: yes, it was on my list of dapper milestone bugs, and I killed them all :)
<dholbach> night fellas
<bddebian> Gnight dholbach
<Kamion> dholbach: before you go
<dholbach> night bddebian
<Kamion> dholbach: do you happen to know if tangerine/tango belong in edubuntu desktop?
<Kamion> I'm doing a seed merge
<dholbach> Kamion: i think not - I think ogra uses gartoon icon theme
<dholbach> Kamion: but i'm not an expert at that
<Kamion> seems plausible
<Kamion> I've ignored the screensaver-default-images merge too, but ogra might want to overrule me later on that ...
<Kamion> ogra: I'm just guessing, but I suspect you might want to drop some bits of ship-live on non-powerpc ;-)
<Kamion> ogra: your merges from Ubuntu seeds look weird, btw - they never seem to actually show the merged revisions in 'bzr log', unlike merges done by other people
<Kamion> ogra: anyway, I wouldn't have merged ship-live yet except that I needed to merge seeds for the kernel ABI change, so sorry if that overflows stuff for you
<kbrooks> 19/05?
<kbrooks> oh.
<kbrooks> that's tomorrw (edt)
<pygi> thats today kbrooks :)
<kbrooks> pygi: i did say EDT
<pygi> kbrooks, I know, that's why ":)" :)
#ubuntu-devel 2006-05-24
<Kamion> mvo_: if you're still around, that DVD build is available now
<BenC> Kamion: will you trigger some CD builds after the installer is done?
<BenC> I'm ready to start testing some install/live-cd stuff
<mvo_> Kamion: cool, thanks
* mvo_ rsyncs
<Kamion> BenC: I was thinking more along the lines of going to bed
<BenC> Kamion: that's what I figured, but thought I'd ask :)
<BenC> you definitely need some sleep
<Kamion> really not well today
<jordi> Kamion: get some good rest!
<jordi> is mdz expected to be around later today?
<Kamion> no idea, I'm afraid
<Kamion> BenC: Ubuntu CD builds happen at 07:31 UTC, BTW
<mvo_> jordi: hello! you are not at debconf? 
<BenC> ah, good, I'll start some downloads tomorrow then
<Kamion> not allowed to work, remember :)
<Kamion> I guess you can stick the download jobs in at and let your computer work
<jordi> mvo_: nope
<jordi> a mosquito is here biting me repeatedly
<mdke> elmo: around?
* jordi goes in hunting mode
<Kamion> jordi: (FWIW, any new nano upload now requires a new debian-installer upload)
<jordi> Kamion: ugh
<jordi> so what should we do?
<Kamion> I have no idea, I'm too tired to think
<Kamion> I'll let mdz decide
<jordi> ok
<LaserJock> Kamion: is it Friday yet? ;-)
<AlinuxOS> Kamion, I've cheked btf-utf-0.005 source, and with fontforge checked georgian charactters and I found them in unifont.bdf :) (But they are soo ugly :O)
<mdke> LaserJock: another 34 minutes
<Kamion> well, if the ia64 kernel takes much longer, it can just wait until Sunday
<AlinuxOS> so in theory I can check georgian language termnal support.
<jordi> Kamion: the new patches aren't, but the crontab bug is pretty bad I think
<jordi> does not affect the default config tho
<AlinuxOS> but in terminal mode (no X mode) I see only squares.
<pitti> good night everyone!
<AlinuxOS> pitti, night!
<AlinuxOS> :D
<AlinuxOS> And I'm here editing bitmap fonts :)
<kbrooks> Kamion: there?
<kbrooks> Kamiwhat are we releqasing?
<mdke> leave the poor guy alone
<kbrooks> what are we releasing?
<jordi> what?
<Kamion> kbrooks: huh? leave me alone please
<mdke> Kamion: /away & /bed
<kbrooks> Are we releasing a flight8?
<Kamion> NO
<kbrooks> or what?
<Kamion> we are not releasing anything
<Kamion> not this week :-)
<kbrooks> who are you answering no to, Kamion?
<mdke> omg
<Kamion> you, for crying out loud
<jordi> to you
<kbrooks> ok
<kbrooks> i heard rumors that a flight8 might be out on the 19th or 20th
<Kamion> those rumours are outdated; there will no longer be a Flight 8.
<jordi> gotta love ubuntu gossip :)
<Kamion> BenC: I've just realised that the past few ia64 kernel builds have taken 7 hours and 20 minutes, and I'm not waiting up for another hour, so sorry, ia64 will just have to wait unless another ftpmaster happens to be around at the right time
<Kamion> night all
<mdke> night
<LaserJock> cya Kamion 
<BenC> Kamion: ia64 is the least of my worries
<BenC> good night
<mvo> yosch: hello, sorry - droped of the net
<ajmitch> hi
<yosch> mvo: hallo, np
<HiddenWolf> mvo: did you see the mail? Should I file a bug, or is there any information that you might need?
<yosch> mvo: just been talking a bit to the Dejavu folks (on #dejavu) about the future of font design :-D
<yosch> mvo: did you get the email and more importantly did you get a chance to look at it?
<mvo> HiddenWolf: thats probably enough, I'm drowning in bugs, so the mail is probably better
<mvo> yosch: I got the mail, but today was a very busy day. I'm very sorry that this goes not get the attention it deserves :/
* sladen wonders *if* the bug situation will subdue after release... or increase
* desrt watches -23 land
<wasabi> Somebody should set up an arm repository and binary upload processor. ;)
<jsgotangco> good morning
<nictuku> jsgotangco, morning
<mroth> did the -23 update break wireless support? 
<Mez> hmm - where can i find logs of ssh logins?
<HrdwrBoB> in /var/log/auth.log in #ubuntu
<Mez> I dont think it's on ubuntu
<Mez> grr this is annoying
<kbrooks> whoo.
<bddebian> Heya folks
<LaserJock> hi bddebian 
<bddebian> Heya folks
<bddebian> Hi LaserJock
<bddebian> WTF is JH_FIND_DIR?
<bioeng> You guys really developed an operating system?
<jsgotangco> you seem surprised
<robertj> am I the only one who has wierd focus problems with update manager?
<bioeng> It's just that this open source community is so much cooler than anything we did before I dropped out of college
<shackan> hi bioeng 
<bioeng> hi
<bioeng> You guys actually do REAL things instead of fake stupid stuff
<TheMuso> bioeng: And what do you call fake stupid stuff?
<bioeng> The stupid class projects we worked on that didn't teach you anything
<TheMuso> Right.
<bioeng> I only got through data structures before I dropped out so maybe the last course in the sequence would have been more interesting
<reconcilliation> No its not. I just finished a Masters. Its not.
<reconcilliation> lol
<bioeng> The last course in the sequence was systems programming
<bioeng> I guess it's not really that much more interesting, huh?
<bioeng> Am I right in that it's not more interesting?
<bioeng> Well, I'll take my leave now
<bioeng> thanks
<desrt> seb seb seb seb
<jdub> hrm, probably a bit early for mvo
<tritium> As an Enterprise/LTS release, is exchange calendaring via evolution considered important?  Currently, appointments don't get listed in clock applet, and no alarms are generated for exchange calendar appointments.
<jdub> tritium: got bug numbers?
<jdub> tritium: seb just did a bunch of -exchange bugfix pulling from cvs
<tritium> jdub: yes, and I filed bug #40005 some time ago
<Ubugtu> Malone bug 40005 in evolution-data-server "No alarms or appointment list for Exchange calendar" [Unknown,Unconfirmed]  http://launchpad.net/bugs/40005
<tritium> jdub: I did see that updated.  That didn't fix it, unfortunately.
<jdub> tritium: might be worth checking if it's fixed upstream, and telling seb about it
<tritium> jdub: I certainly will
<bddebian> Heya tritium
<tritium> hi bddebian
<whiprush> hi bddebian, jdub, everyone.
<ajmitch> hey whiprush 
<whiprush> hi aj
<tritium> I've been violating policy at work, running dapper rather than rhel4, testing it out in the workplace
<bddebian> Heya whiprush
<tritium> hey ajmitch, whiprush 
<bddebian> tritium: tsk, tsk :-)
<tritium> shh...
<ajmitch> tritium: public logged channel, remember :)
<tritium> ajmitch: yeah ;)
<Burgundavia> tritium, I am about to switch my work machine from FC4 to dapper
<tritium> Burgundavia: nice!  Any policies against that?
<Burgundavia> tritium, I am simply not going to tell anybody
<Burgundavia> we are a FC shop pretty much. Our product is built on it
<tritium> Oh, well good for you!  Glad I'm not the only one :)
<Burgundavia> what is funny is that our engineers are still struggling with FC5 and yet found dapper easy to integrate into
<bddebian> Burgundavia: :-)
<tritium> It's going to keep getting better and better in that respect.
<Burgundavia> you see the FC people are looking at letting non-RH people upload to Core?
<bddebian> Wow
<bddebian> Any of you see anything wrong with this? 
<bddebian>   (set) 2>&1 |
<bddebian>     case `(ac_space=' '; set | grep ac_space) 2>&1` in
<bddebian>     *ac_space=\ *)
<fabbione> bddebian: hmm
<fabbione> let me guess
<fabbione> that's from a tcl/tk package that is FTBFS
<fabbione> and you can't spot the error
<fabbione> configure fails on that line
<bddebian> fabbione: yep :-(
<fabbione> bddebian: look at the debian packages.
<fabbione> they already have a fix
<fabbione> it's a typo in the aclocal.m4 
<fabbione> repeat the same fix for N times
<fabbione> and you are done
<bddebian> fabbione: OK, thx
<fabbione> infinity, Kamion, mdz: can somebody please NEW l-r-m i386 for -23- abi?
<tritium> jdub: I was told by evoQA in #evolution on irc.gimp.org that alarm deamon code has been modified a lot and commited in evolution 2.7.x
<tritium> Apparently alarm notification works fine for appointments in exchange calendars
<jdub> "I'm not sure if it's because Ubuntu was unable to auto-negotiate 1000 full-duplex or if the TCP/IP stack still has some optimizing to be worked out before the beta is done."
<jdub> BenC, fabbione: how are you going with that TCP/IP stack optimisation, eh? :)
<jdub> http://www.technologyevangelist.com/2006/05/ubuntu_linux_dapper.html
<Burgundavia> jdub, odd that he had issues with his madwifi card
<mjg59> Sounds like a laptop
<mjg59> It's probably a card that's only supported with madwifi-ng
<fabbione> have a Broadcom 10/100/1000 NIC in the laptop and on the dock. 
<mjg59> Though it turns out that there are cared that only work with madwifi-ng and which have the same PCI IDs as cards supported by madwifi
<mjg59> s/cared/cards/
<mjg59> THANK YOU ATHEROS, YOU ENTIRELY INCOMPETENT MONKEYS
<fabbione> jdub: also.. i don't do kernel anylonger.. you know :)
<jdub> fabbione: oh, but i can see you getting involved in critical post-beta TP/IP stack optimisation
<mjg59> jdub: You're sounding worryingly like management
<fabbione> jdong: my only issue now is to get the tg3 driver in a decent shape...
<fabbione> jdub: ^^
<fabbione> jdub: and no... i am so not going to :)
* jdub assigns fabbione to porting the vista tcp/ip stack to ubuntu so we can ship it with dapper
<jdub> they've improved it, supposedly
<fabbione> jdub: why on earth you want to do so :)
<fabbione> let's just get the BSD stack..
<fabbione> they are the same
<jdub> fabbione: interoperability!
<fabbione> ahha
<fabbione> jdub: troll!
<jdub> of course ;)
<fabbione> let me get back to this glibc issue now
<fabbione> the build i started yesterday landed in a out of diskspace
<fabbione> infinity: where are my binaries?
<jdub> oh, this is good, beagle is indexing my unpacked fedora-ds tarballl
* jdub wonders if he should make ~/src non-indexed
<Burgundavia> jdub, good for a laugh. My company figured out how to get our flagship product to run on 6.06 before FC5
<jdub> Burgundavia: makes sense, considering - they keen on ubuntu now?
<Burgundavia> well, you never no. I am so divorced from the main office being in victoria. We do have an internal Ubuntu + Desktop Multiplier proof of concept live cd
<Burgundavia> s/no/know
<jdub> Burgundavia: anything obvious you think that keeps them from going with ubuntu (a supported platform!) by default?
<Burgundavia> jdub, mostly inertia at this point
* desrt needs someone to do a gnome upload
<desrt> (since i fear seb won't come online due to the holiday)
<desrt> (and since dapper is almost done)
<desrt> anyway.. it prevents you from creating new documents on remote sftp servers (using gedit, or any gnome-vfs, really) -- https://launchpad.net/distros/ubuntu/+source/gnome-vfs2/+bug/39024
<Ubugtu> Malone bug 39024 in gnome-vfs2 "[Dapper]  Gedit fails to save to remote location if creating new file while using sftp" [Normal,In progress]  
<desrt> testing appreciated since nobody else has really looked at it
<desrt> but i'm fairly sure it's the right thing
<desrt> should really be fixed.
<fabbione> desrt: bug daniel
<desrt> he was around earlier, too... bah
<desrt> how much longer until it's too late?
<fabbione> today or yesterday afaik
<desrt> heh.
* fabbione is checking a glibc fart and is in holidays
<desrt> :)
<desrt> what holiday is this, exactly?
<desrt> dapper day?
<jsgotangco> you can't resist or just forced to?
<fabbione> the one in which you are not supposed to do anything??
<fabbione> no, just normal holiday for me
<infinity> fabbione: Hey dude.  I was asleep...  A lot.
<fabbione> infinity: no problem
<fabbione> i decided to power up my Niagara
<infinity> fabbione: I'll put those binaries on chinstrap right now.
<infinity> Or.. Not.
<fabbione> but if you have the binaries handy it will be easier
<infinity> Yeah, I'll do it right now.
<fabbione> thanks
<fabbione> infinity: i only need libc6_ package
<fabbione> not all the .debs
<infinity> fabbione: Too late, they're all there.
<fabbione> ok :)
<infinity> fabbione: chinstrap:~adconrad/sparc-glibc
<fabbione> downloading
<fabbione> installing....
<fabbione> score!
<fabbione> infinity: a rebuild is enough
<fabbione> infinity: can you make the upload and make sure that the relno is yes when building?
<fabbione> just to avoid 20 uploads to get it right?=
<infinity> Alright.  I don't like what that says about the stability of our build environment. :/
<fabbione> Kamion: we will need a new d-i upload to include the new glibc for sparc..
<fabbione> infinity: i fully agree... but that check was a real fart imgo
<infinity> But yeah, I'll upload and babysit the log, and kill the build if it's not right.
<fabbione> imho
<fabbione> gcc-3.4 $someoptions |grep $SOMETHING
<fabbione> can't exactly fail at random
<infinity> Yeah, but clearly it did.
<fabbione> yes
<infinity> Hence, I say "WTF". :)
<fabbione> so did i
<fabbione> since yesterday :)
<infinity> If it was hppa, I'd just assume it was the usual kernel/segv bug.
<infinity> Not sure what scary outstanding bugs we have on sparc right now, though.
<fabbione> we know how to reproduce the issue
<fabbione> in terms that we can simulate that flag set to no
<fabbione> and see why discover1 goes nuts
<fabbione> at least that's the first binary that started having issues
<fabbione> there might be more
<fabbione> but discover1 it's easy to debug
<fabbione> it migth as well be a combinantion of bugs
<infinity> I'm less concerned about the discover segv and more concerned about the complete randomness that led to the glibc miscompile.
<fabbione> since for example using the optimized sparcv9v libc6 hide the problem
<fabbione> yeah i agree... 
<fabbione> that's harder to trigger
<fabbione> but if you can check what buildd does take that and so on, it might help
<fabbione> i need to go afk for a bit
<fabbione> infinity: did you update gcc-opt by any chance?? perhaps that or ccache might have hidden the call to gcc-3.4
<fabbione> anyway.. brb
<infinity> Nah, gcc-opt hasn't changed for eons...
<infinity> (Besides, the build I just gave you was done in the same chroot tarball)
<infinity> I sure would like to know where the i386 LRM went..
<kagou> hi
<LaserJock> hi kagou 
<fabbione> time to do some BIOS upgrades
<fabbione> later
<ajmitch> evening all
<kgoetz> hi ajmitch
<omeg> Well, finally the Xubuntu splash is done too.
<omeg> That means I'm done unless there is feedback.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_SCALED_BAR.png
<infinity> That's pretty nice...
<omeg> Still need to palette fix all of them, though.
<Burgundavia> infinity, for edgy, is there a sane way to say "if you cannot handle a higher resolution, just drop back to text" for usplash?
<infinity> Burgundavia: Err, come again?
<infinity> Burgundavia: You want usplash to default to a higher res, you mean?
<Burgundavia> infinity, yes, but the issue of older machines that break seems to be the big sticking point
<infinity> Burgundavia: We're not using a low res because "computers can't handle a higher res", we're using a low res because "vga16fb is the only framebuffer driver that we know won't break the registers on your video card and cause suspend/resume to stop working"
<Burgundavia> ah, ok
<omeg> By the way, infinity, so you already made a usplash package?
<omeg> Or someone else did, I think.
<infinity> But there's absolutely no reason you can't boot with "vga=1234" on your machine and have whatever resolution framebuffer you want.
<infinity> usplash being tiny in the middle of it isn't that big an issue.
<infinity> omeg: Keybuk uploaded it after all our talks the other day.
<infinity> omeg: It was his gift to me, to divert flames from me for a while. ;)
<omeg> Is there a place where I can get it and test it with my Breezy?
<infinity> omeg: breezy's framebuffer is 640x480 by default, not 640x400, so it wouldn't look right anyway.
<omeg> Oh, I see.
<infinity> omeg: We're two weeks from release.  Be a man.  Upgrade.   Help us find the last few showstopper bugs we MUST fix before release.
<infinity> Burgundavia: I don't really see any valid reason to default to a higher res anyway.
<omeg> Yeah, I'll do that. I'm currently using my main computer for work, though, so I'll put Dapper on my 400 MHz. Then I can test its speed. Breezy runs very acceptable. Just a little slower than Windows 98, I think.
<infinity> Burgundavia: 99% of users never use the virtual consoles (which is where you actually get a benefit from higher res, cause you have more lines/columns).
<infinity> Burgundavia: And "we want a higher res so the splash screen can have more detail" is such a bunk statement it's laughable.
<Burgundavia> indeed, but I was just wondering if there was some technical hack to make it work
<omeg> If you want the splash screen to look better at this point, I'd rather have 32-bit colors.
<Burgundavia> bling makes great marketing. I could care less
<infinity> omeg: Bumping the color palette suffers the same issues as bumping the res.  We go over 128k video memory usage, and some vga BIOSes will fail to cope.
<infinity> On the other hand, using simpler graphics is easy. :)
<omeg> Not for the artist, though :P
<infinity> (Has anyone actually SEEN the MacOSX splash that people keep raving about?  It's so simple, it hurts)
<omeg> But not that I really care.
<Burgundavia> they are still bikeshedding on the art list
<infinity> Burgundavia: They'll bikeshed forever, but we release in 2 weeks regardless.
<omeg> Yeah, it's very simple. Thankfully it's only around for a few seconds.
<Burgundavia> I think the biggest they we could do is to figure out how to not make the background black
<omeg> I liked the Mac OS 9 splash. Just a "Welcome" message while all the extensions and stuff are being loaded at the bottom of the screen.
<infinity> Burgundavia: I can make the background not black quite easily.
<infinity> Burgundavia: I just won't do it for dapper release.
<Burgundavia> ah, ok
<omeg> I liked the Mac OS 9 icons. Tiny little pixel art things.
<omeg> I'd like it if Edgy had a neater splash.
<omeg> But that depends on who's willing to program for it.
<omeg> I should really quickly close everything down and go to work now, then.
<omeg> See you tonight
<nomed> hi all
<nomed> Mithrandir: around ?
<simira> nomed: he's off work today, and will be online only periodically, I believe'
<nomed> simira: k thanks
<Keybuk> infinity: what i386 LRM ? O:-)
<kgoetz> what's yaird?(apart form a tool to make boot initrds)
<Keybuk> kgoetz: nothing.
<kgoetz> oh, fair enough. 
<kgoetz> thanks :)
<Keybuk> (ie. it's just a tool to make boot initrds...
<Keybuk> "yet another" tool, in fact)
<kgoetz> ah, i should have thought of that. lol. 
<Treenaks> hmm.. I have a powerpc with a slow clock, how would I go about debugging that?
<Treenaks> (it loses about a minute per day)
<infinity> fabbione: "checking for -z relro option... no
<infinity> "
<infinity> (Killing the build.
<fabbione> infinity: wtf...
<fabbione> infinity: we need to understand why...
<fabbione> was it the same buildd?
<infinity> Thanks, einstein. :)
<infinity> Yes, same buildd.
<fabbione> yeah yeah.. living close to .de makes that effect ;)
<infinity> I'll have to do more by-hand attempts to reproduce it.
<infinity> At any rate, the build is now sitting in FAILED, so it'll just idle there until we figure it out and then I can reset it.
<infinity> Thankfully, no need to reupload AGAIN.
<fabbione> infinity: ok.. i wonder if we are missing a B-D or something did change at this point
<fabbione> is the buildd the same where you did the manual build?
<infinity> Yes. :/
<infinity> Same buildd, same chroot tarball.
<fabbione> score..
<fabbione> same chroot
<fabbione> did you dist-upgrade the chroot before building?
<infinity> I'll fiddle some and see if I can come up with something.
<fabbione> (when in manual i mean)
<infinity> Yes, I dist-upgraded first.
<infinity> But, I didn't run all the lp-buildd scripts, cause I was in a hurry, so I'll do it the "right" way, and see if lp-buildd is breaking something.
<fabbione> ok thanks
<Lathiat> Treenaks: run ntpd? :)
<Treenaks> Lathiat: I am, but somehow it prefers LOCAL(0) stratum 13 to my ISPs stratum 2 servers
<Treenaks> Lathiat: even if I sync it just before starting ntp
<Treenaks> d
<Lathiat> fun'
<Treenaks> Lathiat: it works..ish when I disable LOCAL(0)
<Treenaks> but I like to think that it's there for a reason :)
<infinity> ARGH.
<infinity> checking for -z relro option... yes
<infinity> W.  T.  F.
<infinity> Identical chroot/sbuild setup this time.
<infinity> Oh, except for an empty ccache.
* infinity assumes that's the problem, empties the buildd ccache and tries the LP build again.
<fabbione> infinity: i doubt that could be the problem but it's worth a shot
<sivang> there is a distro sprint coming on next week?
<sivang> infinity: got enough sleep dude?
<infinity> More than enough.
<sivang> infinity: good to know. I wanted to ask you if you are only specifically interested in a bottle or can of olive oil , or any other olive products? (I'm keen to try and stuff as many as I can carry)
<morg1> Kamion: bug 45543
<Ubugtu> Malone bug 45543 in ubiquity "Serious Data Loss resizing partitions" [Normal,Unconfirmed]  http://launchpad.net/bugs/45543
<hunger> Hmm... how good are the chances that suspend-to-RAM will work in dapper again (like it did in breezy) for thinkpads?
<hendry> freeflying: i can't get skim working on an English setup of Kubuntu. that normal?
<torkel> hunger: works for me on my T40p
<freeflying> hendry: you need some configure for non CJK locales
<ispiked> why isn't there a firefox-dbg package?
<ispiked> iwj: ping
<freeflying> hendry: cp /etc/X11/xinit/xinput.d/scim-ahngul ~/.xinput.d/default  --<assume you've installed scim-hangul
<maswan> we're upgrading apache now, please report any issues with ftp.acc.umu.se
<freeflying> hendry: and im-switch skim scim-qtimm scim-gtk2-immodule 
<hunger> torkel: suspend/resume works... but immediently after the box comes up it does a shutdown which kind of ruins the efford:-)
<torkel> hunger: not for me. But I think I heard about some others having that problem, and I think it should be resolved now
<torkel> hunger: are you running an updated Dapper?
<zyga> hello
<hunger> torkel: Updated to whatever was in the archives 5min ago.
<infinity> fabbione: checking for -z relro option... yes
<infinity> fabbione: After clearing the ccache.
* infinity phears.
<fabbione> HMMMMMMMMMMMMMMMM
<infinity> fabbione: So, it's building now and I'll leave it be.
<fabbione> infinity: ok
<fabbione> is it going to be autouploaded?
<infinity> Yup, it'll get to the archive on its own when done.
<infinity> I don't have much control over that, short of stopping the processes that make that happen.
<fabbione> ok that's fine
<fabbione> i am just scared of that ccache issue
<fabbione> i can try to reproduce it tho
<infinity> I am too.
<infinity> I'm wondering if maybe we should just stop using ccache on the buildds altogether.  It's not like we don't have the CPU speed to keep up anyway.
<infinity> It seems we use it more or less for the bling factor.
<fabbione> ccache in our enviroment is almost pointless
<fabbione> imho
* infinity tends to agree.
<fabbione> it starts to make sense when you share it between all buildds of $arch
<infinity> Perhaps I'll just make an executive decision later and turn it off universally.
<fabbione> so it doesn't really matter when pkg foo is uploaded N times
<fabbione> but as it is there is very little gain
<fabbione> infinity: i will sustain your decision
<sladen> hunger: *please* can yu file a bug against gnome-power-manager then we can try to debug it
<hobojoe> hello all
<hobojoe> I'm not asking for help, but I thought I would point out that kbuntu and ubuntu fail to install on reiserFS systems on the package initrd-tools with latest release.
<hobojoe> I would post a BUG, but /target/var/log/bootstrap.log doesn't exist after the error even though it states it wrote the error to it.
<hobojoe> thought I can't be certain it has anything todo with the filesystem, but it did seem to install fine with ext3.
<hobojoe> but continually fails with reiser
<carlos> Riddell: hi, what's the status of the new KDE translation domains I added to https://wiki.ubuntu.com/MissingPotFiles ?
<carlos> pitti: I'm doing now the upload of the missing translation domains
<sladen> hobojoe: please report a bug anyway
<Mirv> Kamion: are you now using msgid:s Navigation|_Back and Navigation|_Forward from gtk+ translation for GUI installer buttons?
<Mirv> because even lately people have tested and found the buttons not translated. unfortunately I haven't tested for a few days. also one other possibility came to my mind: maybe gtk translations are not included for every language on the cd? that'd be unfortunate.
<_ion> keybuk: I read service.d.txt; looks really good.
<_ion> keybuk: The std{in,out,err} commands are really handy.
<_ion> Among others. :-)
<Keybuk> _ion: I have some other things in my notes which aren't so concrete
<Keybuk> have been thinking a bit more about ordering, and dependencies
<carlos> pitti: could you delay your script 1 hour and a half?
<carlos> just today
<carlos> I had to update the source code
<pitti> carlos: yes, will do
<carlos> hmm
<carlos> it failed again....
* Keybuk looks at pitti@WORK
* pitti still struggles with his tax declaration @REALLIFE
<pitti> Keybuk: c'mon, 3 seconds crontab -e is not really work :)
* desrt yawns @AWAKE
* _ion is compulsively running today's update && -u dist-upgrade.
<Keybuk> pitti: I won't tell mdz if you don't mention me replying to WRONG people on Malone and tickling things through NEW :p
<desrt> slomo; ?
<pitti> Keybuk: /me does not know what you are talking about :)
<Keybuk> good man :)
<Keybuk> I like it when people file bugs on what they think the cause of the problem is, without ever actually explaining there problem
<Keybuk> like this guy who's filed a few bugs because packages use S* scripts in rc0
<Keybuk> and still won't accept that that's normal
<desrt> gentoo user?
<Keybuk> dunno, he did quote the LSB in his last mail
<desrt> no gentoo user would do this
<Keybuk> I've get to describe it as "arse gravy of the highest kind, with those nutty bits you can't explain"
<Keybuk> which is my general description of the LSB
<carlos> pitti: I think you should use the language pack export from yesterday to do the new upload into dapper
<carlos> pitti: there is something weird that prevents me to run the script today....
<pitti> carlos: hm, ok
<carlos> pitti: Also, if you could take a look to https://wiki.ubuntu.com/MissingPotFiles and update your entries....
<carlos> pitti: there are two translation domains that I don't know where they come
<pitti> carlos: hm, today?
<carlos> pitti: no, when you have time
<carlos> I'm trying to get all pending domains imported today
<carlos> but I don't think it's a problem to have some other domains waiting some extra days ;-)
<AlinuxOS> pitti, carlos ;) Hello!
<AlinuxOS> ... Hello too the DEVEL-TEAM :)
<lool> slomo: around?
<sladen> Keybuk: mdz isn't on the channel, so he'll never know!  :)
<lool> slomo: I've produced a patch which solved the unaligned memory accesses in liboil0.3 for me, it's at <https://bugs.freedesktop.org/show_bug.cgi?id=6969>, I'd like to hear something from ds, perhaps he'll upload a fixed liboil or agree that I do so, but if you have root access to an ia64 on your side, I'd be interested to hear whether this solves the banshee FTBFS
<Ubugtu> bugs.freedesktop.org bug 6969 in unknown "function conv_8/16_f32_lrint(f) in class conv_u8/16_f32 failed check" [Normal,New]  
<lool> slomo: (it would probably solve the gst-plugins-base0.10 FTBFS on multiple arches in Debian)
<mgalvin> Mithrandir: there will be no flight 8?
<infinity> mgalvin: No, since the distro team all took Friday (today) off, and on Monday we're jumping straight to RCs.
<infinity> mgalvin: (Note the irony in the response coming from the same person who told you this on a mailing list)
<mgalvin> infinity: :) thanks, just making sure b/c tollef had asked me to get the flight 8 tour ready
<infinity> Yeah, I suspect he asked you that before we decided to canel it.
<mgalvin> yup
<infinity> Your Flight-8 tour will make a nice RC1 tour instead, don't fret. :)
<mgalvin> no biggie... yup :_
<mgalvin> :)
<infinity> (You'll have to re-do some screen shots, I expect, since I expect the artwork to get the "beta" stuff removed for RC1)
<Lathiat> the reboot icon is fairly similar to the updats available icon
<Lathiat> like they oth have arrows goign around in cicles
<Lathiat> could potentialy be confusing?
<bddebian> Mroning
<bddebian> Hmm, Morning even
<_kaenat> How can I rectify an error "E: Couldn't find package manpages-posix-dev" when doing 'sudo apt-get install manpages-posix-dev'?
<dsas> _kaenat: You do have multiverse enabled right?
<_kaenat> dsas: I have a line in /etc/apt/sources.list: deb http://us.archive.ubuntu.com/ubuntu breezy-backports main restricted universe multiverse
<_kaenat> I just did a apt-get update, but didn't help
<Lathiat> -ECHANNEL, please take it to #ubuntu, this channel is for ubuntu-development related discussion
<Lathiat> _kaenat: You'll see I'm offering you some advice there
<wasabi_> So, does Ubuntu aspire to any sort of embedded small footprint device support? Perhaps dapper+1?
<sladen> wasabi_: mubuntu
<wasabi_> Is that a seperate project by a seperate team, or something canonical is running/will be running
<sladen> wasabi_: it's been talked about by lots of people
<wasabi_> Is anybody else working on a simple arm port?
<wasabi_> heh.
<sladen> wasabi_: but it keeps on coming up more often;  a downside of embedded projects is that every device has its own set of drivers and setup unique to that device
<wasabi_> Yeah. Expected. Not a super big deal.
<_ion> Mubuntu as in buntu?
<wasabi_> Building a root image is not that hard.
<sladen> wasabi_: when a standardised piece of arm kit (eg. a Nokia 770, or Motorola mobile)  comes out then It'll take off
<wasabi_> Even now. Just debootstrap --foreign into it.
<sladen> _ion: yes.  I just could find the AltGr combination to get get 
<wasabi_> Whatcha mean? The N770 isn't really any arm kit standard.
<wasabi_> http://akita.larvalstage.net/~wasabi/archive-ubuntu-arm/dapper/ <--- if anybody is interested
<sladen> wasabi_: the reason people can develop for i386, is because they can get hardware which works in the same way as everyone elses
<wasabi_> Qemu? :)
<sladen> wasabi_: actually the 770 platform is based around a TI OMAP reference board, so it's more "standard" than most
<wasabi_> Not really, because it is one device out of many.
<wasabi_> In fact, there's less of n770s and more of PPCs... So I don't know what makes something "standard".
<wasabi_> It's just one more device in a pile of them.
<sladen> wasabi_: the CPU instructions are the easy bit.  It's the perhiphales that are the hard bit
<wasabi_> Just drivers.
<dieman> is there any way to get more than 10 cds in shipit anymore?
<wasabi_> Just like any PC. Some devices have different drivers.
<sladen> dieman: yes, send an email
<wasabi_> All of that happens in kernel space anyways.
<dieman> ok
<tepsipakki> isn't there a way to exclude a file in for example debian/package.docs, so that dh_installdocs adds the line to excludes?
<dieman> sladen: whats the preferred target of the email?
* dieman checks the faq
<wasabi_> In user space it's just a bootable rootfs which finds a display device, maybe a touch screen, and other perhiperals, and works.
<sladen> dieman: the email given on the webpage
<dieman> missed that link
<shawarma> The kernel on the LiveCD supports SMP, doesn't it?
<dieman> there wasn't an email on login or the shipit page i think
<sladen> wasabi_: have you ever, er, done any embedded development
<dieman> im guessing its only on the faq
<wasabi_> No. Which is why I'm asking. I'm compiling Ubuntu for arm right now, then going to plop it onto the n770.
<wasabi_> and start making it work.
<sladen> wasabi_: they don't have ACPI tables that neatly give you the address of everything and an abstraction for finding them
<wasabi_> Isn't that the kernel's responsibility, though?
<tepsipakki> wasabi_: have you seen the maemo mistral (v2.0) roadmap?
<wasabi_> Yeah.
<sladen> dieman: third answer on http://www.ubuntu.com/support/faq
<wasabi_> The part of maemo that interests me is just the application environment.
<wasabi_> ie hildon.
<wasabi_> Hildon can be ported to Ubuntu/Debian just as easy as xfce, or gnome, etc.
<sladen> shawarma: the kernels now reconfigure themselves for UP or SMP
<wasabi_> The rest of it, the user space. I don't want yet another copy.
<sladen> Hirion: if you had the source-code, yes
<shawarma> sladen: I'm not sure if that's a yes or a no. I just stumbled upon this https://launchpad.net/bugs/26774 and was wondering if I could close it.
<Ubugtu> Malone bug 26774 in casper "LiveCD has no SMP support" [Normal,Unconfirmed]  
<dieman> sladen: yah, but the faq link was hard to find :)
<dieman> sladen: way down in the bottom right
<sladen> dieman: can you file a but about that:  https://launchpad.net/products/launchpad/+bugs  
<sladen> dieman: eg.  "New ShipIt: hard to find information/email address for ordering more than 10"
<dieman> sladen: will do
<wasabi_> debootstrap needs support for specifying multiple apt repositories
<Treenaks> Seveas: well, post the link :P
<lemsx1> infinity: hello
<Seveas> Treenaks, planet.ubuntu-nl.org 
<Seveas> http://photos1.blogger.com/blogger/7579/1056/1600/ubuntu_rubber_ducks.jpg
<kgoetz> Seveas: hahaha. classic. whos are they?
<Seveas> pmjdebruijn (Ubuntu NL)
<kgoetz> lol. cool
<sladen> Keybuk seems to have gone all silent
<dieman> nice rubber ducks there
<Treenaks> sladen: keybuk is silently uploading them as the Official artwork :)
<sladen> we missed the chance to pollute the artwork on the 1st of April this year
<AlinuxOS> pitti, ping
<AlinuxOS> have got 1 minute?
<AlinuxOS> ooops
<AlinuxOS> no :)
<AlinuxOS> no developers it's Team Holiday!!!
<AlinuxOS> :D
<bddebian> Bah :-)
<jsgotangco> hi
<bddebian> Heya jsgotangco
<jsgotangco> ahhh jeezz im drunk
<bddebian> jsgotangco: Nice :-)
<kgoetz> lol
<kgoetz> half your luck :/
<jsgotangco> heh
<carlos> pitti: all missing translation domains that I'm able to fix are fixed now
<pitti> carlos: cool
<mhz> nomed: ping
<bddebian> Hello mhz.  Aren't you supposed to be vacationing today? :-)
<mhz> nah
<mhz> I am not in the payroll :D
<kgoetz> hehe
<bddebian> heh
<mhz> bddebian: however, unless it's a bot, ogra is here and he's in the payroll
<mhz> hmm, he may be idle
<jjesse> is today a mandatory vacation day for employees?
<tseng> yes.
<jjesse> that's cool
<mhz> cool
<mhz> but I prefer to make my own decissions on when I get my day off
<wasabi> Hmm. Perl no compile on arm.
<bddebian> Aye
<bddebian> LaserJock!!
<LaserJock> what? :-)
<bddebian> Hi :)
<LaserJock> bddebian: hi back
<LaserJock> bddebian: so should we take over Main while they are away on "vacation"? ;-)
<pitti> BIG BROTHER'S WATCHING YOU !!!1!1
<crimsun> ohnoes
<LaserJock> pitti: my big brother can hardly run Doom on his computer I doubt he is watching me ;-)
<bddebian> LaserJock: mwuhahahaha
<kagou> cya
<bddebian> What's the rationale for keeping 3 versions of pike in the archive?
<LaserJock> the more the merrier?
<bddebian> Bah :-)
<tsdgeos> jordi: thanks :-) !
<jordi> tsdgeos: :D
<tsdgeos> bye!
<dieman> crazy, for some reason i ended up with an initrd without usplash that wont boot.
<dieman> (from a non-supported hoary -> dapper upgrade)
<crimsun> so you manually (re)generated the initramfs?
<dieman> going to
<dieman> need to boot the machine off a livecd first here
<dieman> but yeah, usplash was definately not installed before it was generated and it gave me a very broken initrd
<webwolf_27> are there any known bugs with the current (Dapper) glibc?
<tseng> https://launchpad.net/distros/ubuntu/+source/glibc/+bugs
<tseng> plenty
<tseng> take your pick
<webwolf_27> tseng, just a second I'm looking to see if mines there ;)
<webwolf_27> tseng, nope it's not
<tseng> well, you know what to do
<webwolf_27> yeah, still any idea what I can do as a dirty fix for the following error:
<webwolf_27> *** glibc detected *** double free or corruption (!prev): 0x081781d8 ***
<webwolf_27> Unable to read printer database.
<tseng> that might not be a bug in glibc
<tseng> but the app itself freeing the same address twice
<tseng> or real corruption from a hardware problem
<tseng> is that cups?
<webwolf_27> yes
<webwolf_27> everything else works great. but now one of my printers isn't even found, and the other won't print
<tseng> file a bug against cups
<tseng> cupsys
<webwolf_27> tseng, I saw a similar bug in cupsys with the HP Laserjet 100x that it simply won't print
<tseng> ok, I am not a cups guy
<tseng> please open a bug
<webwolf_27> tseng, will do
<tseng> thanks.
<webwolf_27> No problem, I like linux. I want it to work and I'm happy to help and help others help me
<tseng> cool :)
<webwolf_27> that was one of the reasons for doing my c++ cert in linux
<infinity> dieman: Do you still have that unbootable machine in an unbootable state, so we can look at it, or did you fix it?
<dAndy> can anyone give me odds on whether bug #25206 will be fixed for dapper? It is pretty much a show stopper in my environment
<Ubugtu> Malone bug 25206 in glibc "Cannot use bash from users in NIS database" [Unknown,Fix released]  http://launchpad.net/bugs/25206
<dieman> infinity: its very much broken still
<dieman> infinity: and im completely lost
<infinity> dieman: Oh, good.  (sort of)
<dieman> it appears the image is ok
<dieman> i think
<dieman> the binaries are all in it
<infinity> dieman: Oh.  So maybe it's not my bug?
<dieman> well
<dieman> you want a jpg of the output real quick?
<infinity> Yeah, that'd be cool.
<dieman> ok
<infinity> FSVO "cool"...
<dieman> infinity: http://www-users.cs.umn.edu/~sdier/boot.jpg
<dieman> im currently booted off of a livecd and can get you the image too
<bddebian> FSVO?
<infinity> dieman: Erm, no that's horribly broken and incomplete. :)
<dieman> heh
<dieman> ok
<infinity> dieman: Okay, first thing's first.  Is /boot/ a separate partition?
<infinity> dieman: And is it full? :)
<infinity> bddebian: For Some Value Of.
<bddebian> Ah thx
<bddebian> Aren't you folks supposed to be "off" today? :)
<infinity> bddebian: Technically it's Saturday now for me.
<dieman> infinity: same partition
<infinity> bddebian: Which, I suppose, just makes it that much worse, but whatever.
<dieman> its part of /
<bddebian> :-)
<infinity> dieman: And plenty of space?
<dieman> which has 3gb free
<infinity> dieman: Okay, scratch that one, then.
<dieman> the image is 5.5M, too
<infinity> dieman: Next step.  Copy that broken one somewhere where you can later get it off the machine and in my grubby hands.
<infinity> dieman: And then "update-initramfs -u -k <whateverversionthatis>
<infinity> "
<infinity> 2.6.16-23-386 or whatever.
<dieman> infinity: http://www-users.cs.umn.edu/~sdier/initrd.img-2.6.15-23-amd64-xeon
<infinity> Oh, I have initramfs-tools break intentionally on Xeon machines to punish people for making bad purchasing decisions.
<bddebian> haha
<dieman> ok, did the update-initramfs (and its now about the same size)
<lemsx1> infinity: lol
<infinity> dieman: Didn't throw any errors in the process?
<Burgundavia> infinity, actually, you delayed the lrm release yesterday to punish new users who have tried dapper
<dieman> infinity: no errors
<dieman> infinity: im currently chrooted into the partition, if thats ok
<dieman> proc is mounted
<infinity> Burgundavia: Actually, I didn't delay it at all.  It got hitched up in the LP machinery somewhere (on i386-only, entertainingly)
<infinity> dieman: Yes, chrooted in is better.
<infinity> dieman: Can you also do the following?
<infinity> dieman: mkinitramfs -o /dev/null -k 2.6.15-23-amd64-xeon
<lemsx1> talking about update-initramfs, i have a system (running dapper) that keeps attempting to rebuild a 2.6.12-10-686 initrd even though there is NO such linux-image package installed... where does update-initramfs -u (with no -k) gets the version of the running kernel?
<infinity> dieman: And tar up the junk it spits in /tmp for you?
<omeg> Hi all
<infinity> lemsx1: It doesn't use the version of the running kernel, it does some guessing of the "best" kernel.
<infinity> lemsx1: I suspect you still have symlinks pointing to that kernel as "vmlinuz"
<infinity> lemsx1: Or something else.
<infinity> lemsx1: Runinng update-initramfs with "sh -x" may shed some light on it.
<dieman> infinity: http://www-users.cs.umn.edu/~sdier/initramfs.tar.gz
<infinity> omeg: Just rebooted with your new splash.  Looked nice.  I'll think of you on every reboot now.
<omeg> Sounds great. :)
<omeg> Thanks for testing it. I'm glad it looks nice.
<omeg> I'm wondering, has the Kubuntu splash been packaged yet? Because I just made some very minor adjustments. Nothing that warrants repackaging, but just in case it hasn't been done yet...
<infinity> dieman: Kay, and I'm going to assume that if you reboot right now, it'll still get stuck in the same spot... But try anyway? :)
<omeg> I'll also get GIMP now so I can see for myself how that palette solving thing is done.
<infinity> omeg: The kubuntu one got reverted by the kubuntu lead devel.
<omeg> So my screen was in there for a while, but it got reverted? That's too bad. Did he post any feedback anywhere?
<mjg59> Oops
* mjg59 watches ubiquity use up all the memory and kill nautilus
<dieman> infinity: ok
<mjg59> Which then restarts cleanly, but opens a window in the process
<infinity> dieman: Okay, that initramfs doesn't look broken in the least.  It's just behaving like one that is. :/
<dieman> yeah, still stuck
<infinity> Same image?
<dieman> yah
<infinity> Okay, that's all sorts of bizarre.. :/
<infinity> Let me download this jpeg and put it in the same directory as this other debug stuff from you...
<dieman> yeah
<dieman> im weirded out now
<infinity> dieman: Okay, you can delete it now.  Got it.
<infinity> dieman: Can you boot without quiet on the command line?
<dieman> could it be a kernel issue?
<dieman> just did
<infinity> dieman: Maybe there's a kernel error here that would shed some light. :)
<dieman> not much more information
<dieman> ramdisk says 16 ram disks of 65536k size 1024 blocks
<infinity> Define "not much more"... There should be a mess of printks before that.
<dieman> yah
<dieman> i cant scrollback to them though because of usb kbd :|
<infinity> Woo.
<infinity> And nothing useful in the final 25 lines?
* omeg grabs Flight 7
<dieman> not seeing anything :|
* infinity puzzles over how init can be found and run and then notihng else work..
<dieman> all the stuff in the initrd for amd64 is 64 bit right?
<dieman> could it nbe the kernel is missing 32bit support?
<infinity> It all better be 64-bit. :)
<omeg> By the way, infinity, just a little something inbetween: did the Kubuntu lead devel post reasoning for reverting that splash screen? Maybe I can still change it around to suit the needs and wants.
<dieman> alltho that'd be weird
<infinity> Unless your filesystem is some kinda thpethial.
<dieman> heh
<dieman> i'm gonna reboot and try the generic kernel
<infinity> omeg: He reverted it and told Keybuk and I "we have our own artwork, thankyou very much, don't touch it"
<infinity> omeg: You're welcome to talk to him (Riddell) directly, of course. :)
<omeg> Well, if they have their own good artwork, they should keep it. Kubuntu is their project. I'd argue that it would be nice to have consistent boot themes, though, but I wouldn't know how well mine works since I've only used Kubuntu once.
<omeg> I'll send him a PM
<infinity> omeg: I'd like to see consistency, but since the desktops aren't consistent either, the point is somewhat moot.
<infinity> dieman: I'm sure the answer lies somewhere in dmesg. :/
<iegary> hi, I was wondering if there was a chance for a fix for bug #37973 in libc6 before release - the patch agrees with the timezone data in 2006g.
<Ubugtu> Malone bug 37973 in glibc "Day light time saving is cancel in Asia/Tehran" [Normal,Confirmed]  http://launchpad.net/bugs/37973
<infinity> dieman: You can't get a PS2 keyboard on there?  Or enable legacy emulation in the BIOS?
<lemsx1> infinity: thanks for the sh -x tip
<dieman> infinity: the ps2 port is uh, not all that great on this machine -- they somehow slopped it on in conjunction with usb or something and it usually doesn't work right
<dieman> infinity: i'll try upgrading the bios to see if its fixed
<dieman> (blame dell!)
<lemsx1> where are the release-critical bugs for Dapper? or what needs work before the release date. i'd like to put some time into bug patching this weekend
<infinity> dieman: Kay, and no legacy emulation for the USB keboard?
<dieman> dont believe so
<dieman> i'll check
<infinity> lemsx1: anything in universe >= Major should be fair game.
<omeg> infinity: hehe yeah, that's right (regarding consistency in splash screens). But it could be seen as a start.
<infinity> lemsx1: Stuff in main is more tightly controlled at this point, so some Major bugs will get fixed, other not becuse they're too intrusive.
<omeg> Did you see that Xubuntu variation, by the way? I think it's still somewhat similar to the Kubuntu one I made.
<lemsx1> infinity: using Malone's bug db then?
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_SCALED_BAR.png
<infinity> omeg: The Xubuntu one was nice.  You made the mouse look pretty good.
<lemsx1> infinity: gotcha
<omeg> I'm still gonna remove two more pixels from that mouse if you don't mind, though :))
<omeg> There are two bright pixels on it while the rest of it are two shades of dark pixels, so they stand out too much.
<infinity> omeg: Tweak it all you want.  I trust your judgement after my last reboot and seeing that your hack job was MUCH nicer than my last one. :)
<mjg59> Hmm.
<infinity> nomed: Around?
<omeg> Thanks :)
<mjg59> https://launchpad.net/distros/ubuntu/+source/murasaki/+bug/44355 - we should just pull miriaski
<Ubugtu> Malone bug 44355 in murasaki "Hotpplug installation in dapper Damages Beta2" [Critical,Unconfirmed]  
<infinity> mjg59: Can you confirm that it's generall useless?
<infinity> mjg59: I'm happy to remove it if there's no argument to keep it.  I'm not cool with removing it just cause "udev is better"...
<infinity> (If "A is better than B" was the only criteria for removing packages, we'd lose half of Universe)
<mjg59> There's no reason to keep it
<mjg59> And installing it breaks the system
<wasabi> Grrr. Perl and python won't compile on arm either.
<mjg59> ARGH WHY HAS UBIQUITY RESIZED MY WINDOWS PARTITION INSTEAD OF INSTALLING IN THE PARTITION I TOLD IT TO?
<infinity> mjg59: Oh, neat.  It depends on modutils too.  2.4-only, I suspect..
<infinity> mjg59: And since our glibc doesn't even support 2.4 kernels on most arches..
* infinity decides that enough reason to punt it.
<sladen> mjg59: got the logfiles?  Kamion would love for something to debug
<mjg59> Yeah, I've got the logs
<mjg59> I'll punt that onto Colin later
<sladen> omeg: the foreground text looks quite strong in that Xubuntu one
<sladen> omeg: and it looks at first glance like the gradient might start going /backwards/ towards the top of the circle logo
<infinity> mjg59: Removed.
<omeg> sladen: with foreground text, do you mean the text output at the bottom of the splash?
<omeg> As for the gradient, well, that's kind of the point. :)
<mjg59> infinity: Thanks. Can you close that bug?
<mjg59> Oh, wow
<infinity> mjg59: Just did.
<mjg59> Ubiquity has got *very* confused
<mjg59> I told it to use my existing swap and ext3 partitions
<mjg59> Instead, it resized the NTFS partition and put in new ext3 and swap partitions
<mjg59> But it's written RESUME=/dev/sda5 (the old swap partition)
<infinity> mjg59: You win the "tar up your log files" award of the day.  I think that's exactly the sort of breakage Colin wants to see.
<infinity> (Well, the kind he doesn't want to see, but would like to fix if it theoretically exists -- which it doesn't)
<mjg59> Also, gnome-power-manager hasn't defaulted to enabling sleep on these machines
<mjg59> Grah bugs bugs bugs
<infinity> Sleep went away on my machine too.  WTF?
<infinity> I guess /etc/default/acpi-support is obsolete now?
<mjg59> Not entirely
<mjg59> But gnome-power-manager is supposed to check the whitelist at install time and set appropriate gconf keys
<infinity> Well, g-p-m has definitely decided I can't sleep.
<infinity> And /etc/default/acpi-support says otherwise.
<infinity> And I think I'm also whitelisted, but I don't recall.
<mjg59> g-p-m ignores the acpi-support stuff
<mjg59> You ought to be whitelisted
<infinity> Where's the whitelist live?
<mjg59> /usr/lib/acpi-support
<slomo> lool: i don't have access to any ia64 :/
<mjg59> Sorry, /usr/share/acpi-support
<infinity> I figured that when the former didn't exist. :)
<mjg59> infinity: At the guess the g-p-m postinst is broken
<infinity> Yeah, I'm whitelisted.  How can I check to see if the whitelist is actually correctly parsed by... Anything?
<infinity> DeviceConfig.
<mjg59> Check the g-p-m postinst
* infinity plays..
<infinity> (base)root@cthulhu:~ # echo $model; echo $ACPI_SLEEP
<infinity> 2687DVU
<infinity> true
<infinity> That answers that.
<dieman> ok
<dieman> gort the keyboard fixed
<dieman> waiting for it to drop me to a shell
<infinity> dieman: boot with "break=top"
<infinity> dieman: Though the shell may not work due to the other breakage. :/
<dieman> shell works
<infinity> mjg59: Hrm.  can_suspend=true according to a gconf-editor run as root, but =false according to one run as my user.  The irritating bit is that I can't find where I've got that manually set in .gconf (I don't think I have).
<dieman> ARUGH
<infinity> dieman: Can you run anything from it, like, say, "depmod"?
<dieman> modprobe is there
<dieman> and if you do /sbin/modprobe it says 'not found'
<dieman> but i can cat the file
<infinity> Hrm.
<infinity> If external binaries can't run, this'll be fun to debug.
<infinity> Since I'm pretty sure busybox doesn't have an strace or a gdb I can build into it.
<mjg59> Doesn't "not found" imply that it can't find the RTDL?
<dieman> oh weird
<dieman> zcat works
<dieman> oh, but its probally busybox
<infinity> Probably.
<infinity> Anything busyboxish should work.
<mjg59> infinity: It's definitely broken, given that I've just done clean installs on two whitelisted machines
<infinity> mjg59: Yeah, it's being set in the root profile though, so I'm really confused as to why it doesn't show up in the user profile.  This looks more like gconf-on-crack than g-p-m doing anything wrong...
<infinity> mjg59: Or I totally don't understand how gconf works.
<mjg59> Root is just another user as far as gconf is concerned
<infinity> But gconf-tool is doing sketchy stuff in /var, no?
<infinity> And that stuff gets merged with user configs at runtime?
<infinity> Or sometihng equally OMGWTF?
<mjg59> System-wide config is used as the default in the absence of user config
<infinity> Oh, wait, it's set to false in .gconf/%gconf-tree.xml ...
<infinity> Are the subdirectories in .gconf/ no longer used?
<dieman> could it be its missing libraries or something? are all the things in /sbin linked to ksplash instead?
<mjg59> Ah!
<mjg59> I reran the postinst and it fixed things
<mjg59> So...
<mjg59> gnome-power-manager doesn't depend on acpi-support
<infinity> dieman: klibc, you mean?
<dieman> yeah
<dieman> klibc rather
<mjg59> Which presumably means there's no guarantee that the whitelist files exist when it's configured
<infinity> dieman: glibc and klibc should both be in there..
<dieman> hmm
<dieman> i only see klibc
<dieman> in /lib
<infinity> mjg59: That would be your problem, yes.
<infinity> dieman: Oh, WTF... You're right.
<infinity> dieman: I completely missed that when looking at your cpio archive.
<dieman> hmmok
<dieman> im going to boot back to the livecd
<infinity> dieman: That's the problem then.  But no idea WHY...
<dieman> to see wtf on the disk
<infinity> dieman: Is there any hope of getting external SSH access to that machine while booted from the livecd?
<dieman> yes, actually
<mjg59> infinity: Oh, no, that's not it
<mjg59> infinity: It depends on powermanagement-interface, which depends on acpi-support
<infinity> mjg59: Well, poo. :)
<infinity> mjg59: I ran the postinst by hand, and it IS doing the right thing...
<mjg59> I can never remember depends/pre-depends semantics
<infinity> mjg59: My problem appears to be local user goofiness, not the postinst issue.
<mjg59> infinity: Seriously, it's *not working*
<infinity> mjg59: For  apostinst, depends is fine.
<infinity> mjg59: Depends guarantees configure order.  (unless there's a loop)
<mjg59> I've just installed two machines. Running the postinst by hand sets the right keys.
<mjg59> But they weren't set when I did the first boot
<wasabi> Don't suppose anybody is familiar with the status of gtk display migration?
<infinity> dieman: Need an SSH key sent to you or something?
<dieman> infinity: sure, just shoot me one pgp signed and that should be fine
<infinity> dieman: Address?
<dieman> sdier@cs.umn.edu 
<infinity> Should be there in ~10 seconds.
<infinity> Intervening MTAs depending.
<dieman> yah
<dieman> http://www.cs.uu.nl/people/henkp/henkp/pgp/pathfinder/mk_path.cgi?FROM=C6CEA0C9&TO=AE4B5D92&PATHS=trust+paths
<dieman> heh
<dieman> i guess i can trust your pgp key
<dieman> ;)
<dieman> i could trust it based on lamont alone
<infinity> Colin made me do DNA tests.
<infinity> I'm such a slacker...
<dieman> hahah
<infinity> I have jbailey and Kinnison's business cards sitting in my wallet from last Novermber and still haven't done theirs.
<infinity> Bah.
<dieman> yah
<dieman> you'll be in france, right, next month?
<mjg59> infinity: So any idea why the postinst wouldn't work in the installer?
<infinity> dieman: Yeah.
<bddebian> Any of you archive admins?
<infinity> mjg59: I can only assume for emotional reasons.  The technical ones seem to have all dried up.
<infinity> bddebian: Depends on what you want.
<dieman> infinity: heh, i can give you another one to do at that point too then, i guess
<infinity> dieman: Oh, you're coming?  Cool.
<mjg59> infinity: Gah. Well, it seems somewhat critical to fix this...
<bddebian> infinity: mysql-navigator is at 1.4.2-6 and Debian has a -7 that fixes a bug.  Do I request a sync or bring it over myself?
<infinity> mjg59: Yeah, I agree.  I'm pondering. :)
<dieman> infinity: yah
<infinity> bddebian: The former.
<dieman> infinity: work is paying :)
<infinity> bddebian: Request a syn in a comment in the bug, and SUBSCRIBE (don't reassign) ubuntu-archive to the bug.
<infinity> bddebian: s/syn/sync/
<bddebian> infinity: OK, thx
<omeg> Wooh
<omeg> Second time I'm ever using GIMP.
<infinity> dieman: Cool.  When I still lived in Canadia, I kept meaning to figure out how to swing out your way.  From .au, it became trickier.  This will do.
<dieman> heh
<infinity> mjg59: Wait.  This is a ubiquity install?
<mjg59> infinity: Yup
<infinity> Well, "duh", then.
<mjg59> Mm?
<infinity> The package is installed on the buildds, not on your machine.
<infinity> We'll need to get ubiquity to re-run that postinst.
<mjg59> Oh argh
<mjg59> Seriously?
<omeg> infinity: so the Ubuntu splash I made earlier has been palette fixed by someone (you?) If you have it, can you send it to me so I can put it on the wiki? Then I can label it "correctly palletized".
<infinity> Yeah, all the packages are installed in the livefs build.
<mjg59> Does it have a list of postinsts it needs to run?
<infinity> mjg59: I have no idea if it has a list of dpkg-reconfigures it must run, but I suspect it may.
<infinity> mjg59: You'll have to either grab the source or ask Colin.
<mjg59> Ok
<dieman> infinity: ok, you should be able to login to ubuntu@palmtree.cs.umn.edu
<infinity> mjg59: For the sake of our sanity, want to grab a text-install CD and verify that it DTRT?
<dieman> infinity: the drive is mounted in /chroot
<infinity> You don't mind that you just gave me root, right?
<infinity> If you do, I'll log out. :)
* infinity logs out until you answer.
<dieman> infinity: dont mind
<dieman> infinity: its a bare client machine
<dieman> infinity: there isn't anything private/sensative on it
<mjg59> infinity: No, that sounds like the reason
<infinity> mjg59: The fix seems twofold, actually...
<infinity> mjg59: A) ubiquity needs to dpkg-reconfigure that bad boy on install.  B) You should detect in your postinst if you're in a livefs build and disable both hibernate and suspend, so the livecd can't.
<infinity> mjg59: Though I suppose casper should be doing (B) on boot, arguably.
<infinity> (Less icky than detecting livefs build machinery)
<infinity> Yeah, skip (B).  But make sure that Tollef has made casper set those keys to false.
<dieman> infinity: if you want, i could take away root access for you if you want
<infinity> dieman: No, I don't care one way or the other.  I just wasn't sure you had realised what you'd done.
<dieman> ok
<infinity> (livecd user, passwordless sudo..)
<dieman> yah
<dieman> not worried about it
<dieman> let me know if you need anything
<infinity> Just a coffee, dear. :)
<bddebian> You guys need days off more often.  My builds finish much faster without you folks around. ;-P
<mjg59> Wow. bcm43xx really does work quite well now
<infinity> mjg59: Is there no way we can do this at runtime instead of install time?
<mjg59> infinity: No
<bddebian> Cool.  There are a lot of bugs out there for bcm4xxx
<infinity> mjg59: This doesn't just break the ubiquity case, it also breaks system imaging.
<mjg59> infinity: They're system-wide gconf defaults
<mjg59> What would set them at run time?
<dAndy> Kamion: the ftp support to load a box only seems to sort of work in the kickstart
<infinity> Maybe an init script?
<mjg59> infinity: I think that's entirely too horrible to contemplate...
<infinity> (ick, I know)
<infinity> But I've often prided myself on Linux being something you can tear a motherboard out from under without it blowing up.
<infinity> This case disproves that.
<mjg59> It's a stop-gap measure until we can just handle it in fdi files
<infinity> I'll just nod and pretend I know what an fdi file is.
* infinity goes to look at dieman's confused computer.
<dAndy> Kamion: it does the debootstrap stuff fine, but when it goes to update the system and install the rest of the packages, it cant connect
<bddebian> invalid lvalue in assignment?
<bddebian> (FILE *)sendmail_stream=popen (sendmail_command,"w");
<infinity> dieman: Err, how old is this livecd?
<dieman> infinity: it should be beta2
<dAndy> Kamion: the error message is: "Err ftp://us.archive.ubuntu.com/ubuntu/..... Unable to connect to ftp:"
<dieman> infinity: but i was using the mkinitrd and friends from off the chroot
<infinity> Oh, the chroot, right.  Silly me.
<dieman> initramfs rather
* infinity chroots to that.
<dieman> im all getting used to this still
<infinity> The one in the livefs works right, oddly enough. :/
<dieman> hah
<lemsx1> dAndy: all ubuntu mirrors that i have are very busy (archive. and us.archive)
<infinity> ubuntu:~# ldd /sbin/modprobe
<infinity> ldd: Command not found.
<dAndy> lemsx1: it fails in exactly the same way every time, on both our local mirror, and us.archive
<dAndy> lemsx1: it is able to fetch packages up to a certain point, then it just cant anymore, 
<infinity> dieman: Your libc6 is BROKEN.
<dieman> infinity: doh
<infinity> dieman: reinstall libc6 and let me know if it works then. :)
<lemsx1> dAndy: well, mine finally finished to get linux-restricted-modules-2.6.15-23-686
<lemsx1> dAndy: i'm freeing one connection for you ;-)
<dieman> dAndy: you could try mirror.cs.umn.edu/ubuntu
<dieman> dAndy: its definately not super busy
<dAndy> dieman: and lemsx1: I run a local mirror here at my uni, it isnt the server load that is causing this
<infinity> The fact that mkinitramfs doesn't appear to error out when it can't find ldd is clearly a bug of some sort, but on the other hand, WHY DON'T YOU HAVE ldd? :)
<dAndy> dieman: I tested both locally, and against us.archive
<dieman> infinity: hmmm
<infinity> dAndy: Why are you using ftp:// instead of http:// ?
<dieman> infinity: it may be a broken diversion
<dieman> infinity: that wasn't fixed on upgrade
<dieman>   * debian/ia32.preinst: Correctly remove the ldd.amd64 diversion.
<dieman>     Closes: Malone #38879.
<dieman> heh
<Ubugtu> Malone bug 38879 in ia32-libs "Removing (and purging) package fails" [Normal,Fix released]  http://launchpad.net/bugs/38879
<infinity> dieman: Ahh, ia32-libs...
<dieman> thats definately not right
<dieman> since uh
<dieman> it still didn't work
<dAndy> infinity: partially because kamion very recently added the support and I wanted to test it, and also because there are issues pulling from our local apt mirror with http (we are looking into that issue separately)
<infinity> dieman: Okay, can you reopen that bug and paste this there?
<infinity> diversion by ia32-libs from: /usr/bin/ldd
<infinity> diversion by ia32-libs to: /usr/bin/ldd.amd64
<infinity> libc6: /usr/bin/ldd
<dieman> infinity: i had just deleted the diversion on that machine
<dieman> so what you just listed may be different
<dieman> gurney:/usr/bin>   dpkg-divert --list '*ldd*'
<dieman> diversion of /usr/bin/ldd to /usr/bin/ldd.amd64 by ia32-libs
<infinity> I must have done the dpkg -S before you fixed it.
<dieman> but yah
<dieman> ahh
<dieman> rock
* infinity grabs the vile ia32-libs source package.
<dieman> heh
<infinity> dieman: Do you have more machines like this where an upgrade will explode in similar ways?
<dieman> yah
<dieman> like, hmm
<infinity> dieman: (So I can test a fix)
<dieman> ive got 48 of them
<infinity> Sweet. :)
<infinity> I like a man with redundancy in his bugs.
<infinity> So that when that same man goes and fixes the bug before I'm done debugging it, he can go and reproduce it ALL OVER AGAIN. :P
<infinity> dieman: The preinst has this:
<infinity> dpkg-divert --quiet --rename --package ia32-libs --remove /usr/bin/ldd.amd64
<infinity> dieman: That *should* have worked.
<dieman> hmm
<infinity> dieman: Can you try to reproduce it on another machine?
<dieman> it might have been wrong in the previous version
<dieman> the machines in question were running hoary
<dieman> but sure, i'll try to reproduce it on my machine
<dieman> it may have never tried to upgrade that package
<dieman> i'll look through the upgrade transcript ive got
<vdepizzol> ubuntu 6.06 will come as default human icons or tangerine icons?
<infinity> tangerineish, from the looks of my desktop.
<tseng> human falls back on tangerine for missing icons
<infinity> Or that.
<bddebian> Why would you do:  void *sendmail_stream  and then consistenly do (FILE *)sendmail_stream in the code??
<mjg59> Argh it's just done it again!
<mjg59> Ubiquity seems to hate 
<mjg59> Uhm
<mjg59> Hate not resizing partitions
<infinity> doko: Do you need to make an OOo-l10n upload to match that last OOo upload?
<infinity> doko: I kinda want to know before I go doing evil things like by-hand builds. :/
<kbrooks> bddebian: why? well, i dont know.
<dieman> infinity: does that say /usr/bin/ldd.amd64?
<dieman> infinity: should be /usr/bin/ldd, to remove the diversion of that path
<infinity> dieman: Err, oh.  Does it?  I may be asleep at the wheel. :)
<dieman> hmm
<bddebian> kbrooks: Well the better questions is, can I just do (FILE *)foo;  then just use foo everywhere else?
<doko> infinity: no, the current pending one should be nice; after an rosetta export we should do another one
<dieman> but it has a diversion of ldd.ia32-libs to ldd
<ivoks> infinity: gparted has some serios issues with LVM :/ (but looks like easy to fix)
<kbrooks> bddebian: Casts arent transitive
<infinity> dieman: Easy enough to fix with an else.
<bddebian> kbrooks: OK.  Actually I found a fix on BTS anyway.  Thanks though :-)
<kbrooks> bddebian: i hope you know what i meant :P
<bddebian> kbrooks: I think so
<infinity> dieman: Yeah, you're right.  I'll fix that up.
<dieman> infinity: yah
<dieman> infinity: thx
<infinity> dpkg-divert --quiet --rename --divert /usr/bin/ldd.amd64 --package ia32-libs --remove /usr/bin/ldd
<infinity> dieman: That should do the trick (and not match against and break the new diversion for ia64)
<infinity> dieman: Care to confirm? :)
<infinity> Oh dear god, why is this package debian-native?
* infinity whimpers as he starts uploading the 141MB orig...
<infinity> s/orig/tar\.gz/
<dieman> is it smart enough to search for specific deversions specified with --divert when removing a diversion?
<infinity> I just tested, yes it is.
<dieman> rock
<infinity> Everything on the command line must match.  Anything not is wildcarded.
<infinity> So, the more you specify, the better off you are (if you know exactly what you want to kill)
<dieman> nice
<infinity> It'll be uploaded in... 12 weeks.
<dieman> hah
* infinity massages the phone line to make it go faster.
<dieman> heheh
<wasabi> Heh. That cups interface should totally be enabled... for servers and all.
<infinity> I wish fupload had a progress indicator.
<infinity> dupload, too.
<sladen> infinity: it might miss the release deadline
<dieman> did nfsv4 make it into dapper, or did it definately not get included?
<dieman> i remember lamont asked me at one point because he thought it wouldn't make it in due to some conflict
<dieman> in userspace i think
<infinity> wasabi: Enabling it requires the cups user being able to read auth tokens (so, either in the shadow group, or some clever LDAP setup or something)
<lamont> nfsv4 is in dapper
<lamont> dieman: ^^
<dieman> lamont: rock
<dieman> lamont: it can also serve nfsv4, right?
<infinity> wasabi: Having the cups user in the shadow group by default is considered "bad", so...
<lamont> and the last upload of util-linux fixed cfs.
<dieman> the solaris guy is playing with sol10 and was all depressed
<lamont> dieman: uh... prolly
<dieman> that he couldn't mount off the linux boxes as nfsv4
<dieman> and had to move the default version to v3
<dieman> rock
<infinity> I assume nfs-user-server should work for v4.
<infinity> Though, nfs-user-server is shite...
<ssam> ubiquity is saying that it needs a 2355mb partition for /, is that right?
<Burgwork> sladen, you around?
<sladen> Burgwork: yus
<infinity> doko: You either have the patience of a saint or fantastic upstream bandwidth...
<Burgwork> sladen, the logout dialog goes through gpm/hal now, no?
<infinity> doko: I would have converted ia32-libs to non-native AGES ago if it were my package.  141MB upload for a 10-character fix in debian/* is so not cool. :)
<sladen> Burgwork: while you're here.  Where's the correct place to send a diff to fix  http://www.ubuntu.com/support/faq  in various ways?
<Burgwork> sladen, me
<sladen> Burgwork: yes, the logout dialogue uses g-p-m via hal
<Burgwork> ok, that explains https://launchpad.net/distros/ubuntu/+source/acpi-support/+bug/45517 this bug
<Ubugtu> Malone bug 45517 in acpi-support "Toshiba Tecra A5 no longer whitelisted for suspend" [Normal,Needs info]  
<sladen> Burgwork: you can tell when it switched, because that's when it broke
<Burgwork> it is a gpm bug, not a acpisupport one
<infinity> Burgwork: I suspect that may be the bug mjg59 and I were just yammering about.
<sladen> Burgwork: okay, can you re-assign it and expand on it a bit  (eg.  include the output from  lshal -m  ) and I'll look at it again
<infinity> Burgwork: Assuming that laptop actually is whitelisted in acpi-support.
<Burgwork> infinity, yes, I think it is too
<Burgwork> and yes, it is whitelisted
<mdke> can everyone else hibernate from gdm?
<Burgwork> sladen, back to the website, you know that the website is in moin. I can get you the raw moin and you can diff that
<wasabi> Ooh. Nice to know nfsv4 is there.
<infinity> mdke: I can, now that I fixed my g-p-m preferences.
<mdke> infinity: what did you need to do?
<infinity> mdke: Well, there are two different cases.  If yours is a "fresh ubiquity install that doesn't like you", "dpkg-reconfigure gnome-power-manager" is probably enough to make it happy.
<Burgwork> mdke, go to power prefs and change your lid close to sleep to enable suspend and then back again
<sladen> infinity: that 'laptop-detect' is being run on a buildd and not on the actual machine?
<mdke> infinity: no, not that
<mdke> everything works fine, just not from gdm
<infinity> mdke: If it's an old installatoin that seems to have lost its mind on upgrade, you likely need to gconf-editor your way to bliss (I, apparently, had custom settings for g-p-m which claimed I couldn't suspend and such)
<infinity> mdke: From gdm logout, or login?
<mdke> I can suspend, and hibernate, from inside Gnome. But in gdm, I can suspend, but can't hibernate
<infinity> mdke: Oh, at the login screen, then?
<mdke> infinity: yes
<infinity> mdke: Haven't look at that.
* infinity will have to log out to see.
<mdke> no, it's not a common use case I immagine
<mdke> just tried it on the off chance
* mdke heads for malone
* infinity decides he has too much junk running to log out.
<infinity> sladen: laptop-detect and other things.  Basically "postinsts in general".
<mdke> no one uses hibernate anywho
<infinity> sladen: We need a list of packages that need a dpkg-reconfigure from ubuquity to fix machine-specific settings.
<sladen> infinity: just do *everything" ?
<infinity> That takes a while...
<infinity> Some postinsts are... Uhh... Long.
<infinity> (fc-cache, YAY!)
<infinity> After developing an installer that's meant to make things faster, I'd prefer not to regress too much. :)
<dieman> heh
<dieman> and scrollkeeper
<dieman> i remember the days of xml errors
<dieman> with scrollkeeper
<infinity> fc-cache beats scrollkeeper on my machine for ickiness.
<infinity> It's seriously unhappy with my almost-full, very-fragmented, slow-as-shit laptop hard drive.
<infinity> Last fc-cache run (earlier today) took 3 minutes.  I thought it had hung.
<infinity> I think it may be time for some housekeeping. :)
<mdke> dieman: scrollkeeper will still give you xml errors, if present
<dieman> yeah
<infinity> (Given that this is a 2GHz PentiumM with 2GB of RAM, that seems excessive)
<infinity> mdke: Speaking of, we do currently have some errors.  Are you the keeper of all things doc error related?
<dieman> the preinst for lvm2 keeps throwing me a error 10, too
<mdke> yeah, the zh_TW one?
<dieman> need to figure out wtf
<infinity> mdke: That's the one.
<mdke> infinity: I'll do the last batch of adding translations on sunday, and i promise to check scrollkeeper
<infinity> mdke: Please do.  Several times.
<infinity> mdke: I only notice the errors on cron.monthly, which isn't nearly often enough. :)
<mdke> it's because zh_TW didn't translate that file, so we have to include an english placeholder
<mdke> I'll make sure it's sorted
<omeg> Hey infinity, can you tell me how I can fix a PNG's palette with GIMP? I can't seem to find the function.
<infinity> omeg: Dialogues->Colourmap
<dieman> infinity: btw, thanks for looking into the issue i was having
<dieman> infinity: i wouldn't have figured it on my own for a couple more hours
<infinity> dieman: No sweat.
<omeg> Thanks.
<wasabi> So what ever happened to per-user printers and direct printing without a local cupds?
<wasabi> I remember hearing about that.
<wasabi> (to remote cupsd)
<omeg> Can't seem to drag and drop items, though. I guess I'll have to change the composition.
<infinity> omeg: Yeah, what I do is write down all the current colours and their map position, then change them one at a time.
<infinity> omeg: FWIW, I just checked on an XP machine, and Image->Mode->Color Table appears to be pretty much the same thing in Photoshop.
<infinity> omeg: So, you could have done it with your evil non-free tools too. :)
<omeg> Since you already fixed the Ubuntu one (could you send that one to me?) so I'll continue with the Edubuntu one.
<omeg> Yeah, Color Table does the exact same, but I thought that GIMP could let me do drag 'n drop or something like that.
<omeg> Haha, the worst about this is that I keep trying to do simple keystrokes like "z" for the zoom tool, but it gives me something completely different instead.
<Burgwork> sladen, http://www.ubuntu.com/support/faq?action=raw
<infinity> omeg: I'd sure like it if it did.
<omeg> "Z" seems to have given me a magic wand.
<infinity> omeg: But for a 16 color image, it's not the end of the world.
<infinity> omeg: For 256 colour indexed, the DnD would be very nice.
<omeg> Yeah, you're right. Only a few colors need to be transmogrified, anyway.
<infinity> omeg: Feel free to file a wishlist bug on the GIMP. :)
<infinity> http://lucifer.0c3.net/~adconrad/usplash-artwork.png <--- Current artwork.
<omeg> Yeah, I will
* omeg finishes Edu and Xu and then tests Dapper Flight 7.
<sladen> infinity: 404
<omeg> Yeah, that seems to be down.
<infinity> Err, s/lucifer/cerberus/
<infinity> Yay, internal network.
<omeg> s/lucifer/cerberus/?
<infinity> Oh, you don't speak regex.
<infinity> http://cerberus.0c3.net/~adconrad/usplash-artwork.png
<sladen> omeg: subsitute/this/for that/
<omeg> :P
<infinity> s/for/with/
<_ion> For comparison. http://johan.kiviniemi.name/pictures/usplash/
<omeg> Thanks
<omeg> I'm so glad that 0.2 one was dropped. :P
<sladen> like it.
<sladen> the dithering and colours now look *much* better, especially when they are side-by-side
<infinity> It looks quite nice when "squished" on a 4x3 display, too.  Which is good.
<infinity> (Because I didn't feel like squeezing in any auto-scaling or two-versions-of-the-splash BS right before release)
<sladen> infinity: you can't tell anyway.
<infinity> Yeah, it looks fine on my 1400x1050 FB.
<_ion> Auto-scaling wouldn't work very well with such a small palette
<infinity> I'm happy with it.
<omeg> Yeah. I did tell that mine was squished on this widescreen display when I saw it.
<_ion> The dithering needs to be edited by hand for it to look as good as possible.
<omeg> But it's okay. I can't expect everything to look perfect.
<infinity> _ion: Mithrandir and I were tossing around the idea of an SVG-driven usplash for Edgy, to circumvent the whole issue. :)
<sladen> infinity: who knows if you're "centred" or "stretched" on any particular LCD.  It's a function outside of your control.
<omeg> SVG-driven usplash would be awesome.
<dieman> haha
<dieman> svg usplash
<sladen> it was an idea there from the start
<infinity> Well, it means we can query the display res, guess at the aspect ratio, and make the image on the fly.
<sladen> along with the realisation that you could shove a 150MB MPEG into the initramfs and just *stream* it
<infinity> But it also means pulling in some crazy huge library deps unless we can figure out a way to do it slimer.
<sladen> infinity: on i386, the size is "always" 640x400
<Burgwork> sladen, our company wrote our login screen in flash, so i think I have seen stupid
<infinity> sladen: Not true anymore.
<infinity> sladen: vga16fb has just been changed to do 640x480 on a select few machines.
<sladen> infinity: but vesa, efi, powerpc, sparc, hppa... would be
<infinity> sladen: (Very few)
<sladen> infinity: oh, ah
<infinity> sladen: Plus, there's the vesa case.  And all the other arches, yes.
<omeg> What about EFI?
<infinity> Anyhow, vga16fb at 640x400 is still 98% of the expected install base, so good enough for me.
<sladen> infinity: you could add a test just for 640x400 and display something else
<omeg> Isn't that supposed to be the next best thing since cars on wheels?
<infinity> sladen: Yeah, I was going to do that, but ENOTIME at this point.  I'd rather not make the changes.
<sladen> infinity: mmm, wonder if you can tell if you're running inside VMware;  then use 640x480
<sladen> infinity: which would improve the quality of screenshots
<infinity> sladen: Not that the code's hard, but it's still A) new code, and B) doubling the size of usplash-artwork.so for very little benefit.
<infinity> Screenshots of omeg's new art seem to look good anyway, so I'm not terribly stressed about it.
<omeg> Argh, I'm just gonna do this in my evil proprietary software instead.
<omeg> Turn around your mouse (on the x axis) 180 degrees and then try using it. That's kind of how I feel about using GIMP. New.
<sladen> omeg: try 'gimpshop'  which is GIMP dressed up (eg. menus rearranged) to look like photoshop
<infinity> Okay, that's neat.  I'd completely forgotten that I even had an ia32-libs upload going until I saw it on -changes.
<infinity>  ia32-libs_1.4ubuntu18.tar.gz 137679.0 kB, ok (1981 s, 69.50 kB/s)
* infinity spits at his DSL.
<dieman> hahaha
<Harti> hello
<Harti> https://launchpad.net/distros/ubuntu/+source/xfce4-taskmanager/+bug/45668
<Ubugtu> Malone bug 45668 in xfce4-taskmanager "xfce4-taskmanager - random crashes" [Normal,Unconfirmed]  
<omeg> infinity: maybe you could test to see if this one is correctly done for me? http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_newsuggestion_0_8_TEST.png
<omeg> Sometime, anyway. I guess I'll finalize all of this tomorrow. I'm going to test Dapper now.
<omeg> See you tomorrow.
<infinity> So, accidentally sending a SIGSTOP to every process on your system is actually rather inconvenient.
* infinity files that in the DDTT bin.
<wasabi> Interesting. Perl won't compile in qemu.
<ProN00b> i know this prolly has been asked in here bevore
<ProN00b> but what is the status on java, i mean they made some fuzz in the news with a new licence and stuff
<ProN00b> will i be able to get sun java from universe in the future ?
<LaserJock> it is, I think
<mdz> infinity: is there any particular reason why suspend is a local-premount hook rather than an init-premount hook?
#ubuntu-devel 2006-05-25
<mdz> ProN00b: universe is only open source software; sun java is not open source
<infinity> mdz: Probably just the belief that anything requiring a hard drive belonged in local, back when Jeff first organised it all.
<mdz> ProN00b: the new license allows for it to be in multiverse, which it is
<ProN00b> mdz, then multiverse ?
<mdke> elmo: around?
<ProN00b> can i get it on breezy ?
<infinity> ProN00b: It's in multiverse in dapper.
<ProN00b> ok
<ProN00b> thats cool
<wasabi> Sun open sourcing under a real license would be a little disappointing.
<wasabi> Since so much work has gone into classpath/etc
<ProN00b> whats classpath
<wasabi> free implementation of the java class libraries.
<wasabi> pretty good.
<infinity> mdz: And i realised I missed adding that "Stand by, resuming from hibernate..." message in the last upload.
<infinity> mdz: I suspect that's where you were poking in there? :)
<mdz> infinity: yes, I'm taking care of it
<mdz> but the message will be ugly due to it being in local-premount rather than init-premount
<mdz> too late to shuffle things around
<mdke> Znarl: around?
<nomed> umm .. what does generate /dev/disk/by-label ?
<infinity> mdz: http://cerberus.0c3.net/~adconrad/sysv/sysvinit.debdiff
<infinity> mdz: And yes, that 7 lines of debug-code-diff could be reduced to a one-line diff.
<infinity> mdz: And it works smashingly.  No more usplash restarts (the text resetting is really ugly and "we couldn't quite do it right, so here you are" IMO)
<infinity> nomed: udev should, ideally.
<infinity> nomed: Why?
<mdz> infinity: that's how I did the patch the first time, and we decided to do it the current way instead because it was less intrusive
<infinity> mdz: Ahh, I don't think I ever saw yours, then.
<mdz> and that was 4 weeks ago
<infinity> mdz: This works much better.
<nomed> infinity: i'm trying to figure out how to use the root=LABEL=xxx
<mdz> (actually, I did it with a pid file for usplash, to avoid users being able to keep their processes alive during shutdown by naming them 'usplash')
<nomed> but debugin the initramfs it seems i do not get the by-label entries ..
<infinity> nomed: You just do.  But it helps if your partitions have sensible labels on them.
<infinity> mdz: I did it this way to protect the whole usplash namespace intentionally. (so as to not catch a stray usplash_write in progress or something).
<infinity> mdz: IMO, a user naming a process usplash so it doesn't get killed is shooting himself in the foot and I don't much care. :)
<infinity> mdz: Also, not having killall start reading random pid files seemed a lot less intrusive to me.  It's already walking proc, so we get this info for free.
<infinity> mdz: It also knows the full path to the executable, if you think "/sbin/usplash" would be safer.
<mdz> infinity: he's not only shooting himself in the foot, he could be malicious and interfere with our attempts to quiesce the system before turning it off
<mdz> infinity: there was nothing random in my patch; it accepted a parameter to exclude a pid from being killed
<infinity> mdz: Okay, fair enough for randomly-names images.  /sbin/usplash wouldn't suffer that issue, though.
<infinity> mdz: I didn't mean to imply that it was random, just "more intrusive", perhaps.  Either way, they're both pretty simple.
<infinity> mdz: Mostly, I just felt the current solution was "good enough for beta", but not ideal to hand out to reviewers (and have users watching on shutdown for 3 years)
<infinity> The text starting over from the bottom is a bit unsettling and odd.
<nomed> infinity in which cases the "parse_numeric" should run mknod ?
<nomed> or better .. in which cases is needed root=4:2 for ex .. ?
<infinity> Well, in theory, you'd never use a pure numeric input.
<infinity> That's why we try to do it for you.
<nomed> i see :)
<nomed> so in real it is "a special case" while using udev within an initramfs ..
<infinity> nomed: And in the case of /dev/disk/blah/blah, parse_numeric does nothing.
<nomed> yep ..
<infinity> nomed: Since we will be mounting /dev/disk/blah just as you specified it, we don't do a mknod and mount /dev/root
<nomed> ok thanks ..
<nomed> i wanted just to be sure 
<sladen> infinity: you can go through   readlink /proc/NNN/exe  to find out where the actualy exe is.  And a usplash_write doesn't matter as it's momentary and doesn't matter if killed
<infinity> sladen: I don't have to go through it, killall5 already does.  p->argv0 is the full path.
<infinity> sladen: So, it's a simple tweak to the patch.
<infinity> I just used p->argv0basename because... Well, because I did. :)
<infinity> (Simple fix, though)
<sladen> mjg59: is there a solution for quashing the power-button event on resume yet?
<tritium> I visited http://www.sandiacomputer.com today, and they had a prominent machine on their floor running breezy!  I will definitely buy from them...
<LaserJock> tritium: cool
<tritium> Definitely.  I was very pleased.  I'm thinking of calling into their radio show, and plugging ubuntu a bit :)
<LaserJock> tritium: but breezy? that is so 5.10 ;-)
<LaserJock> tritium: yeah, do it
<tritium> I'll be sure to encourage and/or help them get dapper on there soon.
<AlinuxOS> mjg59, ping
<mdke> does anyone know anything about sending large quantities of email? It's not really on-topic but I could do with some expert guidance
<mdke> I would like to send an email to lots of ubuntu contributors who are listed in a file, but I am concerned about getting blacklisted or something, I don't know how these things work
<Amaranth> send a seperate email for each one
<Amaranth> sending to lots of people all in one go will probably flag it as spam
<Robot101> if you operate the sending server, or the administrator is happy for you to do it, you can send one mail to multiple recipients with no problems
<Robot101> (if you BCC them, rather)
<mdke> yeah, I was going to send it as separate emails
<mdke> no problems?
<Robot101> yeah, it's not apparent by looking at a mail how many people it was BCC'd to
<Robot101> not having the sender's address in the To: line may get you a small spam score, but unless you're otherwise odious, nothing should drop it for that alone
<mdke> right, but my isp would know
<Robot101> you should use a mail server who is happy for you to send such a mailing, and you should also make sure your intended recipients are happy to receive it :P
<mdke> Robot101: well, that's pretty difficult, should I mail them to ask? ;)
<Burgundavia> mdke, one further thing. Are you expecting all these people to respond?
<mdke> Burgundavia: no, no
<StevenK> This might end up like Homer Simpson with his autodialer.
<bddebian> Howdy peopleseses
<Robot101> well, just be polite, either state you're not going to send any more messages, or allow people a way to indicate future interest, or a way for you to never mail them again. :)
<Robot101> mdke: what's the mail for?
<mdke> it's about relicensing the wiki
<mdke> s/re//
<Burgundavia> Robot101, we are selling them a bridge with some land in florida
<StevenK> mdke: Ah. "Are you happy for your changes to the wiki to be GPL?"
<mdke> no. anyway, I don't think my ISP is going to deal with this very well. I think i will hold out and try and grab elmo
<mdke> meh, stuff is so difficult
<mdke> has anyone seen elmo around? he's at debconf right?
<zul> hey
<tseng> thom: yay typo
<infinity> mdke: apt-get install postfix ; use "localhost" as your SMTP server in your mail client, boom, you're an ISP.
<mdke> yeah, the mail is on its way
<infinity> mdke: Assuming your ISP doesn't block port 25, that's all you need to do to not worry about this getting filtered.
<mdke> infinity: i did a hasty check for my ip in some blacklists, hopefully most people will get the email
<Chipzz> wow
<Chipzz> cool :)
<Chipzz> http://chipzz.studentenweb.org/vimomnicompletion.png
<Chipzz> didn't know this actually worked in the terminal versions of vim too :)
<mdke> ok, i got my copy
<mdke> you guys?
<Chipzz> (ctrl-x ctrl-o for anyone who cares ;P)
<infinity> I dunno, was I in the list?
<mdke> infinity: have you ever edited the wiki?
* infinity shrugs.
<infinity> Probably?
<mdke> heh
<infinity> Ahh, and there's the mail. :)
<mdke> good news
<mdke> it's still churning them out here
<mdke> i can't wait for the rejections
<infinity> mdke: Why public domain?  Just to avoid attribution hassles that a free copyright would bring?
<mdke> yeah, that's basically it. Attribution, and relicensing
<crimsun> I'm all about public domain.
<infinity> Well, relicensing is simple if you pick an uber-free licese, like the MIT/X11/BSD license.
<infinity> But some people dislike having their attribution stripped, that's all.
<infinity> For a wiki, I don't really give a shit. :)
<infinity> None of the content there is brilliant enough for me to want my name on it anyway.
<mdke> infinity: we looked at those, they all seemed to contain a "if you modify, you must use the same licence" thing
<mdke> but anyway, it's a wiki
<mdke> as you say
<infinity> mdke: No, with BSD/MIT/X11, if you modify, you must retain the license text.  That's not the same as not being able to relicense.
<mdke> hmm
<infinity> mdke: BSD/MIT/X11 stuff can be relicense as GPL (a common case in the free software world), proprietary (Windows has lots of BSD code in it), or anything else you want, so long as the copyright text is preserved somewhere.
<infinity> mdke: Hence what I meant about "using a free copyright license keeps attribution intact", since that's really all the BSD license does.
<mdke> ok, so sort of dual-licensed on modification?
<infinity> BSD reads more like "public domain with attribution"... Which is nonsense, since public domain protects no rights, so BSD uses copyright law to protect exactly one right -- attribution -- and nothing else.
<infinity> You could sum the license up in one sentence, but it would be less elegant: "Do whatever you like with this code, but if you do, you must keep my name in it, kthxbye"
<infinity> mdke: Like I said, for a wiki, I don't care one way or the other anyway.  Just typing for the sake of typing, I think.
<mdke> well, I'm learning
<mdke> I didn't look closely at those licenses
<infinity> mdke: Well, and because I don't think anyone involved with Free Software should ever be confused about licensing.
<infinity> (since we hinge a LOT on understanding and manipulating copyright law... More so than priprietary software vendors do)
<mdke> sure
<mdke> that was part of the reason for trying to clarify the wiki situation
* infinity nods.
<infinity> Just be glad that most Ubuntu users probably aren't license pedants, so the relicensing should go okay.
<mdke> :)
<infinity> Had you sent that to a bunch of Debian users/developers, I'd fear for the flamewar that would ensue based on the conclusion of the email.
* mdke realises he should have set reply-to community-council
* bddebian starts flaming :-)
<infinity> (The bit that says "If we don't hear back from many people, we'll assume it's all good and relicense the whole thing")
<infinity> Since you so CANNOT do that legally.
<mdke> infinity: well, that's quite debateable, I think
<infinity> If you don't have consent of the original content writer, you can either stop distributing their content or keep the license as they intended (whatever that was).
<infinity> You can't relicense their stuff.  Ever.
<mdke> you could quite easily argue that posting to a wiki implies an intention to give the content away
<mdke> i think, anyway
<mjg59> mdke: You could argue that, but you'd lose the lawsuit
<infinity> Only if we have a TOS that says that.
<mdke> mjg59: thanks :/
<infinity> Posting copyrighted material on the internet doesn't magically make it free.
<Burgundavia> infinity, really? half the internet seems to think that
<mdke> no, but posting it to a collaborative resource where everyone modifies the pages all the time could imply a waiver of copyright
<infinity> Burgundavia: I know they do.  Doesn't make them right.
<mjg59> mdke: Copyright is one of those things that it's very hard to give up implicitly
<mdke> infinity: what they think *is* exactly the point
<Burgundavia> infinity, I have dealt with fun at wikipedia
<infinity> "The website HTML, text, images audio, video, software or other content that is made available on this website are the property of someone - the author in the case of content produced elsewhere and reproduced here with permission, or Canonical or its content suppliers. Before you use this content in some way please take care to ensure that you have the relevant rights and permissions from the copyright holder."
<infinity> mdke: That's OUR legal disclaimer, linked on the bottom of every wiki page.
<mdke> yeah, I know.
<infinity> mdke: So, there's no reason to imply that users should think they don't own the content they post.
<infinity> Cause we clearly tell them that they DO.
<mdke> in respect of the website
<infinity> You're going to split hairs and tell me that www.u.c and wiki.u.c aren't related, despite sharing the same legal notice?
<infinity> mdke: Oh well.  I wish you luck when you butt heads with someone with less of an "oh well, I don't really care about wiki content anyway" attitude than me.
<mdke> infinity: that copyright notice doesn't really exclude what I'm saying, because I'm relying on an implied license
<infinity> mdke: There's no such thing as an implied license.
<mjg59> mdke: Can you point at any cases where the concept of an implied copyright license has been upheld?
<infinity> mdke: We have an implied license to distribute the content if it's posted, we do not OWN it, so we can't strip the owner's copyright.
<mdke> mjg59: I'll have a look, I haven't done any research
<mdke> but licenses are contracts, and you can easily have contractual obligations which arise from conduct
<infinity> You're talking about implied copyright tranferral, not implied licensing.
<mdke> especially estoppels
<infinity> You would never argue that if I posted a cool image I drew on a bulletin board that it would imply that the board owner owned the image, would you?
<mdke> no, i wouldn't
<infinity> How is this different?  At all?
<mdke> I'm not arguing the wiki owner owns the copyright
<infinity> Yes you are.
<infinity> You can't relicense it in the public domain if you don't own it.
<mdke> well, I don't intend to
<mdke> I'm arguing that when you post a document to a collaborative resource that you know is going to be changed by others, you are granting a licence to the world to use the material as they wish
<infinity> You have an implied license to distribute on your website, where it was posted.  That's the only implies license I see without a TOS stating otherwise.
<mdke> but, it's only arguable, I think
<mdke> I'm not saying I'm right for sure
<infinity> You'd definitely lose that one in court. :/
<mdke> that's hard to say, since neither of us have specified which legal system we're talking about or looked anything up
<infinity> Canada and the US are the two I often play in.  Australia, recently, since it's become more relevant to me since moving here.
<infinity> You'd be screwed in all 3 of those.
<infinity> I suppose you'd be fine in Taiwan, where they only vaguely know what "copyright" is to start with.
<dieman> hah
<infinity> (Which is great IN Taiwan, a pain when trying to do business internationally)
<mjg59> mdke: But that obviously can't hold, since people posting to Wikipedia are only consenting that their material be released under the GFDL
<mjg59> (which is a lot more restrictive than public domain)
<mdke> mjg59: wikipedia specifies the GFDL
<bddebian> Oh, I got it too 
<mdke> but let's not argue about it
<infinity> mdke: Right, ans we specify nothing but "you own the copyright to the stuff you post"
<mjg59> mdke: So if people posting to one wiki are only doing so in the expectation of giving up some rights, why are you arguing that people posting to another wiki are implicitly giving up all rights?
<mdke> mjg59: because in the case of wikipedia their expectations are defined by the specific statement of what licence material is released under
<mjg59> I don't think you can argue that an expectation of "Do whatever you want with this" holds
<mdke> anyway
<mjg59> Since that doesn't apply to the most popular wiki in the world
<mdke> who cares? we're doing it the safe way anyway
<infinity> mdke: "If you don't say anything, we'll assume consent" isn't safe.
<mdke> infinity: in that case, I suggest you write to community-council@lists.ubuntu.com
<infinity> Note that, unlike trademark law, it's is NOT up to the copyright holder to protect their copyright.  It's up to the copier to make sure he has the legal rights to copy.
<mdke> but in the absolutely worst case scenario, people can only bring a legal suit if they've suffered a loss
<infinity> So, we can NOT just say "oh, well, we pinged you, you didn't respond, it's ours"
<mdke> and they are hardly likely to lose out on profit made by wiki material
<mjg59> mdke: No
<mjg59> mdke: Most legal systems have statutory damages for copyright infringement
<infinity> They can bring criminal charges.
<mjg59> infinity: That's rather more dependent
<infinity> Copyright is not just a civil offense in most countries.
<infinity> (But we'd just take the content down after a C&D, it would never hit a court)
<mjg59> In the UK, at least, small scale infringement for non-profit is generally civil rather than criminal
<mjg59> (though that may have changed somewhat with the EUCD implementation)
<mdke> no one enforces criminal copyright infringement in the UK
<infinity> Ahh, fair point on the severity.
<mdke> even microsoft have to do their own civil enforcement
<mdke> i'm not used to other systems tho
<infinity> No, no.  They LIKE to do it. :)
<mjg59> mdke: ? 
<mjg59> Large-scale copyright infringement is often dealt with as a criminal offense
<mjg59> (in the UK)
<mdke> that's not been my experience
<mjg59> FACT and FAST often work with the police
<mjg59> "TWO JAILED AFTER POLICE RAID ONE OF UK'S BIGGEST PIRATE DVD FACTORIES"
<mjg59> (http://www.fact-uk.org.uk/site/latest_news/index.htm)
<mdke> TWO JAILED AFTER UBUNTU WIKI MAYHEM
<infinity> (not that this is relevant to us, really)
<infinity> But that's not the point.
<mjg59> "FILM piracy has become such a problem that the Metropolitan Police has created a specialist unit to fight it"
<mjg59> (etc)
<infinity> Arguing that what you're doing is okay because it's smaller scale isn't going to win friends and influence people.
<mdke> *pleeease* take it up with the CC
<mdke> I didn't take this decision
<Burgundavia> "but I only shot one person judge"
<infinity> mdke: Is there a log of the meeting where the decision was taken?
<mdke> infinity: depending on how far back they go, sure
<mdke> I don't know what the right date is though
<mdke> oh well, I certainly didn't mean to piss you guys off
* bddebian isn't pissed off
* mdke hugs bddebian 
<bddebian> :-)
<infinity> mdke: I'm not pissed off, so much as flabbergasted that an email like this was sent out with anyone really tearing apart what it meant first, that's all. :)
<infinity> mdke: I still love you, honest.  And I'll make sure dholbach hugs you sometime.
<mdke> thanks
<mdke> infinity: the point i think is this: a task like this is impossible to do by asking everyone and getting their consent. An attempt at a reasonable compromise might be to give people a month to withdraw the material, if they care, and if they don't reply, assume that they've given up the material. Where that's wrong, it can be dealt with on a case by case basis by the CC., no doubt 
<mdke> now speaking strictly legally, that may be not idea, but it's the only practical way, I think
<mdke> ideal*
<dieman> im with inifinity on this, i was surprised by the email
<mdke> there is no alternative
<mdke> aside from starting from scratch, and ditching a lot of material which frankly, people are happy to be used
<dieman> http://onyserious.ytmnsfw.com/
<bddebian> WTF? Bug #13329
<Ubugtu> Malone bug 13329 in debian-installer "syslinux.cfg not found in the archives" [Minor,Unconfirmed]  http://launchpad.net/bugs/13329
<bddebian> Should hoary bugs be rejected at this point?
<crimsun> bddebian: if submitters refuse to test current dapper, I would think so.
<lamont> hoary is still a supported release
<bddebian> It is?
<lamont> so if it's in main, and would qualify as RC, I think it still gets to be fixed..
* lamont ponders...
<lamont> 5.04+18 months --> 6.10
<bddebian> Wow, hi lamont, haven't "seen" you in a while -)
<lamont> and this is may.  so 5 more months
<crimsun> lamont: yes, but would we ask them to test a fix in /hoary/ or in /dapper/?
<lamont> heh - been lurking
<lamont> crimsun: if it's RC, then the fix goes into hoary-{updates,security} as appropriate, if not, then "please test in dapper"
<crimsun> afaics, our policy has been to ask them to reproduce the issue(s) in dapper first
<lamont> but that's just my opinion
<lamont> mind you, RC bugs in hoary at this point are pretty much security bugs... :0)
<bddebian> lamont: Yeah but this bug is pretty vague
<lamont> hrm.. then while you're asking for clarification, you can ask if they can reproduce it in dapper, ne c'est pas?
<bddebian> No habla france'
<lamont> me neither
<bddebian> Part of the issue is that I don't want to sound more ignorant than I already feel.  Does that bug make sense to anyone else?
<lamont> although this network here makes me feel like I'm in oxford all over again
* lamont looks
<lamont> or rather, tries
<infinity> lamont: `That's obvious, since it should have been "n'est ce pas?"
<infinity> lamont: (obvious that you don't speak french, that is)
<bddebian> WTF is n'est ce pas anyway? :-)
<lamont> infinity: yeah - whatever.
<lamont> bddebian: "isn't it so" or some such
<bddebian> Ah
<lamont> roughly equivalent to "ya know?"
<lamont> bddebian: heh.. let me go kick doko for us.
<lamont> ENODOKO
<lamont> bddebian: I'll poke him next time I see him
<lamont> and he can reject his own bug. :-)
<bddebian> OK
<lamont> mdke: I have a complaint about your email.  please use newline characters from time to time.  kthxbye
<mdke> lamont: sorry, I didn't know how to do it with the script that I was given
<bddebian> Gawd I hate looking at these old bugs
<mdke> my apologies
<infinity> Hit enter occasionally in your text editor before saving the mail template?
<lamont> wimpy excuse.  whatever. :-P :-)
* mdke shuffles off
<mdke> this hasn't been a success :/
<lamont> lol
<Burgundavia> mdke, spamming is hard, no?
<mdke> apparently so
<mdke> they told me it would be so easy!
<mdke> big bucks from home
<mdke> lies
<infinity> You forgot the penis enlargement bit, that's why.
<mdke> also, what we have here is a case of shooting the technologically incompetent messenger
<bddebian> hahaha
<mdke> who chose me for this job anyhow
<infinity> You probably volunteered.
<infinity> Sucker. :)
<bddebian> Bah, fsck it, I can't upload to main anyhow
<lamont> mdke: my complaint was specificially about the messenger, you'll notice....
<lamont>  /msg infinity picking on mdke is fun, huh
<mdke> lamont: yeah, hence the "technologically incompetent" bit
<infinity>  /msg lamont And how!
* mdke does some more shuffling
* bddebian hugs poor mdke
<mdke> lamont: everyone more competent to be the messenger was whinging about having to release some OS or something
<lamont> they claimed to have real work to do, is that it? :-)
<mdke> precisely
<shawn_home> mdke: the wiki license change is fine with any of my documentation bits :)
<shawn_home> stupid yahoo treated your email as bulk good thing i saw it 
<Lathiat> linux-image-amd64-xeon - Linux kernel image on Intel x86_64.
<Lathiat> i love that :)
<dieman> hah
<dieman> nice
<dieman> the x86_64 part, really
<dieman> because it should be Intel em64t, i guess
<dieman> in eithr case, ugh
<dieman> either
<zyga> hey
<zyga> has anyone seen mvo?
<Burgundavia> zyga, likely relaxing. It was a distro holiday yesterday
<zyga> Burgundavia, bah, I have a update-manager backtrace for him
<xor_not_and> does ubuntu use any BSD style internals, like init instead of SysVInit?
<xor_not_and> (ok..then) is there anything original in ubuntu other than the graphics?
<sladen> lmanul: ping
<sladen> lmanul: I want to have a talk about g-p-m if you're around
<Riddell> mdke: are we going to have the whole ubuntu book included or just an excert?
<mdke> Riddell: just exerpts, afaik. But I don't know much about it
<Riddell> mdke: who would know?
<mdke> Riddell: Mark, Jane
<Riddell> thanks
<mdke> ok
<sladen> mdke: Desktop and Support chapters AFAIK
<mdke> and Kubuntu
<\sh> mdke: ah..did you receive my email about wiki license change?
<mdke> \sh: yes
<mdke> \sh: I'm unlikely to respond to all the mails I get answering that, I'm afraid
<\sh> mdke: I can imagine :) but I think this matter has to be addressed somehow...because I don't want to have my personality in the public domain ;)
* hunger wonders how the licence can just get changed after the fact, but is not really bothered.
<sladen> mdke: I'm happy for all my changes to be considered PD
<mdke> thanks
<ajmitch> mdke: what happens if you can't reach every wiki contributor, or some don't want to go PD?
<mdke> ajmitch: they write to community-council@lists.ubuntu.com with their concerns
<mjg59> mdke: Having thought about it, I don't think I'm happy with my stuff being PD
<mjg59> I don't want it being incorporated into non-free works
<mdke> mjg59: same applies ^
<nomed> hi all ...
<nomed> i was reading the wiki page "LiveCDPersistence", i'd like to know if there is an error .. in that case i can edit it ...
<nomed> in casper the function:
<nomed> ** find_cow_device **
<nomed> search first a device with label casper-rw 
<nomed> and if not it tries to mount a vfat file system ..
<nomed> and then check if /cow-backing/casper-rw exists ..
<nomed> in the wiki page it's explained :
<nomed> a) while using label approach .. vfat "won't work"
<nomed> b) while using "Loopback File" "This partition can be any type" vfat , ext3 ,ext2
<nomed> why "vfat" won't work ? it seems it should ..
<nomed> and i'm not sure about this . but it seems even that "Loopback File"  works just on a vfat partition ..
<nomed> Mithrandir: around ?
<bddebian> Hello
<pygi> hey bddebian 
<bddebian> Hi pygi
<omeg> Wooh, first bug report. https://launchpad.net/distros/ubuntu/+bug/45739
<Ubugtu> Malone bug 45739 in Ubuntu "Loud startup noise during boot" [Normal,Unconfirmed]  
<omeg> Not really a bug, anyway.
<omeg> Aha.
<omeg> Very cool.
<lmanul> sladen: pong
<lmanul> A little late, sorry :)
<sabdfl> help
<pygi> sabdfl, what happened?
<sabdfl> anybody else seen "Computer" and "Wastebasket" show up on their desktop?
<phanatic> sabdfl: i saw them, but they disappeared after reboot
<AlinuxOS> mjg59, hello
<AlinuxOS> mjg59, I've updated package, thank you.
<sabdfl> phanatic: ok, thanks, i'll try
<phanatic> sabdfl: do you have some free minutes maybe?
<sabdfl> phanatic, sure, privmsg
<sladen> lmanul: still around regarding g-p-m?
<lmanul> sladen: yep
<sladen> lmanul: -> /query
<Mithrandir> nomed: hiya
<nomed> hi Mithrandir
<nomed> could you scroll back ?
<nomed> that "persistent" (maybe) issue 
<nomed> i guess there are wrong infos on the wiki ...
<Mithrandir> nomed: you can't use vfat as the file system of the cow device since vfat doesn't have such things as owner, modes, etc.
<nomed> 'elif [ "$(get_fstype ${devname})" = "vfat" ] ; then' in find_cow_device ?
<mdke> hi nomed
<Mithrandir> nomed: if you want to store the cow fs in a file, you have to use vfat for the fs where you store the cow file.  If you use a device directly as a cow device, it can be any fs which is supported by the initramfs and which supports traditional unix semantics.
<nomed> hey mdke :)
<nomed> Mithrandir: k thanks ..
<Mithrandir> nomed: I believe the code works the way I've told you now, if not please do tell me and I can fix it.
<nomed> Mithrandir: yes .. the code works in this way ..
<nomed> the problem are not clear infos on the wiki ...
<Mithrandir> nomed: the reason for not allowing the cow file to be on ext2/ext3 is you can't mount those without causing data corruption if they're in use by a suspended system.
<nomed> see: LiveCDPersistence (Using a Loopback File) ...
<nomed> Mithrandir: yep :)
<nomed> Mithrandir: other question ... 
<nomed> some months ago i played with unionfs as rootfs ...
<nomed> and there were serious problem during the "umount" ...
<nomed> and not just in case of "suspend" ...
<nomed> i'd like to try to play with casper allowing to boot an iso from an hd partition instead of a cdrom ..
<nomed> do you already know any other  particular issue doing this ?
<Mithrandir> just make a casper/ directory and put a filesystem.squashfs there, on a vfat partition and it'll just work.
<nomed> yes ...
<nomed> so you do not suggest to use ext3 *never* ?
<Mithrandir> for casper?  Sure, using ext3 on a cow device directly is fine.
<nomed> emm ..
<_ion> #define cow \
<nomed> i mean i put the iso file on an hd ...
<nomed> and i boot it from there ...
<nomed> i'll abviously need to mount -o loop the iso ..
<Mithrandir> _ion: copy-on-write.
<_ion> mithrandir: Ah, thanks.
<nomed> and then search the squashfs ...
<nomed> but i'd like to know if it's a bad idea doing that on an ext3 fs ..
<Mithrandir> nomed: no, casper doesn't support putting the ISO on a hard drive.  It supports putting the squashfs on a hard drive.
<nomed> Mithrandir: i see ...
<nomed> but i'd like to add that ...
<nomed> i don't mean i'd like to see it on casper :)
<nomed> just that i would test it ..
<Mithrandir> sure, that should be fairly easy to add
<nomed> yes .. the question is if i shouldn't consider doing that on an ext3 fs 
<Mithrandir> it should be fine as long as you don't suspend to disk at the same time
<nomed> ok 
<mbiebl> Keybuk: ping
<nomed> two questions more then it' over :)
<nomed> Mithrandir: if i add as rw layer an hd partition, is it possible that there can be "data corruption"?
<nomed> again ext3 fs ..
<nomed> i 'm not sure how the "umount" all mounted partitions works in this case ..
<nomed> and would it be possible to add a :
<nomed> [ -f /foo/bar_override ]  && . /foo/bar_override
<nomed> at the end of casper ?
<omeg> dsas: sound hotkeys won't work when the laptop is booting up. It's too busy to respond to the request.
<dsas> they work once the login process has started.
<omeg> Didn't work for me. I also experience that the sound keys simply don't work when the computer is too busy in other operating systems.
<dsas> Or at least when I hit enter for my password I hold my volume down button till the on screen display appears showing silence.
<dsas> omeg: I was only proposing it as a work around anyway, so it doesn't really matter :)
<omeg> I guess maybe I could try again. I still think it's an okay request for the wishlist, though. I wish my laptop had one of those old-fashioned wheels with which to turn down the volume rather than those fancy buttons.
<omeg> Oh well, I'm going to try and sell it anyway.
<sladen> omeg: what type of laptop?
<dsas> omeg: I wasn't saying there was anything wrong with the request, I just gave that as an idea to use until it gets changed (if it does)
<omeg> A Dell Inspiron 9100.
<omeg> Three words: thick, loud, heavy.
<omeg> On the other hand, it has a 3.0 GHz pentium 4, 256 MB video RAM, and a 1920x1200 WUXGA screen. Especially the latter is probably a good selling point.
<sladen> omeg: I'm hoping for edgy to move volume control/etc down into a small non-GUI daemon
<sladen> omeg: ...if other people go along with it
<omeg> sladen: non-GUI daemon?
<sladen> omeg: a program that runs as part of the core of the system as just speaks to /dev/input and ALSA.  And which is not dependant upon having the full GUI available
<sladen> omeg: so it would be available bfore X and regardless of KDE/GNOME/Xubuntu
<omeg> Ah, I see.
<omeg> Yeah, that would be really cool.
<zul> heylo
<zyga> hello
<bluefoxicy> pitti... no not here.  Hrm..
<koke_> where are the translations for the live installer?
<mdke> koke_: debian-installer
<mdke> koke_: you've only got about another day though
<koke_> I like pressure ;P
<mdke> there are some strings in "ubiquity" too, i think
<koke_> there are a lot of bold strings which its last letter is not bold
<koke_> it's weird
<koke_> launchpad is still my old friend https://launchpad.net/products/?text=debian-installer
<mdke> you need distros/ubuntu/dapper/+source/debian-installer
<mdke> i'd think
<koke_> the real debian-installer appears in position 28th
<koke_> :)
<koke_> where are the installer translation in the live cd??
<mdke> koke_: you just asked that, and got an answer, no?
<koke_> mdke: now, I mean in the CD
<koke_> in launchpad they appear correctly\
<koke_> I want to check if it's not a translation problem
<mdke> ah
<mdke> no idea
<koke_> desperate solution then... find / -iname *.mo
<koke_>  /rofs/ wtf?
<poimen> somoen knows a internet site that is paying for translations or something? I need to make $300  a month and no job around here??
<lucasvo> poimen: which languages do you speak?
<poimen> spanish and english
<poimen> lucasvd : I speak spanish and english 
<Alinux> I'm testing todays buld with VMware
<Alinux> but it stopes at 61% of configuring... cron is not installed.
<Alinux> I don't know why. :/
<ubuntu> I'm having some problems with the new installer
<ubuntu> it dies with no message :(
<crimsun> ubuntu: are you using a daily image?
<ubuntu> crimsun: nope, beta2
<ubuntu> btw, I'm koke using irssi :)
<ubuntu> I can't change mi nick :/
<crimsun> /nick koke
<ubuntu> I tried but no success
<crimsun> and Colin would appreciate it if you would try the latest daily
<ubuntu> I'll download it for tomorrow
<ubuntu> some LaptopTesting to do :)
<ubuntu> btw /var/log/installer/syslog says ubiquity: /bin/partman exited with code 10
<HiddenWolf> ubuntu, that means your nick is taken and you have to pick another one.
<koke_> cool, thanks :)
<koke_> maybe the nickserv protections
<kaur> using dapper beta and usb flashdisk doesn't automount
<crimsun> kaur: #ubuntu+1, please
<kaur> i was send here from there
<koke_> crimsun: do you know what to upgrade in the live apart  from ubiquity to get the latest installer and deps?
<HiddenWolf> koke_: ubuntu-desktop and/or ubuntu-live
<crimsun> koke_: you could rsync
<koke_> rsync from where?
<koke_> HiddenWolf: maybe that's too much :)
<kaur> from ubuntu +1
<kaur> sry
<kaur> my mistake
* koke_ trying to install with ubiquity 1.0 now
#ubuntu-devel 2006-05-26
<jmanblue> where do i make feature requests?
<bddebian> I assume sl-modem is in multiverse for license reasons?
<dudanogueira> hello all! please, im not finding where to change the "applications" icon at the top left menu. sorry for asking this at this channel, but i looked everywhere!
<bddebian> dudanogueira: The applications icon itself or a specific application?
<dudanogueira> the application icon itself
<bddebian> Oh hmm, that I'm not sure of, sorry
<dudanogueira> the ubuntu icon. its because im making a tomato OSX, a joke with apple... a better deskop
<sladen> bddebian: yes, it's a binary blob
<bddebian> sladen: thx
<ispiked> maybe here is the more appropriate place to ask this question. is mono stuff (libraries needed to run mono apps., etc.) shipping with dapper?
<crimsun> yes, even develop them. $ apt-cache policy mono-devel
<ispiked> crimsun: cool.
<desrt> dapper dapper dapper dapper
<BenM> hey guys, is the usage of gettext in  gnome-panel ubuntu specific
<BenM> for the menu item names
<BenM> .desktop files have X-Ubuntu-Gettext-Domain=gedit, and i'm wondering what this is
<jdub> BenM: .desktop translation
<jdub> BenM: https://wiki.ubuntu.com/LangpacksDesktopfiles
<BenM> interesting
<BenM> so, i noticed that g-p mmaps 1.5 mb of RSS in the gettext files
<BenM> which is a bit nasty
<BenM> if it's reading a string or two from each
<BenM> and i think many of those mappings are only for gp
<BenM> dontzap should be a default :-)
<BenM> anyways, so it's doing things like loading the yelp .mo
<BenM> just to get a single string
<jdub> BenM: yeah, sounds about right, probably not taken into account during the analysis
* BenM nods
<BenM> perf has this tendency to be ignored
<BenM> :-)
<jdub> no, some elements were examined - read the page
<BenM> well, something like this isn't going to cause an additional second
<BenM> so, the perf data there isn't really all that useful
<kagou> hi
<mdke> Riddell: around?
<tseng> thom: thanks for the mongrel tip, fcgid blows
<mdke> Riddell: new snapshot of translations for kubuntu-docs is in the repo, i've added targets to the Makefile for new languages and some which we already had but didn't seem to be in the Makefile.
<bddebian> Hello
<pitti> hi bddebian 
<bddebian> Hi pitti
<delire> i'm interested to know what Ubuntu's policy is on packages that move out of Debian unstable and ultimately into stable for longer than two Ubuntu release cycles. it appears there was a piece of excellent audio software that has since moved on into Debian stable, and having been considered 'stable' for so long, is now no-longer in Ubuntu or Dapper..
<delire> it seems a shame that good but very stable software slips out of Ubuntu over time..
<jsgotangco> its not in universe?
<delire> nope
<mdke> packages move out of debian unstable?
<bddebian> What package?
<jsgotangco> what is this?
<delire> pd-externals. a huge set of plugins used by thousands of people with the modular sound programming environment 'Pure Data'
<sladen> delire: what's the package?
<bddebian> So it's non-free?
<delire> bddebian: no, it's completely free
<bddebian> Usually packages are not dropped unless they are unmaintained
<jsgotangco> yeah
<delire> mdke: yes, they move out over time when development is no longer continued or a package maintainer decides that s/he doesn't need to package them any more.
<crimsun> the reason is stated at bugs.debian.org/331385
<sladen> delire: has it been renamed?
<delire> bddebian: hmm, well pd-externals in CVS is still very active.
<delire> sladen: it doesn't appear to have been renamed, no.
<crimsun> yes, it was removed from sid, so it was removed from dapper as well.
<delire> sladen: i could very well be wrong, hope so.
<delire> crimsun: that's a shame.
* sladen ponders what the course of action is
<delire> crimsun: universities all over the world use these plugins on Redhat systems.
<delire> (via planet CCRMA)
<sladen> delire: (really not a argument :)
<delire> sladen: of course, i'm just saying it's a popular package and used the opportunity to find out what happens in this case. i'd argue for some sort of 'package retention' policy on good software gone stable.
<mdke> delire: you should probably try and convince debian to maintain the package again
<delire> mdke: i guess i should yes, though this does throw up a loophole i think. a stable package shouldn't go 'stale'.
<crimsun> delire: it's not a matter of "stable" vs. "testing" or "unstable" here; it's a matter of maintenance. The latest release seems to be from March 12, 2003. The version that was removed is a snapshot.
<mdke> or maybe you could even maintain the package yourself
<delire> crimsun: i think it's 2004 according to my Debian system, but would need to check. yes, it has been unmaintained for a while.
<crimsun> yes, what mdke suggests is the most viable course of action imo
<delire> hmm. i'd consider this yes. what is the road to becoming a package maintainer for Ubuntu?
<delire> s/road/path
<mdke> s/Ubuntu/debian
<delire> i see..
<crimsun> delire: it would be best to maintain it in Debian so it can be synced into Ubuntu
<tseng> you dont have to jump through hoops to be a debian developer
<tseng> you just need to do good work on the package and find someone to sponsor you
<tseng> check your work and do uploads
<delire> crimsun: right. so no total 'switching' from Debian for Ubuntu developers i see ;)
<delire> tseng: i've been using debian for many years, and having read various letters to lists/blogs et al, it looks like a convoluted initiation. i'll look into it thanks.
<tseng> its a pain to become a developer, not to get a sponsor for a single package
<sladen> delire: the more work we upload directly into Debian and then sync back to ubuntu, the less difference there is between Debian and Ubuntu
<delire> tseng: right, that may be where i have gone wrong in my assumption.
<tseng> http://mentors.debian.net/
<delire> sladen: a good way of putting it.
<sladen> delire: keeping that difference small becomes really important when all those changes have to be maintained by 50 Ubuntu developers instead of 1000+ Debian developers
<delire> tseng: cheers
<ivoks> sladen: i extracted diff for lexmark fix
<delire> sladen: yep.
<ivoks> sladen: but... it's much easier to package whole rc3, than apply that fix :/
<sladen> ivoks: groovy.  how big is the fix
<ivoks> sladen: it's drastic :/
<sladen> ivoks: did you manage to test with just that patch
<sladen> ivoks: oh.
<sladen> ivoks: do you have the patch somewhere?
<ivoks> sladen: no, i can't build package
<ivoks> sladen: this is the thing... new lexmark-print.c breaks building
<ivoks> sladen: over 50% of changes between rc2 and rc3 are .po
<ivoks> sladen: which should be changed, if we replace lexmark-print.c
<ivoks> sladen: we are looking at total rewrite of that file
<ivoks> sladen: it's bug #6627
<Ubugtu> Malone bug 6627 in gutenprint "lexmark z53 blank pages" [Normal,Needs info]  http://launchpad.net/bugs/6627
<delire> thanks all. ciao
<sladen> delire: thank *you*.  For being it up
<sladen> ivoks: /me looks
<sladen> ivoks: if you remove all of those debug printf renames, the patch is 10 lines
<sladen> sorry, ~4 lines added and 10 lines moved
<sladen> ivoks: the hunk at  @@ -2193,6 +2160,7 @@  seems strange
<sladen> ivoks: where did you get patch from?
<infinity> sladen: Where did you lose article?
<infinity> And yeah, that change looks odd. :)
<_lemsx1_> infinity: ping
<infinity> It seems odd to ping someone 20 seconds after they typed something.
<_lemsx1_> lol
<_lemsx1_> i just woke up
<_lemsx1_> :-P
<_lemsx1_> just wanted to ask, it seems that console-screen.sh is the only script that calls unicode_start (or _stop) that gets delayed until after usplash finishes
<_lemsx1_> keymap.sh doesn't have any usplash code
<infinity> Err, yeah.
<infinity> I suspect that's because console-screen is the only one that does the crazy VT-switching madness.
<sladen> ivoks / infinity: http://www.paul.sladen.org/ubuntu/upload/guten-lexmark-z53-backport-1.diff is the patch stripped down;  but there's another floating '}' brace near the end
<_lemsx1_> infinity: gotcha. lol
<infinity> Must have missed a + } elsehwre..
<_lemsx1_> infinity: it's mad indeed
<infinity> Or, the original patch is skee-eeetchy.
<infinity> sladen: Or, given the indenting in the context, that } was misplaced and just plain didn't belong..
<sladen> bah
<ivoks> sladen: sorry, my pppoe died :/
<sladen> ivoks: I've replied to the bug report with what you missed
<ivoks> ok
<ivoks> sladen: that's diff between rc2 and rc3 for lexmark-print.c
<sladen> ivoks: can you put the -rc3 version up somewhere and I'll have another comparision.  Will you be around for a while to test the package?
<ivoks> sladen: i can't test them (i have no lexmark), but i can build them, and I allready did
<ivoks> sladen: there have ben lots of changes between rc2 and rc3
<ivoks> sladen: imho, best thing would be uupdate, but i also thing that's worst thing we can do
<sladen> ivoks: yes most of them are changes in the name of the debug function.  When those are stripped out the patch is below 20 lines, most of which is a big location (see the one that is attached to the bug report)
<sladen> s/location/relocation/
<ivoks> sladen: but, that's not the problem...
<ivoks> sladen: with your patch, compile fails
<ivoks> sladen: with my patch .mo generator seg faults
<ivoks> sladen: i'll give you whole diff, so you can see how not-trivial this is :(
<sladen> ivoks: Yes.  note that I've hilighted two hunks (again in the bug report) in that patch that look suscipicious;  which is why I'm after the two original files, so I can re-diff then and check that I get the same results if I start afresh rather than massaging the current diff that was put up
<sladen> ivoks: it's obviously going to fail (just as the patch it was based on, fails), because there's a duplicated line in one hunk and a hanging brace in the other
<fabbione> so what do i need to disable to avoid cdrom's to be automounted on insert?
<fabbione> (server install or almost)
<ivoks> fabbione: kill ivman/gnome-volume-manager...
<fabbione> i don't have gnome installer
<fabbione> installed
<fabbione> see... server install or almost
<sladen> fabbione: a server install isn't going to have g-v-m running is it?
<fabbione> no it doesn't
<ivoks> hm
<ivoks> then what could automount it?
<ivoks> autofs?
<sladen> fabbione: which is what takes in the incoming hal/udev message and hangs it off to pitti's pmount (IIRC)
<fabbione> ps ax  |grep gnome | grep -v grep | wc -l
<fabbione> 0
<fabbione> there is no autofs
<fabbione> it's not kde
<fabbione> it's basically X + openbox + mythtv
<sladen> fabbione: what's an  lshal -m  give you?
<fabbione> all mythtv options to monitor cd/dvd are off
<fabbione> an error?
<fabbione> sladen: sorry--
<fabbione> there is no lshal
<ivoks> huh?
<fabbione> ivoks: i did a server install... please read what i wrote, ok?
<ivoks> then nothing automounts it :)
<fabbione> well something does
<ivoks> fabbione: i'm aware of that, "huh" was for "no autofs, no utopia and it still automounts" 
* fabbione tests something windowish
<sladen> fabbione: so you have no HAL on that box at all?
<fabbione> ok i figured
<fabbione> thanks guys
<fabbione> mythtv doesn't stop cd/dvd polling on the fly
<fabbione> it needs a restart
<sladen> ivoks: do you have copy of that -rc3 file somewhere handy?  cvs.sf.net appears to be down
<ivoks> yes... sec
<ivoks> sladen: www.grad.hr/~ivoks/ubuntu/gutenprint-5.0.0-rc3.tar.bz2
<ivoks> sladen: that's a release, not svn
<ivoks> or cvs
<ivoks> i got it!
<ivoks> it works...
<sladen> ivoks: what works?  I thought you said you didn't have the hardware to test it?
<ivoks> i don't have hardware, but package builds now...
<ivoks> there was duplicate lines in my patch
<ivoks>    lexmark_imageable_area,
<ivoks> +  lexmark_imageable_area,
<ivoks> that was wrong...
<sladen> ivoks: good, that gets rid of the first hunk I flagged up.  what about the extra '}' brace?
<ivoks> i removed it
<ivoks> sladen: http://www.grad.hr/~ivoks/ubuntu/lexmark
<ivoks> sladen: there's source and packages
<sladen> ivoks: do you have a debdiff?
<ivoks> sec
<ivoks> sladen: http://www.grad.hr/~ivoks/ubuntu/lexmark/guten.debdiff
<sladen> ivoks: okay.  Can you remove all the debug_* changes
<infinity> ivoks: Strip the first hunk from that diff.  Updating CVS IDs in patches is non-sane.
<ivoks> infinity: ok
<sladen> ivoks: which don't actually relate to the fix at all
<infinity> (And what sladen said too)
<ivoks> all right
<infinity> mdz: Barring something Very Bad happening, our final glibc version for dapper is building right now.
<infinity> mdz: I'll spend tomorrow making sure OOo and friends are all up-to-date, one way or another.
* infinity heads to bed now.
<ivoks> infinity: 'night
<sladen> ivoks: ah that extra brace matches "if (1) { /* wisi */" 
<sladen> b
<fabbione> infinity: did you check if it's getting the right z relno yes on sparc???
<infinity> fabbione: Yes, I'm as parnoid as you.  :)  I checked, and it's fine.
<fabbione> infinity: thanks dude :) good night
<sladen> ivoks: you should probably end up with:  http://www.paul.sladen.org/ubuntu/upload/guten-lexmark-z53-backport-2.diff
<ivoks> sladen: I am
<ivoks> it's kind of hard to work over ssh on GPRS line :)
<sladen> ivoks: ouch.  not working locally?
<ivoks> nope...
<ivoks> imagine downloading gutenprint over gprs :)
<infinity> That would be like.. Lke.. Living in Australia.
<ivoks> i have ADSL, but it died couple of hours ago :)
<infinity> When my DSL dies, I consider that God's way of telling me to go out and get some fresh air...
<bluefoxicy> infinity:  and you mention this in #ubuntu-devil why?
<infinity> It's a good tip for anyone who spends as much time in front of a computer as I do (if there is anyone else that insane)
<bluefoxicy> infinity:  I have no rl friends, I have a job offer but I'm awesome :)
<bluefoxicy> I was sitting at my computer and someone called me
<neuralis> infinity: there's more of us than you know ;)
<desrt> http://www.tuxmachines.org/node/7000
<bluefoxicy> like "Hello I'm ##@#*(* with @*%^( and we would like to schedule you for an interview..."
<desrt> awesome!!
<bluefoxicy> infinity:  that kind of sitting in front of computer?
<ivoks> sladen: ok, that went without problems
<ivoks> sladen: now we have to get lexmark guys to test those packages
<bluefoxicy> Does anyone have any clue on why some people are having trouble with GLX still?
<desrt> flight8 release is on digg too
<desrt> neat!
<bluefoxicy> in #ubuntu+1 someone reported his radeon out of the box didn't do 3D; my via has a driver but it doesn't do 3D either.. we get like, unable to get an RGB double-buffered visual... there's 5 bugs for this on malone.
<bluefoxicy> Any ideas, at all?
<infinity> bluefoxicy: Xgl, or GLX?  (Two very different things)
<ivoks> :)
<bluefoxicy> infinity: 
<bluefoxicy> bluefox@icebox:~$ glxgears
<bluefoxicy> __driCreateNewScreen_20050727 - succeeded
<bluefoxicy> Error: couldn't get an RGB, Double-buffered visual
<bluefoxicy> bluefox@icebox:~$
<infinity> Oh, cute.
<infinity> WFM for with both free and non-free drivers on a radeon.
<bluefoxicy> Xorg.0.log I can paste on rafb.net if you like.. actually it might be in the bug I filed (I split a separate one for via)
<bluefoxicy> yes for a loto f people it works... :/
<infinity> Either way, unless someone comes up with very obvious bugfixes, you may be SOL at this point in the game.
<infinity> Release is WAY too close to go fiddling.
<bluefoxicy> which means it's hard to fix.
<infinity> And 3D, while cool, is pretty low on the list of "things that must work before release"
<bluefoxicy> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-via/+bug/41349 https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-via/+bug/29493
<Ubugtu> Malone bug 29493 in xserver-xorg-driver-ati "Failed to find a GLX visual on ATI x700 card using ati driver" [Major,Fix released]  
<bluefoxicy> mm.  Fix released for ATi, I wonder what it was.
<bluefoxicy> infinity:  I didn't attach my xorg.0.log completely to that bug, or my xorg.conf.  I'll do so, maybe someone can fix it post-release on dapper.  Thing is only like 1 dev has a via chipset video driver :(
<infinity> bluefoxicy: post-dapper, it'll probably be fixed upstream and working in edgy, I'd guess.
<infinity> bluefoxicy: pre-release (and shipping in dapper), you're likely stuck with it how it is.  We won't hold up the release for something like this. :/
<bluefoxicy> infinity:  don't worry about holding up the release.
<bluefoxicy> It's already back by a couple of months, I would have preferred it released on-schedule as it is.
* bluefoxicy idly starts counting weeks as months
<bluefoxicy> infinity:  in the mean time I'll ping #xorg on the issue and see if they have any leads.
<ivoks> bye all
<sladen> bluefoxicy: things like that can fail, simply if there is no enough video RAM available to create the buffer
<sladen> ivoks: okay, thanks for your work
<bluefoxicy> I'm more interested in edgy development, because I'm hoping for gcc 4.1 + -Wstack-protector + FORTIFY_SOURCE, maybe some increased randomization in the kernel.  Too bad there's no SELinux developer or we could get away with some other niceness (like denying executable stacks...)
<ivoks> sladen: well, i'm in ubuntu-printing team... this is something i should be doing :)
<bluefoxicy> sladen:  does anything in Xorg.0.log tell me how much vram it found?
<jono> can anyone point me to an ubuntu CSS stylesheet?
<sladen> jono: http://www.ubuntu.com/htdocs/ubuntuweb/css/common.css  (hint.  View source)
<sladen> jono: there's actually a block of 4 stylesheets, with overrides for screen/print/projector, so you may want to include the full 4-line block
<mdke> there are loads more now
<mdke> just point your browser at ubuntu.com and view the source
<mdke> then follow the imports :)
<bluefoxicy> Not that simple.  I tried setting my video memory to 65536 (I have 64M of video memory) and it didn't worksforme.  :(
<bluefoxicy> I've decided I'm not going to specify how much video ram I have
<bluefoxicy> because the X server freezes.  Again.
<infinity> That's generally a good sign that you're specifying an inaccurate figure. :)
<infinity> (But I'm pretty sure the unichrome driver does a bang-up job of autodetecting video RAM anyway, so overriding that is probably pointless)
<bluefoxicy> infinity:  my bios reports 960M RAM + 64M VRAM
<bluefoxicy> I'd asummed 64M == 65536K
<bluefoxicy> sladen said I might fail getting a double buffered visual because I don't have enough video ram for it.  :/
<infinity> bluefoxicy: You can easily see in your Xorg log if the VRAM is being detected correctly.
<bluefoxicy> um, where?
<infinity> bluefoxicy: Specifying a number, though, means that the Xserver may be randomly mapping into main memory ranges (and it's not hard to see why that could hang the system)
<bluefoxicy> http://librarian.launchpad.net/2770384/Xorg.0.log  <-- All I see are "Found XXXXXXXXX ranges excluded YYYYYYYYY overlap at ZZZZZZ ranges NNNNNNNN"
<infinity> bluefoxicy: Most drivers will print a "Detected Memory" or "Video RAM" line or some such in the log.
<bluefoxicy> easily understanding that is called "being a hardware engineer"  :P
<bluefoxicy> ah
<infinity> Er, this log is from when you specified it manually, isn't it?
<bluefoxicy> no
<bluefoxicy> it's from http://librarian.launchpad.net/2770371/xorg.conf
<infinity> Oh, then the line is here: "(--) VIA(0): videoram =  65536k"
<bluefoxicy> oh, videoram  o.o
* infinity just thought that looked suspicious, since it was the number you quoted above.
* bluefoxicy had a hard time locating that :>
<bluefoxicy> well then.. that narrows the problem down to nothing I know of
<bluefoxicy> obviously I have enough video ram for a double buffered visual?
<infinity> I don't know the math involved in that one, so I can't say for sure.
<sladen> bluefoxicy: do you have any other programs open?
<sladen> bluefoxicy: eg. firefox will lots of images?
<bluefoxicy> sladen:  firefox displaying xorg.0.log
<sladen> bluefoxicy: or any other 3D applications
<infinity> (Though, I have the same amoung of video RAM here, so...)
<bluefoxicy> no other 3D apps
<bluefoxicy> I'm logged into gnome with xchat and FF running
<sladen> bluefoxicy: what does LIBGL_DEBUG=verbose glxgears  give you?
<bluefoxicy> ahhh yay, debugging stuffs :)
<bluefoxicy> sladen:  nothing new  :(
<bluefoxicy> http://rafb.net/paste/results/TWEWuY51.html  <-- that's not ALL visuals possible is it?
<bluefoxicy> someone pointed that out on one bug but another person says they always get that and glxgears works anyway
<sladen> bluefoxicy:  glxinfo | grep '^   visual' -A99    will give you the available modes
<bluefoxicy>    visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
<bluefoxicy> http://rafb.net/paste/results/CeNfwq99.html
<bluefoxicy> Bugs
<bluefoxicy> The driver is not fully 64 bit clean. In particular, 3D acceleration, XvMC and VBEModes do not work properly in 64-bit mode.
<bluefoxicy> from the man page for my driver.
<bluefoxicy> SHIT.
<bluefoxicy> it's a 64-bit bug  >:|
* bluefoxicy ammends the bug report.
<Mithrandir> mgalvin: sorry about not telling you, but no, no flight 8.
<bluefoxicy> OK I've added a link to the page stating it's got 3D problems on 64-bit, the bug can be marked confirmed, severity whatever but it's an upstream bug, thing is malone does not let me do that.
<bluefoxicy> there is simply nowhere to edit the severity or status of a bug anymore
<YokoZar> I'm unable to sign codes of conduct - whatever I do it keeps giving me the error "The signed text does not match the Code of Conduct. Make sure that you signed the correct text (white space differences are acceptable)."  This occurs even when I don't insert extra whitespace.
<YokoZar> Is this feature just broken or do I need to be walked through it?
<mdke> YokoZar: if the code of conduct is version 1.0.1 then it is broken. move to #launchpad to ask any more questions about launchpad
<YokoZar> mdke: ahh thanks
<tseng> is it possible to run the utf8migrationtool on a directory that isnt mine
<tseng> not ~
<Mithrandir> tseng: I don't think so.  It's also unmaintained and should probably either receive some attention or be removed.
<Mithrandir> tseng: you just want to convert a directory tree from one encoding to another?
<tseng> right.
<Mithrandir> apt-cache show convmv
<tseng> thanks, Mithrandir 
<mgalvin> Mithrandir: no worries :) i'll just use the content for the RC tour
<lzap> Sunday, uh? :-)
<AlinuxSOS> mdz, hello, 19 may pacakge ttf-bpg-georgian-fonts, version 0.2 has no entri for new BGP_Rioni.ttf font in /etc/defoma/hints/ttf-bpg-georgian-fonts.hints, I've --purged and reainstalled this package. should I file a bug? And I'm working on special ~/.font.config to manage in the best way BPG font family.
<sladen> AlinuxSOS: yes, please file a bug (including the solution you've just given if you've tested and confirmed that that works)
<AlinuxSOS> sladen, some friends that are practise in .deb building can build this font package + personilise .font.config for georgian user . it's ok?
<AlinuxSOS> of course I'll test everything before.
<sladen> AlinuxSOS: ideally it would be good to have that work out of the box.  If you know what changes they are making, could you ask them to integrate them?
<lzap> will Dapper have 2.6.15 kernel or .16 ?
<Chipzz> 2.6.15 I guess
<Burgundavia> lzap, .15
<Chipzz> 2.6.16 isn't even packaged yet I think
<mdke> it will have the kernel it has now
<sladen> go Skype.  They've actually fixed their binary deb to have the right dependances
<Burgundavia> sladen, stunning. I guess I would have lost my bet then
#ubuntu-devel 2006-05-27
<lifeless> morning all
<phanatic> morning lifeless 
<infinity> mdz: FWIW, the "Attempting to resume..." option may be the only one that really makes sense, since once we echo to /sys/power/resume, it's out of our hands.  The kernel takes it from there.
<mdz> infinity: yes, that's what I realized after the fact
<infinity> mdz: Without us duplicating the kernel's internal heuristics to guess if the image is a resume image (ick), we're stuck.
<mdz> infinity: we already do that with file(1), we just don't have that capability in initramfs yet
<mdz> it's an edgy problem now
* infinity nods.
<infinity> Oh, and your previous question ("why is it in local instead of init?") is easily answered with "because your resume partition could require evms/lvm/md/udev to find it"
<infinity> I must have been half asleep the last time you asked.
<infinity> mdz: Hrm.  Can we get an Ubuntu-6.10 milestone in Malone, so we can defer targetted bugs insted of removing the target altogether?
* mdke seconds that
<infinity> mdz: If we don't want to commit on a version, Ubuntu-edgy would be fine by me too. :)
<mdz> infinity: unfortunately not; I asked about this
<mdz> apparently we need to create edgy first
<infinity> mdz: Oh.
<infinity> mdz: Well, it's created in dogfood.  I wonder how wrong it would be to set it up in production, but disable uploads to it... <smirk>
<crimsun> hah, bug #45922
<Ubugtu> Malone bug 45922 in base-files "Wrong (different) dist name after tty logout" [Normal,Rejected]  http://launchpad.net/bugs/45922
<infinity> Actually, I was curious about that.  I thought the name was meant to be "Ubuntu 6.06 LTS" (note the whitespace), not "Ubuntu 6.06LTS"
<infinity> The latter feels altogether unparsable to me.
<infinity> mdz: ^^^
<infinity> Shipit and a variety of other random sources agree with me.
<mdke> yeah, how is that not a bug?
<infinity> mdke: The complaint "OMG, the distro name changed" isn't a bug.
<infinity> But the whitespace might be.
<mdke> right, the lack of a space
<mdz> infinity: you're right, please fix
<infinity> Fixing.
<mdz> why is xchat trying to convince me there are two 'infinity's to tab-complete?
<infinity> One in /msg?
* infinity doesn't use xchat, so is merely guessing.
<mdz> I do inf<tab> and get "infinity infinity"
<infinity> Or maybe I'm multiplying.
<mdke> one infinity is more than enough
<infinity> I'm cool with that.  One of me could go nap.
<mdke> >_<
<mdz> you're in its user list only once. weird.
<infinity> mdz: I suspect we still want DISTRIB_RELEASE to be "6.06LTS", to avoid breaking people's assumptions about what lsb_release will spit out?
<mdz> infinity: check LSB to confirm
<mdz> but I think it shouldn't contain whitespace
* infinity checks.
<infinity> It doesn't actually specify, but my definition of "version number" doesn't involve spaces, so I'll leave it out there.
<Burgundavia> mdz, nice work on the TimeBasedRelease page
<mdz> Burgundavia: just mailed -doc asking for review
<Burgundavia> mdz, mind if I add an intro?
<mdz> Burgundavia: not at all
<Burgundavia> mdz, I posted the link in the dapper forum at ubuntuforums.org
<mdz> Burgundavia: url?
<mdz> I'm wondering whether to expand FeatureSpecifications or write FeatureDevelopment
<mdz> Burgundavia: you're holding a lock on TimeBasedReleases, but it timed out
<mdz> Burgundavia: are you still editing?
<mdz> Burgundavia: if so, please change the FeatureDevelopment link to FeatureSpecifications, and I'll just expand that instead
<mdke> mdz: just steal it from him if it's timed out
<infinity> mdz: Any issues with a 6-line patch to gawk to avoid infinite loops when manipulating UTF8 strings?
<infinity> mdz: http://cerberus.0c3.net/~adconrad/20_eval.c-utf-8-strcat.dpatch
<infinity> mdz: (elmo's applied it in Debian, seems to DTRT)
<mdz> infinity: how long ago in Debian?
<mdz> how did you notice it?  is it triggered in Ubuntu somewhere?
<infinity> mdz: First revision of the patch in March, that revision on April 18.
<mdz> my gut reaction is dapper-updates
<infinity> mdz: We have a bug open about it, cause it can cause an FTBFS (though not in our environment, since none of our buildds run in UTF8 locales)
<infinity> So, it's important, but not really.  Ish. :)
<mdz> infinity: has it been running on the Debian buildds since the 18th? or when?
<infinity> buildds don't typicall have gawk installed at all, unless something build-deps on it.
<infinity> (Which some things do, admittedly)
<infinity> Anyhow, the FTBFS bug was not a buildd-triggered bug, but joeyh doing a by-hand build.
<infinity> Hence the UTF-8 locale and the gawk instead of mawk, I assume.
* infinity is indifferent, just looking for "real bugs with obviously small and correct looking fixes".
<infinity> mdz: If it was sometihng that actually triggered repeatedly on the buildds (and this fixed it), I probably wouldn't even bother asking about fixing it.  It's the grey area (it's a bug, but we don't trip on it directly) that led to me poking you. :)
* infinity is miffed that he ran out of time to deliver on his last two UVF exceptions...
<mdke> mdz: I did some formatting changes on that TBR page, check if you like them, feel free to revert if not
<jsgotangco> feh and i was just looking at it too
<mdke> jsgotangco: the wiki tells you when someone else is editing, so you don't get conflicts
<jsgotangco> i just looked, that's all :P
<Riddell> mdke: thanks, I'll look at that tomorrow
<mdke> Riddell: cool, i tested the package and it seems alright
<mdke> jsgotangco: ah, misunderstood
<mdz> mdke: much better, thanks
<mdz> and good night
<mdke> night
<Burgundavia> mdke, looks good
<rpedro> hi, are there any known bugs with the fglrx binary drivers since the latest dapper updates? Xorg's log says it can't find the fglrx module, so I had to revert back to the ati drivers...
<infinity> rpedro: Have you rebooted?
<infinity> rpedro: (This isn't a support channel, but I can tell you that if you have the latest fglrx installed and all the latest kernel/lrm updates, it should work fine.. I'm using it here right now)
<rpedro> yes, this happened preciselly after rebooting after the updates, right before that I was trying to configure Xgl and rebooted a few times. the fglrx driver was working ok...
<rpedro> infinity: ok then I guess I'll try to find out what's wrong with my pc
<rpedro> infinity: just asked here cause I thought maybe because the kernel got updated the kernel modules might have some problem,
<infinity> rpedro: Perhaps we should take this to /msg
<jdub> did something break with LANGUAGE fallbacks?
<jdub> mine is currently en_AU:en
<jdub> i thought we did en_AU:en_GB:en?
<tseng> thom: if i use lighttpd/fcgi behind the proxy it seems alot more responsive than mongrel, btw
<hendry> Mithrandir: ping
<hendry> aigarius: howdy
<aigarius> hendry, hey!
<hendry> aigarius: still in mexico?
<aigarius> hendry, yep. leaving tomorrow.
<hendry> freeflying|away: heh
<hendry> aigarius: was reading planetdebian. wish there was more lowdown on that dude that was asked to leave. i want more scandal.
<freeflying|away> hendry: hi
<aigarius> hendry, don't. note that the debconf6 blog directs people to read additional emails in debian-private
<aigarius> hendry, you do have access to that, right?
<hendry> aigarius: no, i don't. I am now a DD
<aigarius> hendry, you mean that you are *not* a DD
<zul> hmm?
<hendry> aigarius: no, i don't. I am noT a DD
<hendry> aigarius: sorry :)
<hendry> freeflying|away: my hangul key (MS Natural keyb) doesn't work with Skim. Any ideas?
<freeflying|away> hendry: sorry, no clues 
<aigarius> hendry, I am still considering what I will put in my blog entry for that day. I can put in things that I know myself, but not what has been posted to debian-private. Also some people asked me not to mention the thing at all so not to stir any additional commotion.
<hendry> freeflying|away: I think Mithrandir was working on this, but we're in different timezones
<hendry> aigarius: oh well. i guess they are right, that they don't want the Debian name dragged in the mud.
<freeflying|away> hendry: maybe in night, you can meet him
<mjg59> Can we avoid discussing this here, please?
<Chipzz> hendry: several other people on planet debian commented on the incident
<hendry> is there some reason "libapache2-mod-fastcgi" is not in dapper?
<fabbione> morning
<ajmitch> hi fabbione 
<fabbione> hi aj
<jcole_home> TomB| TomB_: ping
<TomB_> hi?
<pitti> Good morning
<ajmitch> morning pitti 
<pitti> hey ajmitch 
<jcole_home> anyone try this with ubuntu? i just made a debian install mini.iso and installed... pretty cool :) --> http://wiki.debian.org/DebianInstaller/PartmanCrypto
* Starting logfile irclogs/ubuntu-devel.log
(Mithrandir/#ubuntu-devel) hendry: yes?
<hendry> Mithrandir: I have Kubuntu dapper machine here. And the Hangul key doesn't work with skim.
<hendry> Mithrandir: it's a MS Natural Keyb
<Mithrandir> does xev pick it up?
<hendry> Mithrandir: ah, that's it. xev.
<hendry> Mithrandir: keycode is 209
<hendry> Mithrandir: other key is 210
<hendry> Mithrandir: perhaps skim is at fault
<Mithrandir> that's right, iirc.
<Mithrandir> what's the output of setxkbmap -print?
<mantas_> Hello all
<mantas_> I've noticed, that ubuntu gnome language-packs are 10 days old and there are lots of updated translations since then. Maybe someone could run Ubuntu automatic language pack builder today ?
<LaserJock> ack, what is the URL for seeds?
<Burgundavia> LaserJock, people.ubuntu.com/~cjwatson/seeds
<LaserJock> Burgundavia: ah, thanks
<lifeless> infinity: hi. you popped out just before I expanded. If you are interested I can clarify further. If not, thats fine too.
<sivang> morning all
<Burgundavia> salut sivang 
<sivang> salut Burgundavia :)
<pitti> ogra: ping
<dholbach> good morning
<pitti> hey hey dholbach 
<dholbach> hey pitti!
<sivang> hey pitti , dholbach , ogra 
<pitti> hi
<dholbach> hi sivang
<pitti> infinity: oh, this m-t-locale-ru bug isn't halfway as bad as I thought
<pitti> infinity: we already have transitional packages for all previous main packages
<pitti> infinity: and the remaining ones are just for languages which were outdated and uninstallable even in breezy (and maybe earlier)
<infinity> pitti: *nod*... Point still remains that we should add more transitional packages.
<pitti> infinity: we shuold kill the obsolete universe ones
<dholbach> heya infinity!
<mantas_> pitti, hi, could you update ubuntu gnome language-packs today ? Now they are 10 days old and there are lots of updated translations since then and I need to test lots off Lithuanian translations fixes before release candidate
<pitti> mantas_: yes, already in progress
<sivang> yo infinity 
<pitti> infinity: can you please remove mozilla-thunderbird-locale-{el,es,ko,nb,pt-br,ru,sv,tr} from universe?
<infinity> Yup.
<pitti> infinity: I can add them as transitional packages anyway if you want to get them through NEW
<thom> tseng: yeah, i noticed that but put it down to fbsd4 uselessness; take it you're running on linux?
<infinity> pitti: They won't be NEW if they're replacing the old binaries.  That's sort of the point. ;)
<pitti> ah, ok
<infinity> pitti: I'll remove the old sources once the new binaries are in.
<pitti> infinity: alright, I'm on it now
<infinity> pitti: Thanks, dude.
<dholbach> hey mvo!
<mvo> hey dholbach!
<pitti> infinity: uploaded; too late for this cron.daily unfortunately :/
<infinity> pitti: I'm not picky.  My day's winding down, so slower, more mindless tasks, like babysitting stuff through queues, are fine with me.
<infinity> (Another sleepless night, I've been working for the last ~12 hours..)
<infinity> Not intentionally, mind you.
<infinity> pitti: Are there any plans in the future to have informative changelogs for the language packs, instead of "initial release" every time? :)
<infinity> pitti: Sometihng like "1298 new strings, 892 corrected strings" might be nice.
<pitti> infinity: the ones you see on d-changes are the NEW ones, thus *are* initial release :)
<infinity> pitti: If those sort of statistics can be gathered.
<pitti> infinity: they can, it would just take much computation power and a way to access the old packages
<infinity> pitti: They ALL say that, you can't fool me. :)
<pitti> infinity: yes, sure, but the preexisting ones aren't announced on -changes
<fabbione> oh craptastic
<infinity> pitti: Well, I'd assume that eventually, if rosetta is spitting these things out, it can keep statistics and a running changelog... Maybe?
<fabbione> i can't go in vac a week that i get 200 bugs untriaged
<infinity> pitti: That might be kinda slick.
<pitti> infinity: I already have statistics for the whole tarball, but not broken out per-language and per-component (main/kde/gnome)
<infinity> pitti: Anyhow, way offtopic for release crunch, maybe I'll be all pie-in-the-sky about pretty langpack changelogs in Paris.
<pitti> infinity: if that's desirable, I can certainly hack something (but post-release)
<infinity> mvo: Hey, dude.
<infinity> mvo: How often do you refresh the icons and such in app-install-data?
<infinity> mvo: Would be nice to get the prettier Tbird icon in there.
<pitti> Riddell: will you care for the current oversizedness of kubuntu install CDs?
<pitti> Riddell: erm, live CDs, the install ones are fine
<mvo> infinity: I can do another refresh run today, I did the last before the weekend, it requires (a bit of) manual work, at least looking over the changes etc
* mvo starts his archive-crawler
<infinity> mvo: Well, I could just give you the .svg and you could replace that one thing. :)
<mvo> infinity: that would be too easy ;) yeah, lets do it this way
<infinity> mvo: http://cerberus.0c3.net/~adconrad/mozilla-thunderbird.svg
<infinity> mvo: And /usr/share/app-install/desktop/mozilla-thunderbird.desktop needs to be mangled to drop the ".xpm" extension from the filename.
<infinity> mvo: In theory, that should do it.  I welcome your testing, however. :)
* infinity heads out for food.
<dholbach> infinity: good night
<Kinnison> ciau adam
<desrt> pvanhoof; didn't know you often came here
<pvanhoof> autojoin
<desrt> odd.
<desrt> it would be useful to have a service that auto-connected to efnet, gimpnet, freenode for you
<desrt> and looked like a single server to your irc client
<desrt> and "knew" about which server each channel was on
<desrt> (like... even though efnet has #ubuntu, it would know that the real one is here)
<pvanhoof> oh, that might ne useful yes. But if I really needed that already I'd probably set myself a psybnc up on my private servers
<desrt> psy does connection multiplexing?
<pvanhoof> I'm sure I could hack it that way if it doesn't
<desrt> <3 free software
<desrt> wanna hear something awesome?
<pvanhoof> sure
<desrt> inspired somewhat by toshok, i installed starcraft today
<desrt> so i'm gonna go play it now :)
<desrt> g'night.
<pvanhoof> g'night :)
<seb128> pitti, carlos: do you know why gnome-panel template is outdated?
<seb128> pitti, carlos: the new item of the help submenu are not listed :/
<pitti> seb128: the POT you mean? doesn't it get rebuilt on package build?
<seb128> pitti: it does, I would not ask other way but would fix it :p
<pitti> seb128: maybe that menu item is in a new file not mentioned in POTFILES.in?
<seb128> pitti: cf my comment on https://launchpad.net/distros/ubuntu/+bug/31775/+index
<Ubugtu> Malone bug 31775 in Ubuntu Dapper "Ubuntu should have better links to support options" [Normal,Fix released]  
<carlos> seb128: not yet, I need to do some checks first...
<seb128> pitti: the .pot from my local build list them correctly
<seb128> carlos: could you do that now? that's sort of a dapper priority
<Kinnison> pitti: The language packs are still building. Unfortunately one of the two i386 builders has openoffice.org on it
<seb128> pitti: and the build log has a "cd po; intltool-update -p" call with no sign of error for it
<dholbach> heya seb128!
<seb128> dholbach: hi kubuntu-er :p
<dholbach> pffft
<dholbach> I knew I'd hear something like that :)
<fabbione> mdz: 
<fabbione> multipath-tools (0.4.7-1ubuntu7) dapper; urgency=low
<fabbione>   * Fix typo in init script that was executing hsg80_init unconditionally.
<fabbione>   * Suggests: sg3-utils and Conflicts: sg-utils (obsoleted).
<fabbione> ^^ can i upload?
<carlos> seb128: when did you upload latest package?
<pitti> Kinnison: yeah, I just checked :/
<seb128> carlos: latest package or the one with those changes?
<carlos> latest package
<carlos> I assume latest package should have those changes too, right?
<seb128> carlos: probably 4-5 days ago, lemme check
<seb128> right
<seb128> 2006-05-18 11:06:51
<seb128> carlos: read?
<seb128> carlos: but comment on bug #31775 states that:
<Ubugtu> Malone bug 31775 in Ubuntu Dapper "Ubuntu should have better links to support options" [Normal,Fix released]  http://launchpad.net/bugs/31775
<seb128> "FWIW: it appeared in Rosetta quickly, but since then seems to have
<seb128> disappeared, from what people seem to have reported."
<carlos> seb128: the .pot we have atm imported says: POT-Creation-Date: 2006-03-14 12:44+0100
<seb128> not good
<seb128> could you look why previous build didn't get its template imported? 
<seb128> the build system didn't change
<seb128> and the build log has the call to "cd po; intltool-update -p"
<carlos> seb128: "Commercial Support" is one of the additions, right?
<seb128> carlos: correct
<carlos> seb128: I don't get such strings in my about menu...
<seb128> carlos: did you restart your panel recently?
<carlos> this morning
<seb128> carlos: dpkg -l gnome-panel
<carlos> where should I see it?
<carlos> 2.14.1-0ubuntu13
<seb128> carlos: system, help submenu
<mdz> fabbione: ok
<carlos> oh, ok
<carlos> I see them ;-)
<fabbione> mdz: thanks
<seb128> carlos: ah, better that way
<seb128> :p
<Keybuk> one interesting thing about Dapper, I've noticed
<Keybuk> this is the first release that I haven't had to reinstall during the development cycle
<jsgotangco> i only reinstalled like twice
<jsgotangco> (except laptop testing)
<mdz> mvo: is the auto-dist-upgrade test still running
<mvo_> mdz: yes, I got some md5sum problems the weekend, looking at this now
<mvo_> mdz:  is this ok to upload: update-manager (0.42.2ubuntu19) dapper; urgency=low
<mvo_>  .
<mvo_>    * help/C/figures:
<mvo_>      - applied "pngcrush" on the figures in the manual,
<mvo_>        this saves 4 MB uncompressed (ubuntu: #45901)
<mdz> mvo_: yes
<mvo_> mdz: thanks
<seb128> carlos: any luck on the panel?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Release preparation in progress, please behave
<carlos> uploading latest version atm
<mdz> seb128: can you do the panel updates so that when we get the book, we don't need to change the panel?
<seb128> carlos: how "uploading"? why didn't it do an import from the build?
<carlos> seb128: I really don't understand how was that possible...
<mvo_> mdz: I would also like to do another notification daemon upload today, there is currently a pretty ugly visual glitch for small notifications on the bottom panel (#45632)
<seb128> mdz: yeah, I'll do that as soon as carlos has sorted why my change from previous week are not listed by rosetta
<mdz> seb128: ok
<mdz> mvo_: that effect looks almost intentional :-)
<mdz> mvo_: where's the patch?
<seb128> carlos: maybe pitti would know?
<carlos> seb128: no, I don't think so
<carlos> seb128: people.ubuntu.com says that the .pot file is correct
<mvo_> mdz: not done yet :(
<seb128> mvo_: from what package does "Enter your password to perform administratives tasks"  come?
<mvo_> seb128: most likely gksu, why?
<seb128> carlos: I asked for the panel template to launchpad yesterday to rosetta and got an error mail too
<carlos> seb128: when did you add those new strings? 
<carlos> seb128: the .pot export is not working atm
<Kagou> hi
<seb128> mvo_: because gksu, libgksu* are translated to french and that string is still englsuh
<seb128> english
<carlos> seb128: it's unrelated to this problem
<seb128> carlos: 2006-05-16 17:06:38
<seb128> I think
<mvo_> seb128: hrm, that sucks!
<imbrandon> kdesu maybe ?
<seb128> that's the date from the "publish history" page
<mvo_> seb128: does it come when you type gksu id?
<seb128> mvo_: yeah really, do you run a german desktop? is it translated for you?
<mdz> mvo_: do you know what the problem is?
<seb128> mvo_: "id"?
<mdz> mvo_: if it's not trivial to fix, it can wait until after the release
<mdz> seems like quite a minor bug
<mvo_> mdz: yes, I think I have a pretty good idea what the problem is. it is a minor bug, but it looks *so* ugly
<mvo_> seb128: well, anything
<Kamion> infinity: changing DISTRIB_RELEASE at this point is bad - various build systems rely on that being 6.06
<seb128> mvo_: "gksu ls" is translated correctly
<Kamion> mdz: ^--
<seb128> mvo_: "gksu --desktop synaptic.desktop  synaptic" is not
<seb128> neither the title
<seb128> nor the description
<Kamion> (changing non-machine-parseable strings is fine)
<seb128> and that's really visible since that's the dialog you get when using update-notifier
<mdz> Kamion: gar, really?
<mdz> Kamion: if so, go ahead and revert that bit
<mdz> but issue, issue.net, _DESCRIPTION, etc. should definitely say LTS
<mvo_> seb128: ok, please nag me about it in a bit again, I'll fix it. I just want to get this notification-daemon thing done first
<seb128> mvo_: ok
<Keybuk> pitti: there's a bunch of language packs that are hankering to be demoted to universe
<mdz> mvo_: could you do the pngcrush thing for hwdb-client as well?
<mvo_> mdz: sure
<pitti> Keybuk: uh? I thought they are all caught by germinate's wild card magic
<pitti> Keybuk: or do you mean thunderbird-locale-XX?
<Keybuk> it could be just that germinate hasn't updated, if they're brand new
<Keybuk> language-pack-gnome-fy, language-pack-gnome-fy-base
<Keybuk> language-pack-kde-am, language-pack-kde-am-base
<Keybuk> language-pack-kde-oc, language-pack-kde-oc-base
<Keybuk> -- 
<pitti> Keybuk: right, these are the new ones
<Keybuk> right-o, they'll probably vanish in ten minutes then :)
<jsgotangco> mvo_: nice upload, that's a big difference thanks
<Kamion> mdz: pretty sure, I remember we had to fix some stuff when we changed from 6.04 to 6.06
<mvo_> jsgotangco: cheers
* Keybuk can't get over how much faster "bzr push" is now
<Kamion> mdz: I think I've reached an understanding of the ubiquity resize problems that have been reported, and I think we need to fix those - quick fix should be to remove /var/lib/partman before every partman run, and to take a bit more care to make sure partman_commit uses the manual partitioning path; about to set up a test environment for that
<Kamion> I still have 146 new mails in /var/mail/cjwatson though so it'll be a *little* while before I'm up to date ...
<mdz> Kamion: I just got this feeling like someone walked over my grave
<carlos> seb128: ok, got the problem
<seb128> carlos: ah nice, what is causing it?
<carlos> pitti: it's in your script part of the exports, but I guess I could add a workaround for it
<Kamion> mdz: this week is not going well for me so far :-/
<pitti> carlos: the gnome-panel problem?
<carlos> pitti: yes
<carlos> seb128, pitti: I don't know why, but the i386 build didn't get those strings
<carlos> even more, the .pot file seems like was not updated
<carlos> pitti: https://chinstrap.ubuntu.com/~dsilvers/paste/fileBF9Uhc.html
<carlos> that's the start of the diff between the i386 and amd64 .pot files
<Kamion> mdz: also the gnome-power-manager reconfiguration thing that mjg59 reported
<carlos> same build, different .pot files
<pitti> strange
<ogra> pitti, pong
<carlos> I'm not filtering .pot files that have the POT-Creation-Date older than the one I have already imported
<ogra> mvo_, oh, you fixed pngcrush ?
<carlos> but I could do it
<carlos> the problem it could cause is that a package that generates the .pot file without gettext, would forget to update that field
<carlos> and we could miss some new strings
<pitti> ogra: edubuntu ppc/live still has 43 MB free; shall I update the seeds to fill that with 38 MB langpacks, or do you need it for other purposes?
<carlos> but it would prevent this kind of bugs
<ogra> pitti, feel free :)
<ogra> mdz, did you want the hwdb button re-addres to the device manager ? its only 5 lines of code and ~10 lines of glade stuff, we dropped it when i had to add a .desktop file for KDE compatibbility
<mdz> Kamion: g-p-m reconfiguration thing?
<ogra> *re-added
<mdz> ogra: please; that is a regression
<ogra> ok
<mdz> ogra: but get the patch reviewed before uploading
<ogra> i thought we agreed fro breezy that it wasnt needed if a .desktop file exists
<mdz> ogra: I hope the translations are still in the .po file?
<mdz> ogra: there is no .desktop file (or it is suppressed)
<ogra> i dont think so, it was never tharnslated and dropped for breezy already
<ogra> its supressed
<ogra> you can see it in alacarte after installein
<ogra> *installing
<Kamion> mdz: bug 45654
<Ubugtu> Malone bug 45654 in ubiquity "Gnome-power-manager postinst not run" [Normal,Unconfirmed]  http://launchpad.net/bugs/45654
<seb128> would people consider "copying all the yelp .po from launchpad to the source package" as an ugly workaround?
<mdz> Kamion: urgh
<mdz> seb128: no
<seb128> that's to fix #45875
<seb128> bug #45875
<Ubugtu> Malone bug 45875 in yelp "Untranslated strings from 06_toc-with-desc.patch" [Normal,Confirmed]  http://launchpad.net/bugs/45875
<seb128> ok, I'll do that then
<mdz> seb128: that's entirely reasonable
<seb128> so we get a toc translated
<seb128> mdz: thank you
<mdz> Kamion: I think #45654 should be fixed in casper
<seb128> the toc is a .xml so the translations need to be present for the build
<Kamion> mdz: I don't object either way
<Kamion> Mithrandir: ^-- ?
<mdz> Kamion: suspend to RAM is a valid use case on the live CD (e.g., for testing)
<mdz> it should be enabled by default if known to work on that hardware, as for the installed system
<Mithrandir> : tfheen@golem ..casper-1.54/casper-bottom > grep reconfigure 32disable_hibernation casper-reconfigure /root gnome-power-manager
<Mithrandir> bah
<Mithrandir> : tfheen@golem ..casper-1.54/casper-bottom > grep reconfigure 32disable_hibernation
<Mithrandir>     casper-reconfigure /root gnome-power-manager
<mdz> Kamion: do you have a bug# for the partitioning issue?
<Mithrandir> though, casper doesn't copy it in.  It probably should.
<Mithrandir> hmm
<mdz> Mithrandir: so it just needs to be copied as a ubiquity hook?
<Mithrandir> or rather, gnome-power-manager should add that hook, IMO
<mvo_> mdz: hwdb with pngcrush ready, saves ~1,9mb uncompressed. can I just upload?
<Kinnison> Mithrandir: would that involve having a file in the g-p-m package?
<mdz> mvo_: yes
<Mithrandir> Kinnison: yes.
<Mithrandir> mdz: yeah, we just need to decide who gets the honour of doing so.  IIRC, this is all gconf stuff.
<ogra> mvo_, how did you get pngcrush working ? it segfaults on all arches for me
<mdz> Mithrandir: what are we doing for existing packages?  I thought casper supplied all the hooks still
<mvo_> ogra: there is a uvf request approved for a sync, i rebuild it locally
<Mithrandir> mdz: hmm, casper does actually the reconfigure for g-panel-data, so I guess it could do it for g-p-m too.
<ogra> mvo_, ah, thanks a lot
<mvo_> ogra: hwdb is uploaded, no worries :)
<ogra> :)
* ogra hugs mvo_ 
<Mithrandir> iwj: is there any way of setting firefox prefs from the command line?
<Kamion> mdz: bug 45597 and others
<Ubugtu> Malone bug 45597 in ubiquity "Resizing partition results in data loss" [Normal,Unconfirmed]  http://launchpad.net/bugs/45597
<Kamion> also bug 45652
<Ubugtu> Malone bug 45652 in ubiquity "Partitioner *really* confused" [Normal,Unconfirmed]  http://launchpad.net/bugs/45652
<Kamion> haven't analysed all the logs yet
<carlos> pitti: Should I file a bug about the broken .pot file generated with gnome-panel? if the answer is 'yes', where? gnome-panel?, pkgstriptranslations ?
<mdz> Kamion: added to DapperReleaseRadar
<pitti> carlos: I'll take a look at it right now, then I'll see what needs to be done
<carlos> pitti: ok, thanks
<mdz> workrave just told me I should stop for the day
<dholbach> mdz: for the complete day?
<Kinnison> mdz: oops
<ogra> ouch
<carlos> do you think I should filterout any .pot file that has the POT-Creation-Date field older than the one we have in Rosetta?
<mdz> this version doesn't deal with hibernation very elegantly ;-)
<pitti> carlos: it would be nice to detect these cases
<mdz> I remember approving a freeze exception to get that fix in (dholbach I think?)
<pitti> carlos: if you filter them out, the amd64 one would get used?
<dholbach> mdz: yes - the changelog said it had "fixes for hibernation, etc"
<carlos> pitti: yes
<Mithrandir> huh, I apparently don't need to be root to run growisofs?
<mdz> dholbach: which version was that?
<pitti> carlos: that certainly sounds useful then, if the filtering out also generates a warning message somewhere, so that we can fix the actual bug
<carlos> pitti : the only problem is with packages that are not updating that field
<mdz> dholbach: this is 1.8.3-1ubuntu1
<carlos> pitti: hmm, but I guess I could workaround it if I allow .pot uploads with the same date
<Mithrandir> mdz: any other casper bugs you'd want me to look at too, or should I just upload that?
<carlos> pitti: ok, I will try to do it that way
<dholbach> 1.8.3 has "fixed a bug that could cause to stop running when 'suspend timer while inactive' was disabled." and 1.8.2 has "better hibernate/standby suport on Unix." (we had 1.8.1 before)
<dholbach> mdz: ^
<Kamion> pitti: please undo that 6.06LTS DISTRIB_RELEASE hack you did in postgresql-common, if it failed to allow 6.06 as well
<Kamion> pitti: I've reverted base-files
<pitti> Kamion: oh, ok; I could just allow for both to be sure
<pitti> Kamion: there is still a sane fallback for unknown ones, but that would generate a warning on installation
<carlos> pitti: btw, I'm trying to get updated language packs, there is a broken python package installed that breaks the generation, I think you should use that tarball as the final language pack
<pitti> carlos: 'that' -> the one you are going to build right now?
<carlos> pitti: yes
<pitti> carlos: if mdz is fine with uploading a new set, fine for me
<pitti> carlos: I'll test them this evening when they are built
<mdz> Mithrandir: anything targeted at 6.06?
<carlos> pitti: but not right now but later today as usual (the mirror is still being updated)
<carlos> pitti: ok
<mdz> pitti: are there translations for the missing strings which we are missing?
<pitti> mdz: IIRC carlos said that the current tarball lacks some KDE files, and hopefully they're also fix this gnome-panel issue; carlos, right?
<Keybuk> mdz: http://people.ubuntu.com/~scott/reports/confirmed_notforwarded.html
<carlos> pitti: hmm, not really, gnome-panel has been fixed after the mirror started, so it will not be there, but I could provide you with the updated gnome-panel's .po files in another tarball
<pitti> carlos: so what else is broken in the current dapper packs? (May 18 tarball)
<carlos> mdz, pitti: Also there are some new translation domains that I fixed last week that we would get also with this export
<carlos> pitti: the whole list of missing translation domains that I fixed last friday
<pitti> ok, that sounds worthwhile
<carlos> the one I had at wiki.ubuntu.com/MissingPotFiles
<carlos> pitti: you have still some translation domains that should be fixed/reviewed
<pitti> carlos: I was just going to say that I'll remove them from my tarballs
<carlos> pitti: they are noted on that page
<pitti> :)
<carlos> well, tuxpaint-stamps needs a .pot regeneration on build time
<carlos> and I guess we could remove gettext, man and test
<carlos> but would be good if you could provide me with its sourcepackage
<pitti> right
<carlos> to be 100% sure
<Mirv> seb128: apparently you did notice https://lists.ubuntu.com/archives/ubuntu-translators/2006-May/000606.html ? or then the strings have reappeared by their own. thanks, anyway.
<seb128> Mirv: I've pointed it to carlos who just fixed it (cf discussion on that chan some time ago), np ;)
<Kamion> pitti: *nod*
<carlos> seb128: I just answered that email
<carlos> Mirv: ^^^
<marcin_> hi guys
<marcin_> could someone tell me what is the procedure when I translate some strings in rosetta?
<seb128> carlos: ok, thank you
<marcin_> when these changes are going to appear in packages?
<seb128> before dapper
<carlos> seb128: btw, the notification messages from gnome-xchat are using a width too small
<pitti> Kamion: fix uploaded, thanks for the notification
<seb128> carlos: that's a bug for mvo_ ;)
<carlos> ok, so you are aware of the problem
<marcin_> seb128: so someone should review and commit them soon?
<janimo> Riddell: hi, ddo the kde screensavers show up in kde system menus?They do in xfce  bug 39466
<Ubugtu> Malone bug 39466 in xfdesktop4 "KDE Screensavers Show Up In XFCE Menu" [Normal,Confirmed]  http://launchpad.net/bugs/39466
<seb128> marcin_: not sure of what you call "commit", somebody should translate them on rosetta for your locale so they are available with next language-packs update
<carlos> marcin_: I think we are going to generate packages today with all translations done until yesterday
<seb128> carlos: until yesterday is without those panel ones then
<carlos> if there is something untranslated, you should translate it in Rosetta and we will release new packages in a month with those updates
<marcin_> seb128: I contributed some translations this is why I ask when they will be visible
<carlos> seb128: well, the panel changes will be added by hand ;-)
<carlos> seb128: but I'm not sure if the upload is approved already
<seb128> I need to give mvo some good kicking too ;)
<marcin_> another thing is that there is a lot of strings that should be updated automatically
<seb128> german guys should run a german desktop and notice when their change breaks translations like that :p
<marcin_> for example 'strings' like  %s %f etc....
<mdz> Mithrandir: did you do that DVD test we discussed at last week's meeting?
<mvo_> mdz: I did one, the live session was run on my system (it wasn't with the old version)
<carlos> marcin_: if there are strings that are just '%s %f"
<Mithrandir> mdz: I was planning on doing it today since I had the pleasure of dealing with tax return forms the whole of friday.
<carlos> marcin_: either the maintainer should not tag them to be translated
<Kamion> mvo_: did the option to use the traditional installer work too?
<marcin_> can you something with rosetta to make them translated automatically?
<marcin_> s/you/you do
<carlos> or you, as a translator would be interested on changing its order
<mdz> mvo_: if you still have it, and can test the d-i mode, that would be handy
<marcin_> carlos: ok
<mvo_> Kamion, mdz: I have it and can do it in a bit, unfortunately my only system with dvd is the one I work with mostly
<carlos> marcin_: and thus, we cannot translate them automatically
<fabbione> mdz: i can test ppc dvd here in a short time
<carlos> well, we can, but we shouldn't ;-)
<mdz> Kamion: just hit an odd case in ubiquity partman during an install here
<pitti> seb128: according to the build logs, neither the amd64 nor the i386 gnome-panel build updated the POT file, hmm
<seb128> pitti: I don't read the build log the same way then
<seb128> pitti: the i386 log has a "cd po; intltool-update -p" call and no error next to it
<pitti> seb128: oh, wait, it doesn't use --verbose
<pitti> right, sorry
<seb128> np
<pitti> seb128: so, the cdbs rule tries to update it and fails with 'intltool-update: POTFILES.in not found.'; then, later, there apparently is a custom rules snippet which calls it again
<Kamion> mdz: ?
<seb128> pitti: right, that's because it's built out of the src directory
<seb128> pitti: to debian/build, so the cdbs snippet doesn't work
<pitti> ah, I see
<Kagou> smurf, around ?
<seb128> pitti: I'm about to make a panel upload, should I make that intltool-update call --verbose?
<pitti> seb128: can't hurt
<pitti> carlos, seb128: still, I'm totally lost about this g-p amd64/i386 difference
<seb128> weird, isn't it? :)
<carlos> yeah
<carlos> I didn't see anything wrong in the buildd output
<carlos> seb128: when the package is published, please, ping me so I remember to check that we didn't lose any string again
<seb128> carlos: I've just uploaded, ok, I'll let you know
<pitti> carlos: and apart from the mo files, the amd64 and i386 tarballs differ only in the pot file
<carlos> pitti: btw, I'm asking for removal the pmount .po files that you migrated to the right locale... sorry for the delay...
<pitti> carlos: great
<pitti> seb128: hm, maybe --verbose will reveal something; I'll watch the next build log
<seb128> same for me
<Mithrandir> Riddell: is it known that splashdown doesn't work correctly on the kubuntu live cd?
<iwj> Mithrandir: Not that I know of.  In any case, it wouldn't work while firefox is running.  Why do you ask ?
<ogra> pitti, i dont want to uuencode the hwdb icon in my hal patch, would you mind a dependency on hwdb-client for hal-device-manager ? 
<Mithrandir> iwj: I want to change some default settings in my "make my desktop work the way I want, dammit" script.
<pitti> ogra: no, of course not
<ogra> thanks :)
<pitti> I grab some food now, bbl
<janimo> is something like mail latest uploader on FTBFS planned for soyuz?
<iwj> Mithrandir: You could edit /etc/firefox/pref/firefox.js, unless that has the wrong permissions.
<Mithrandir> iwj: I'll run this script on machines I don't have root on too, so that's unfortunately not a solution.
<iwj> Mithrandir: It's possible that editing ~/.mozilla/firefox/<random-number>.default/prefs.js will work but probably only after the profile has been created.
<Mithrandir> iwj: yeah, and it's the $random_number part which, well, is random.
<iwj> Mithrandir: Well, you could run firefox -CreateProfile (which needs an X display for no readily apparent reason ...)
<Mithrandir> iwj: vfb-run handles that, so that's fine, really.
<Mithrandir> iwj: hmm, I could possibly do that and go to a javascript URL.
<iwj> Hmm, thinking of it, you should really edit/create user.js and not prefs.js (in the same directory as prefs.js).
<iwj> No, create the profile with -CreateProfile and now just grobble through ~/.mozilla to find the right directory.
<Keybuk> grr
<Keybuk> I hate people who file bugs just because they think something is wrong with code
<Keybuk> not because they've actually found a problem with it
<Keybuk> "foo fails to frobnicate bar!" ... "we don't have bar in dapper" ... "oh"
<Keybuk> type thing
<Keybuk> or, in this case, udev doesn't check for /proc/sys/kernel/hotplug ... that's right, we don't USE that
<fabbione> Keybuk: we don't????? HOLY COW THE WORLD WILL FALL DOWN
<Mithrandir> Kamion: is it nontrivial to change "CD" to "DVD" in the "check cd for defects" menu entry on the dvd?
<Kamion> Mithrandir: yes, requires translation
<Kamion> sorry
<Mithrandir> point.
<Mithrandir> want a bug about it anyway?  (Or maybe you have one?)
<pitti> re
<mdz> seb128: I was just going through Testing/Short, the bit where you copy the file and check that it isn't read-only
<mdz> seb128: that works, but only if I hold Ctrl when dragging the file, otherwise it says it can't move it
<mdz> seb128: if it can't move, shouldn't it fall back to copying?
<seb128> mdz: it should, we have a bug about that but it works fine on my box
<seb128> (ie: dnd from /usr to my desktop copy)
<mdz> Kamion: after a default ubiquity install in vmware, I have two entries for the CD in sources.list (one commented, one uncommented) which looks a bit confusing in synaptic
<mdz> seb128: reproduced easily here in vmware with Examples
<mdz> dragging to the desktop
<mdz> seb128: also on my laptop here
<mdz> seb128: any debugging I can do?
<seb128> mdz: what do you dnd, from where to where?
<mdz> seb128: about-ubuntu.odt from example-content to the desktop
<mdz> seb128: er, about-these-files.odt
<mdz> which is root/root 0644
* mvo_ is away for lunch
<carlos> pitti: are you still using the mapping.txt file from the language pack tarball?
<mdz> Keybuk: while you're doing archive stuff, could you do that pngcrush sync mvo mentioned?
<pitti> carlos: yes, I do; is it broken?
<Keybuk> mdz: I've just started that one :)
<mdz> Keybuk: thanks
<Keybuk> how did you know I was doing archive stuff?
<seb128> mdz: do you have /usr and /home on the same partition?
* Keybuk checks for vnc running on his desktop
<mdz> Keybuk: malone told you
<mdz> s/you/me/
<mdz> seb128: yes
<Lure> mdz: iegarty on #ubuntu-bugs directed me to you - bug 22985 (with many duplicates) - shouldn't this be on https://wiki.ubuntu.com/DapperReleaseRadar?
<Ubugtu> Malone bug 22985 in xserver-xorg-driver-ati "[x700]  fails to infer lvds for primary connector on acer ferrari 4005" [Major,Confirmed]  http://launchpad.net/bugs/22985
<seb128> mdz: it might work on my desktop because they are different partitions, lemme try on my laptop
<carlos> no, I'm looking into what's needed to move language pack tarballs into production and that file generation takes a lot of time, I was checking if it's needed (and thus, I should improve the code that generates it) or if I could remove it
<mvo_> mdz: the double cdrom thing is #45028
<mdz> Lure: not unless there is a trivial/obvious/safe fix available
<mdz> mvo_: thanks
<carlos> pitti: seems like the problem I had to generate language packs is fixed. Today, the export should work... still using the mirror, but should work
<pitti> nice
<Lure> mdz: ok, we will check if https://bugs.freedesktop.org/show_bug.cgi?id=1559 fix is it - if it fixes, where should we send the patch for consideration?
<Ubugtu> bugs.freedesktop.org bug 1559 in Driver/Radeon "radeon: Continuing problems with display detection" [Major,Reopened]  
<mdz> Lure: in malone, it points to fd.o bug 5473, not 1559
<Ubugtu> Malone bug 5473 in pyopenal "pyopenal: merge new debian version" [Normal,Fix released]  http://launchpad.net/bugs/5473
<mdz> Lure: there is no patch attached to either of them that I see
<pitti> carlos: what's wrong with the 'gettext' domain? apparently it's from the gettext-kde source package
<carlos> pitti: just that I wasn't aware where it came from ;-)
<pitti> carlos: ah, now you know ;)
<mdz> dholbach: ping?
<pitti> carlos: 'man' is from belocs-locales-bin
<dholbach> mdz: pong
<pitti> carlos: ... and can be ignored
<mdz> dholbach: ETA for ubuntu-artwork update?
<dholbach> mdz: 5-10 min
<Kamion> mdz: not ubiquity-specific
<mdz> dholbach: thanks
<dholbach> mdz: fixing up as quick as i can
<Kamion> (bug already filed too, on apt-setup)
<carlos> pitti: anyway, I don't think we should translate gettext-kde, it's an ugly workaround from KDE that will not be used with KDE 4.x and it's only needed to generate KDE's .pot files... so I will not import it
<mdz> Kamion: mvo pointed out the bug, thanks
<carlos> pitti: ok
<pitti> carlos: right, I'll ignore it as well
<Kamion> mdz: do I need to work on it urgently for dapper?
<mdz> Kamion: nope
<pitti> carlos: 'test' is from source 'nevow'
<Lure> mdz: I know, sladen mentioned that fix is supposed to be commited recently in Xorg cvs - will look into this in the evening 
<mdz> wanted to know if it was filed already, and it is
<carlos> pitti: it's inside 'examples/i18n' ...
<carlos> I don't think we should import it either..
<pitti> carlos: right, I marked these as to be ignored in my scripts
<dsilvers> ogra: Did you want to make a change to the hal package?
<mdz> seb128: something seems to have broken splash-down; usplash doesn't get started when shutting down
<mdz> seb128: do you know anything about it?
<carlos> pitti: did you added too the ones noted by Riddell as obsolete?
<pitti> carlos: will do
<dsilvers> mdz: It's bug 35182
<seb128> mdz: yes, a sec, I find the bug
<Ubugtu> Malone bug 35182 in gnome-power-manager "Shutdown from g-p-m doesn't use uspash" [Minor,Confirmed]  http://launchpad.net/bugs/35182
<dsilvers> mdz: I have a patch for hal which I'm just about to try and test
<seb128> thank you dsilvers
<carlos> pitti: ok, thanks. That way we will get the list of any remaining template that we forgot to handle
<ogra> dsilvers, yep
<ogra> dsilvers, but only to the device manager and the galde file of it)
<ogra> *glade
<mdz> mvo_: did we get a .desktop file into g-a-i for sun java?
<Kinnison> ogra: If you can get a patch file to me, I'll add it to this upload
<ogra> Kinnison, will do, but pitti has to review it
* carlos workraves
<pitti> carlos: what's wrong with gnome-doc-utils?
<carlos> pitti: don't know
<carlos> what's wrong?
<pitti> carlos: it's mentioned in 'remove from buildd tarball'
<carlos> oh, sorry
<carlos> right
<Keybuk> dholbach: ping
<mdz> Kinnison: added to DapperReleaseRadar, please get that in
<dholbach> Keybuk: pong
<carlos> pitti: it's documentation 
<mdz> or else revert the change which caused it
<Kinnison> mdz: right.
<carlos> pitti: and should not be inside the language packs
<Keybuk> dholbach: no such package in Debian as festival-it
<dholbach> Keybuk: source package?
<pitti> carlos: are you sure? these are tools to generate documentation, and it has a proper pot and po/ directory
<Keybuk> dholbach: no such source :)
<Keybuk> oh, hmm
<dholbach> Keybuk: http://packages.debian.org/src:festival-it says so :-)
<Keybuk> ah
<Keybuk> it's already in dapper
<dholbach> oh... sorry
<Keybuk> same version
<dholbach> yeah - so we're good :-)
<dholbach> Keybuk: thanks
<carlos> pitti: if you take a look at it https://launchpad.net/distros/ubuntu/dapper/+source/gnome-doc-utils/+pots/gnome-doc-utils/de/+translate
<carlos> pitti: you will see that the translations are used to generete XML files
<pitti> carlos: ah, ok; ignoring then
<pitti> Riddell: what about the obsolete domains in kdeedu, kdelibs, etc.? why are they still in the kde-i18n-* packages?
<pitti> Riddell: I can add machinery to my scripts to ignore these domains, of course, but it seems untidy
<Kinnison> ogra: well, modulo the test I'll be doing in a few minutes (once this is built) I imagine I'll be uploading my hal fix fairly soon, so you may just end up doing your own upload later
<dholbach> mdz: uploading
<mdz> dholbach: thanks
<mdz> dholbach: update DapperReleaseRadar when it's in
<Riddell> pitti: they're because nobody had removed them from KDE SVN, but they all seem to have been removed now so it'll sort itself out in the next kde release
<dholbach> mdz: okay
<pitti> Riddell: ok, so I need to manually ignore them now for the final dapper langpacks
<pitti> carlos: should today's rosetta tarball contain all domains now (in theory)? I. e. do I still need to merge tarballs?
<ogra> pitti, Kinnison, http://people.ubuntu.com/~ogra/20_add_hwdb_button.patch
<carlos> pitti: in theory, you should not need anything from buildd
<carlos> pitti: but let's get the diff report today to be 100% sure
<pitti> ogra: what is that huge removed part in the glade file?
<pitti> carlos: I just ask whether I should go and implement a 'KDE domain ignore list' or not
<pitti> ogra: oh, btw, patching build-tree won't help you, you need a proper debian/patches/foo.patch
<carlos> pitti: well, if it's not trivial (done in less than 5 minutes), you could leave it if you want and we can manually remove them from the report later to detect any other missing translation domain
<pitti> carlos: hm, just for the sake of a clean report and avoiding errors, I'll do it now (shouldn't be more than 10 minutes)
<Kinnison> pitti: If the patch is otherwise okay, I can deal with updating the hunk headers (I do so for my own patches)
<carlos> pitti: ok
<carlos> thanks
* Kinnison will brb
<pitti> Kinnison: hard to tell just from looking at the .glade diff; but I assume ogra tested the gui and it actually works :)
<Mithrandir> uh, casper-md5check seems to not work correctly, for some reason.
<Kinnison> Right, now my irssi is in a screen session I can reboot
<pitti> Kinnison: hard to tell just from looking at the .glade diff; but I assume ogra tested the gui and it actually works :)
<Kinnison> back in a bit
<ogra> pitti, it does
<pitti> ogra: that should be fine then
<ogra> pitti, i admit the glade stuff is ugly, but i didnt want to hack the file by hand :)
<pitti> right
<pitti> it'll just be hard to adapt it to new upstream versions then
<pitti> but let's not worry about that today
<ogra> i dont think the glade ever changed since 0.4.*
<mdz> mrgby
<pitti> mdz: bless you
<mdz> ^^ that is 'mount' typed on the wrong keyboard, which happens to have a dvorak layout
<ogra> lol
<ogra> hmm, looks like the pngcrush stuff for hwdb and u-m gains us a lot, even on edubuntu 
<mdz> ogra: that's why I asked you to do hwdb almost 2 months ago
<ogra> mdz, i tzried several times but couldnt get pngcrush to work, sorry
<mdz> Mithrandir: casper-mdcheck seems to work for me (i386/vmware, current daily)
<Mithrandir> mdz: does it give you the reboot thingy at the end?
<mdz> ogra: you didn't say anything
<mdz> Mithrandir: dunno, it's still running
<Keybuk> bah, someone remind me the magic rsync cdimage incantation
<tseng> thom: right, dapper
<Keybuk> ah, s'ok, was in my history
<infinity> Kamion: I didn't change DISTRIB_RELEASE, I just didn't UNchange it.
<fabbione> are tasks or meta packages gone foobar today?
<fabbione> (12:52:11) Anders: I'm inside something called XFce now?!??!
<fabbione> 12:52:46) fabbione: what did you install?
<fabbione> (12:53:00) Anders: i updated my Kubuntu :p
* fabbione scratches his head
<pitti> fabbione: shhh, part of KDESabotageSpec
<MysteriousGEGL> heh
<Kinnison> Who knows the most about usplash?
<pitti> carlos: ok, everything should be cleaned in the buildd tarball that starts in 3 minutes
<pitti> carlos: I'll check it afterwards by comparing the previous and new buildd tarball
<Kinnison> infinity: Do you have any idea why usplash_down ; usplash_write ; shutdown -h would fail as a sequence?
<mdz> Kinnison: it doesn't
<Kinnison> infinity: I get usplash displayed, it shows the message, then I get the X is going away noise and it flips back to tty1
<infinity> Yeah, uhm, what?
<infinity> Oh, you're doing it from a console.
<mdz> Kinnison: what happens is that gdm switches VTs, which causes usplash to shut down
<infinity> Yeah.  What he said.
<Kinnison> mdz: Aah, right
<mdz> that was mentioned in the bug report
* Kinnison admits he got a bit lost reading through the report
<infinity> GDM switching back to itself to kill itself is braindead, but it doesn't break our default setup much, so I've never cared.
<mdz> even if gdm didn't do that, X would
<infinity> (And since if you're shutting down from a text consoles, you're not likely to mind a text shutdown,...)
<mdz> so perhaps usplash_down should be run from init.d/gdm?
<Kinnison> hmm, so init.d/gdm stop would run usplash_down ?
<mdz> seb128: any opinion on that?
<mdz> would cause confusing results if gdm were not in use
<infinity> mdz: I ran it from GDM itself to avoid the noise one would get in doing it in the init script.
<Mithrandir> uh, you might want to stop gdm without running usplash.
<mdz> noise?
<infinity> I still maintain that if you're not shutting down "graphically", you don't much care if your shut down it, well, graphical.
<infinity> s/down it/down is/
<mdz> infinity: that is not the issue here
<mdz> infinity: it's bug #35182
<Ubugtu> Malone bug 35182 in gnome-power-manager "Shutdown from g-p-m doesn't use uspash" [Minor,Confirmed]  http://launchpad.net/bugs/35182
<mdz> infinity: which is pretty much "usplash
<infinity> mdz: There's some chatter from GDM and init before the GDM init script runs.
<mdz> "usplash-down doesn't work at all"
<Kinnison> infinity: You are shutting down "graphically" in the sense that gdm now signals hal to do the shutdown and thus we need the hal shutdown script to use usplash
<mdz> "again"
<infinity> Kinnison: Oh, ahh.  I see.  Whole different ballgame.
<mdz> seb128: thoughts on reverting to the old way of shutting down?
<infinity> Can g-p-m not just signal gdm to do the shutdown?
<Kinnison> seb128: We should just not use g-p-m for shutdown for now
<Kinnison> seb128: but continue to call it for suspend and hibernate
<seb128> mdz, Kinnison: fine with me, I can change it back to use gdm
<Kinnison> seb128: then I could get g-p-m to signal gdm
<seb128> seems reasonable
<Kinnison> seb128: rather than hal
<Kinnison> It's a bit bodgy but it seems the least invasive method of getting it done
<mdz> Kinnison: I don't think we need to change g-p-m
<seb128> no, just change gnome-session to use gdm
<Kinnison> mdz: just deal with the fact that g-p-m emergency shutdown won't be usplashed
<seb128> that should be enough
<Kinnison> ?
<mdz> #35182 is a minor bug when we don't use g-p-m as our primary method of shutting down
<carlos> pitti: ok, thanks
<Kinnison> mdz: okay
<mdz> seb128: yes please
<Kinnison> seb128: yep, do you want me to do that, or will you dump it on your list?
<mdz> seb128: reboot as well
<seb128> alright, doing that then ;)
<Keybuk> Kinnison: does g-p-m still save the session when it does an emergency shutdown?
<seb128> Kinnison: I'll do it, I know what to change that will be quick
<Keybuk> because if it does, that's a release critical bug imo
<Keybuk> as we offer no way to undo it
<seb128> Keybuk: no, it has been changed
<Kinnison> Keybuk: no
<Keybuk> ok, cool
<Kinnison> Keybuk: I fixed that just before I moved
<Kinnison> Keybuk: 96-disable-session-save-on-shutdown.patch added in 2.14.3-0ubuntu2 on 8th May
<mdz> Kamion: the gfxboot labels on the DVD are sort of unfortunate; the user will go for "Install to the hard disk" in many cases where they want "Start Ubuntu" (for ubiquity)
<Kinnison> seb128: You're a star
<dholbach> any objections, if I clean up  Testing/Current ?
<Kamion> mdz: I realised that this morning, but I have trouble working out what to doabout it now
* dholbach takes that as a 'no'
<pitti> carlos: I fixed tuxpaint-stamps to build a POT file; that should be the last item on the page
<carlos> pitti: ok, btw, the translations for it will come from buildd so we still need the merge today
<pitti> :(
<carlos> next time, we will not need it
<carlos> anyway, next time, I guess we should export only updates from Rosetta, right?
<dholbach> mdz: you think it'd make sense to point to the Testing wiki in the topic?
<carlos> pitti: should I do the export daily?
<fabbione> dholbach: what's the url for current?
<dholbach> fabbione: https://wiki.ubuntu.com/Testing/Current
<dholbach> it was nearly empty and from 11 days ago
<fabbione> dholbach: thanks
<pitti> carlos: hm, can you leave the current full daily export until the release, just in case/
<pitti> carlos: ?
<fabbione> dholbach: clean it up and let's start fresh
<mdz> Kamion: just did a brainstorming session with Jane
<dholbach> fabbione: yeah, just did it
<mdz> Kamion: pasting our proposal
<carlos> pitti: sure
<carlos> pitti: but I need the exact tarball you used for the final build so we get the updates relative to that export
<carlos> so please, tell me if you do a new upload
<Mithrandir> mdz: ok, I can't reproduce the reboot problem with the i386 iso in vmware, so I think it might be a DVD-only problem.
<pitti> carlos: is it possible to keep all of them from now on until June 1st?
<mdz> Mithrandir: reboot problem?
<carlos> pitti: all the daily exports?
<pitti> carlos: I'll modify my scripts to keep them, too
<pitti> carlos: yes
<carlos> sure
<Mithrandir> mdz: yes, after casper-md5check finishes, it just continues booting on the dvd.
<carlos> the removal is done by hand
<mdz> Mithrandir: ok
<carlos> until we move into production the script
<mdz> Mithrandir: on my CD test in vmware, it works correctly as well
<mdz> I'll check on the DVD
<carlos> but anyway, I was planning to store them at people.ubuntu.com as a backup
<Kinnison> ogra: since there's no point me doing this broken patch for hal, you may as well go ahead with your own hal package
<ogra> ok
* Kinnison toys with the idea of lunch
<mdz> ogra: what are you doing with hal/
<Kinnison> mdz: as per the patch quoted earlier, he's adding a hwdb button to hal-device-manager I think
<ogra> mdz, adding the hwdb button back
<mdz> ogra: ok
<mdz> Kamion: what's a good test case language which is on the DVD but not the CD?
* Kinnison -> Lunch
<mdz> Mithrandir: are you taking care of the g-p-m reconfiguration issue with ubiquity?
<mdz> Mithrandir: (I've put your name next to it on DapperReleaseRadar)
<Mithrandir> mdz: I uploaded that two hours or so ago
<Mithrandir> mdz: I can test it once we have images too, sure.
<mdz> oh, missed it
<mdz> Mithrandir: should be testable by doing an upgrade on the current daily, yes?  I'll do that
<Mithrandir> mdz: thanks
<Keybuk> ok, hopefully that makes bzr "installable" now
<Keybuk> bzr-doc was NBS
<Riddell> Mithrandir: I know splash down doesn't work in all situations yes
<mdz> Keybuk: I had already reminded jbailey about -v by private mail ;-)
<mdz> Mithrandir: casper binaries don't seem to be published yet
<mdz> I'll test later on
<j^> is fontrendering in evince still broken? i.e. http://blog.wired.com/27BStroke6/att_klein_wired.pdf does not work here with evince, works with xpdf though
<Kamion> mdz: install CD or live CD?
<mdz> Kamion: preferably both
<Kamion> mdz: (though of course the live filesystems are still identical on the live CD and the DVD; we never got round to fixing that)
<mdz> Kamion: we never got round to adding that feature ;-)
<Kamion> mdz: the i386 install CD has all languages on it, as far as I can see
<mdz> oh
<Kamion> the i386 live CD has en zh bn de fr
<Keybuk> mdz: heh, public humiliation also serves as a reminder for others ;)
<mdz> Kamion: i386 DVD d-i English install in VMWare went fine
<Kamion> yay for working DVDs at last
<mdz> j^: looks fine in evince here
<sladen> here do missing multimedia mime-types/file extensions og?
<j^> mdz first page is fine here, but fails on page 2
<mdz> j^: doesn't fail here
<seb128> what is the issue?
<j^> seb128 http://blog.wired.com/27BStroke6/att_klein_wired.pdf
<seb128> mdz, Kinnison: gnome-session using gdm uploaded
<j^> fonts do not render starting on the second page here
<mdz> j^: that is a URL; he asked for a description of the problem
<mdz> seb128: thanks, I will update DRR
<j^> mdz one thing at a time :)
<seb128> j^: that PDF displays fine for me
<j^> seb128 for some time now evince can only handle some pdfs here
<j^> any idea what could be the problem?
<seb128> "can only handle some pdfs here"
<seb128> it's as clear as "doesn't work"
<mvo> Kamion, mdz: dvd-install looks good on my system 
<j^> seb128 the text shows up as random garbage
<seb128> do you get an error? does you box explode? does it has weird color? does it ... ?
<seb128> j^: could you run "pdffonts att_klein_wired.pdf" and copy that to pastebin.com ?
<mdz> j^: try it in a pristine environment (live CD)
<seb128> might be some font you installed which get picked by fontconfig
<j^> seb128 oh you are right, i had some fonts in ~/.fonts removing them it works
<seb128> :)
<j^> gnome-font-view displays the font without problems though
<seb128> the issue is not the font I think
<seb128> it's that the font doesn't ship the glyph required for the pdf
<seb128> glyphs required
<mvo> live-dvd (i386) looks good too 
<sladen> seb128: PDF's should embed the font unless it's one of the standard 14
<seb128> sladen: that's not an evince issue what PDFs do or not
<sladen> seb128: is a corrupted embedded font?
<seb128> I've no idea, ask j^
<seb128> he had an issue due to a font he installed to ~/.fonts on his dapper
<j^> it was Times.ttf from apple
<infinity> Keybuk: Did you already remove bzr-doc from the seeds when cleaning up the archive mess?
<infinity> Keybuk: (I was going to do so earlier, but the bzr bug at my homework)
<infinity> s/at/ate/
<Keybuk> I did
<ogra> pitti, ping
<pitti> ogra: ?
<Mithrandir> oh, 32 bit sucks so much
<ogra> pitti, at which point is the lpi patch added to hal ? seems my button patch isnt liked by it and the only thing i can see touching the glade file is lpi
<ogra> but it has no number and i dont see it while testbuildind
<ogra> *testbuilding
<pitti> ogra: debian/patches/lpi.patch ?
<ogra> yeah
<ogra> i dont see it in the build process at all 
<pitti> ogra: they are applied asciibetically
<ogra> oh, k, thanks 
<ogra> then they need to be before the numbered patches i guess
<pitti> ogra: see /msg
<ogra> yep
<dholbach> mvo: how ok are you with  http://daniel.holba.ch/ubuntu/lpi.patch ? launchpad-integration on the live cd is busted without it.
<seb128> dholbach: did we get a bug about that?
<dholbach> seb128: the bug just occured to me
<dholbach> seb128: and that's the quick fix I wrote
<dholbach> seb128: I'm sure mvo can fix that more elegantly :-p
<seb128> k
<Mithrandir> Keybuk: have you changed splashdown so initscripts no longer read from the correct tty?
<dholbach> pressing enter on the "remove disc from try, press enter when you're done" message didn't shut down my box - did anybody else have that issues too?
<dholbach> (amd64)
<mdz> mvo: did you see Subject: Results: upgrade from Breezy using update-manager
<mdz>  ?
<Mithrandir> dholbach: yes, I see it on i386 in vmware.
<mdz> dholbach: shutdown or reboot?
<dholbach> mdz: shutdown
<mdz> hmm, haven't tried that
<Mithrandir> dholbach: does Alt-F7 RET fix it for you?
<dholbach> Mithrandir: on which package should i file a bug?
<mdz> but reboot works fine
<dholbach> Mithrandir: lemme try
<dholbach> *booting up again*
<mdz> dholbach: does it print the "Will now halt" or no?
<dholbach> mdz: will test
<mdz> janimo: hi
<janimo> mdz, hi
<Keybuk> Mithrandir: I haven't changed splashdown
<mdz> janimo: how is xubuntu looking for the RC?
<dholbach> mdz: no, doesn't print it
<janimo> mdz, there are a few bugs to be fixed  still
<dholbach> mdz, Mithrandir: it write it, when I press alt-f7 and then press enter
<janimo> some fixes I have queued for upload
<janimo> mdz, is it on Thursday or Friday?
<Mithrandir> Keybuk: this used to work; init scripts used to read from the usplash tty.
<Keybuk> Mithrandir: then something has broken, no?
<Mithrandir> Keybuk: no shit. :-P
<Mithrandir> Keybuk: since you're the guy twiddling those parts of the system, I figured asking you first would be a useful start.
<Keybuk> init scripts will read from whatever tty they're run with
<Keybuk> I haven't deliberately twiddled that stuff, to my knowledge
<janimo> pitti, did you say you were ok with evince-gtk after all?
<janimo> as the lesser evil
<mdz> janimo: Thursday
<pitti> janimo: it's less evil than introducing an entirely new codebase as pdf viewer, yes
<janimo> mdz, when must uploading freeze before Thu?
<pitti> janimo: ask for promotion in a quick moment when I'm mentally or physically absent and sneak it in :)
<Keybuk> Mithrandir: I can't see anything in either sysvinit or usplash's recent changelog that would break it
<Keybuk> they're all minor changes
<janimo> pitti, yay!
<mdz> janimo: nowish
<Keybuk> are you sure this ever worked?
<Mithrandir> Keybuk: yes, I'm quite sure.
<mdz> janimo: I sent mail to debian-devel-announce about this last week
<dholbach> Keybuk: I'm quite sure it used to work.
<janimo> mdz, I saw that mail but also quite some uploads this morning
<Keybuk> Mithrandir: has it worked since we've had usplash running to the end of the shutdown sequence?
<mdz> janimo: er, ubuntu-devel-announce
<pitti> mdz: are you fine with uploading new langpacks tonight?
<dholbach> "If you care about Ubuntu uploads."
<janimo> mdz, do all uploads need explicit permission and then are ok?
<pitti> mdz: (after thorough tests, of course)
<Mithrandir> Keybuk: with the reusplash change?  Afaik, yes.
<Keybuk> Mithrandir: well, to usplash since then there's just boring artwork changes
<Keybuk> and to sysvinit, only initscripts changes
<Mithrandir> Keybuk: at least, I've seen the "please remove disc and press enter" message in usplash.
<mdz> janimo: we are uploading for showstoppers (DapperReleaseRadar) and some trivial and safe fixes
<Keybuk> so I can't see anything that would break it
<mdz> pitti: yes; are you going to flush -update as well?
<pitti> mdz: yes, they have always been empty in development release uploads
<pitti> for the sake of minimizing space requirements on CDs
<mdz> oh, i didn't realize
<dholbach> Ok, I let the amd64-live-cd-erase-disk-install running, while I go out with the dog and get some lunch
<dholbach> see you later
<janimo> pitti, I have synced xubuntu-system-tools up to g-s-t latest, and cleaned up the diff.gz, all is in debian/patches. This also is a lesser evil than a another gui netconfig app, can this please be promoted while you are not watching?
<tseng> haha
<pitti> janimo: if you are content with the stability and functionality of evince-gtk, well, blimey, go ahead
<ogra> mdz, when was a preview button added to g-s-s ? (i dont have one (and i didnt add the one you found to intrusive))
<mdz> ogra: it displays in a small window
<janimo> pitti, so I put the MIRs back in the wiki or just ask Scott or Colin to promote?
<Mithrandir> Keybuk: if you choose shutdown from gdm, what is the tty initscripts will read from if you use "read"?
<mdz> ogra: is that hal patch ready for review?
<ogra> mdz, they want fullscreen preview triggered by a button as x-s-s had
<Keybuk> Mithrandir: absolutely no idea
<mdz> ogra: that will not happen for dapper
<Keybuk> at a guess, they read from /dev/console
<pitti> janimo: I'll change them
<janimo> pitti, ok thanks a lot
<ogra> mdz, i seem to be to dumb or cdbs doesnt like me, seems i cant even add one line to the DeviceManager.py and make it apply accordingly ... :/ working on it
<Kamion> mdz: the patch in 40692 looks reasonable; can I upload that?
<Kamion> bug 40692
<Ubugtu> Malone bug 40692 in yaboot "No boot with 1.3.13-4.1ubuntu4" [Normal,Needs info]  http://launchpad.net/bugs/40692
<ogra> mdz, yes, thats how i understood it :)
<Keybuk> Mithrandir: otherwise, if I were to make an uninformed guess, they'd read from tty7 because that's the tty that gdm issues the shutdown request from
<mdz> Kamion: yes
<mdz> Keybuk: could you help ogra get his patch to apply?
<pitti> janimo: btw, what would be so wrong about just taking evince for xfce? do the gnome libs impose so much overhead?
<Keybuk> mdz: yes
<mdz> thanks
<Keybuk> ogra: mail me the patch and I'll look into it after lunch
<janimo> pitti, not counting startup time (extra 30 libs) there are a few megs of RAM while running
<ogra> Keybuk, i dont even get this one working as zzz_hal_button.patch: http://paste.ubuntu-nl.org/14464
<janimo> pitti, plus esd gconf and g-vfs daemons started
<janimo> plus as seen recenlty while abiword temporarily got gnome deps for a few days >50M on the CD
<janimo> that means quite a lot of language packs :)
<pitti> ogra: how did you create the patch? relative to lpi.patch?
<ogra> pitti, cdbs-edit-patch zzz_add_hwdb_button.patch
<pitti> ogra: btw, you might find http://people.ubuntu.com/~pitti/scripts/cdbstpatch useful for editing hal patches (cdbs+tarball.mk)
<pitti> ogra: cdbs-edit-patch doesn't work with tarball.mk
<ogra> eek
<ogra> ok
* ogra looks at the script
<pitti> yes, it's something I wanted to improve since long ago...
<pitti> ogra: that script is just a thin wrapper around dbs-edit-patch which makes it a little more comfortable
<ogra> uuhh, shudder ...
<ogra> yep, i see it
<ogra> thanks a lot, that will help :)
<ogra> *sigh*
<ogra> pitti, doesnt work ... 
<ogra> Applying patch desktop-POTFILES.patch ... successful.
<ogra> Applying patch hdm-python2.4.patch ... failed!
<ogra> ogra@edubuntu:/mnt/devel/packages/hal-0.5.7$
<Mithrandir> why don't you just use a revision control system?  There's this quite neat system called bazaar I've heard about..
<mdz> Riddell: opinions on bug #45004 and bug #43949?
<Ubugtu> Malone bug 45004 in kdebase "konqueror :filebrowser profile only available" [Normal,Unconfirmed]  http://launchpad.net/bugs/45004
<ogra> Mithrandir, doesnt really help me now :)
<Ubugtu> Malone bug 43949 in kdebase "Konqueror View Mode Toolbar Icons" [Normal,Unconfirmed]  http://launchpad.net/bugs/43949
<Riddell> mdz: 45004 looks like a problem with not having kubuntu-default-settings involved, so that's a valid issue
<mdz> Riddell: these two bugs were referenced in Subject: Konqueror profiles removed, why this? on ubuntu-devel
<Riddell> 43949 is part of SimplifyKDE and can be reverted by removing kubuntu-default-settings
<Riddell> mdz: I'll read up on and reply to that thread
<Riddell> mdz: do we need to get approval before uploading packages now?
<mdz> Riddell: if it's not on DapperReleaseRadar, yes
<mdz> Riddell: if you have a hit list for the RC, please share it
<ogra> pitti, any idea ? 
<Riddell> mdz: new docs upload just about to happen, I'll fix 45004 in kdebase, I want to check the KDE timezone change module to make sure it's working correctly
<pitti> ogra: ah, hdm-python.patch uses -p0, just fix it to use -p1
<ogra> ok
<mdz> Riddell: docs OK; what's required to fix 45004?
<seb128> mdz: "Update path in gnome-panel" (for the book item) is done since this morning
<mdz> Riddell: and what's the issue with the timezone change module?
<mdz> seb128: thanks, will update the page
<seb128> np
<Riddell> mdz: 45004 add back the file apps/konqueror/profiles/filemanager
<mdz> Riddell: why was it removed?
<janimo> mdz, FYI https://launchpad.net/people/xubuntu-team/+subscribedbugs   . I marked those I consider important for the release major and are at the top
<Riddell> mdz: for timezone it was copying a file to /etc/localtime when it should be creating a symlink (I think)
<Riddell> mdz: we removed some old profiles from konqueror that KDE's usability people said were unused and unnecessary, by the looks of that bug it seems we removed one or two important ones too
<jono> hey
<jono> what is matthew east's nick?
<Riddell> jono: mdke 
<jono> mdke: ping!
<jono> thanks Riddell
<mdz> janimo: do you think you can fix them all today?
<janimo> mdz, may 3 of them
<mdz> Riddell: /etc/localtime should be a copy, not a symlink
<janimo> unlikely all (although one is not confirmed)
<janimo> s/may/maybe/
<janimo> mdz, one is fixed locally I was going to wait upstream's opinion, but otherwise it's ready for upload
<tepsipakki> localtime is a symlink on every machine that I've installed..
<janimo> pitti, did you see my question 20 min ago re xubuntu-system-tools and its not being very evil?
<mdke> jono: I'm busy at work atm, can you email? I'll respond when I can
<mdz> it's a copy on my laptop and a symlink on my desktop
<mdz> Riddell: ok to fix
<mdz> Riddell: (the profile thing)
<pitti> janimo: oh, I misread it as evince-gtk
<mdz> Riddell: if it's copying over a symlink and clobbering the destination, that's serious and worth fixing too
<Riddell> I have a symlink in /etc/localtime, so maybe kde makes a symlink when it should copy
<mdz> Riddell: <mdz> it's a copy on my laptop and a symlink on my desktop (both Ubuntu)
<Kamion> the installer makes it a symlink
<jono> mdke: sure :)
<janimo> pitti, I gave it the same treatment as latest evince-gtk (based on same orig.tgz as g-s-t and debian/pactches dir, cleaned up diff.gz)
<Riddell> mdz: oh, strange
<janimo> pitti, so it is only the rules/control different and one extra patch vs g-s-t
<pitti> janimo: hrmng
<janimo> pitti, and this is a lesses evil again, a while back I did not pursue MIRing gnetswitch since I found this
<janimo> as gnetswitch was originally planned as the UI network configurator
<Kamion> if you make /etc/localtime a copy then you need to be sure that the copy will be refreshed from the correct place when the timezone data in /usr/share is updated
<janimo> but since it's totally new and less mature than g-s-t...
<Kamion> I don't believe any maintainer script deals with that at the moment
<pitti> janimo: bah, I really don't like it, but if you need it, so be it
<janimo> pitti, well the users need it mostly, I have DHCP :). Thanks a lot :)
<janimo> great, with this xubuntu users will hopefully only need the cmdline for adding a printer.
<janimo> mdke: hi, re xubuntu-docs upload. You said the translations are in rosetta, and I need to make a new upload of the package right?
<mdz> Kamion: one difference between my laptop and my desktop is that I have on several occasions used g-s-t to set the time zone on my laptop
<zul> hey
<Kamion> mdz: sounds like that would do it
<mdz> Riddell: the current kubuntu live ISOs seem to be oversized
<Riddell> mdz: I've changed the seeds, I'll ask for a rebuild once new docs are in
<ogra> meh, edubuntu live i386 exploded as well with yesterdays build ... :(
<ogra> mdz, hal uploaded
<mdz> Riddell: i was just testing ubiquity under kubuntu, and while the installation progress bar is running, I get a dialog "A new medium has been detected" about the filesystem it just created
<mdz> Riddell: known bug?
<Riddell> mdz: not known, I've not had any reports of that, I did see if myself once a number of weeks ago but never since then
<mdz> Riddell: this is under vmware
<Riddell> it wouldn't be hard to turn off kded mediamanager to be on the safe side
<mdz> ogra: thanks
<Keybuk> ogra: your patch applies now?
<ogra> Keybuk, yes, apparently tarball.mk doesnt work at all with cdbs-edit-patch, pitti has a special script for such packages
<Keybuk> indeed it doesn't
<Kamion> Riddell: it's known, you left a comment about it :P
<Keybuk> it's on my list of "reasons I hate cdbs"
<Kamion> I see it all the time
<Keybuk> I think it's number 18,294
<ogra> hehe
<seb128> it's on my list of why I don't like tarball.mk :p
<ogra> with the script its fine (as long as all prevoius patches apply :) )
<Keybuk> oops, sorry, 181,294
<Keybuk> ;)
<BenC> Kamion: ping
<BenC> mdz: ping
<Kamion> BenC: hi
<BenC> Kamion: when are you planning a d-i upload?
<mdz> BenC: hi
<mdz> sfllaw: awake?
<BenC> mdz: hey, any word from Mark about his ipw3945 problem?
<Kamion> BenC: later today, for sparc; why?
<mdz> BenC: last I heard it magically started working again
<BenC> mdz: good, and weird...hopefully it was just a fluke :)
<mdz> Mithrandir: I have just seen the problem with the casper eject prompt on a Kubuntu i386 CD
<Mithrandir> mdz: yeah, I'm just not sure what the cause is.
<BenC> Kamion: I have a new kernel upload that affects sparc (enables sound and framebuffer i2c)...it's not required for install, but does d-i affect livecd?
<Mithrandir> mdz: that is, when it changed.
<mdz> Riddell: have you ever seen this happen?  casper displays the prompt via usplash to press enter, but doesn't respond when you do
<mvo> mdz: can I please upload a new notification-daemon? it fixes the ugly bubbles for bottom panels (bug #45632), a explaination is in my last bug comment, the debdiff is linked there too
<Ubugtu> Malone bug 45632 in notification-daemon "Short names in notification area render incorrectly" [Minor,Confirmed]  http://launchpad.net/bugs/45632
<mdz> Mithrandir: this never happens to me on ubuntu/i386
<Kamion> BenC: no, but it should be in sync with the newest kernel
<BenC> Kamion: here...
<BenC>   * powerpc64: Enable HUGETLB
<BenC>   * x86,amd64: Build-in rtc and genrtc on all but the 386 kernel.
<BenC>   * sparc: Enable CONFIG_FB_RADEON_I2C and CONFIG_SND_ALI5451.
<Mithrandir> mdz: I've reproduced it with ubuntu/i386 in vmware.
<BenC> that's the new kernel changelog
<mdz> mvo: ok
<mvo> mdz: thanks
<Kamion> BenC: rtc> have you removed the rtc-modules udeb?
<BenC> the rtc is the only thing that really affects d-i, but mainly because the rtc module udeb disappears
<mdz> Mithrandir: seems to be reading from vt7 for some reason
<Kamion> (it was in universe anyway)
<mdz> Mithrandir: is there a bug report open about this yet?
<Kamion> BenC: I don't think we use rtc any more in d-i anyway; that's why the udeb was in universe
<Mithrandir> mdz: not that I know of, no.
<Lure> mdz: I can confirm casper problem with yesterday's Kubuntu Live CD
<Lure> mdz: it happens only after ubiquity install, but works if I just used live CD
<Mithrandir> mdz: and since this used to just work without me having done anything, I haven't tested it properly.  Grr.
<dholbach> mdz: are you fine with  http://daniel.holba.ch/ubuntu/launchpad-integration.debdiff ?
<Kamion> Lure: what casper problem?
<Riddell> mdz: yes, I've seen that happen
<mdz> Kamion: the one Mithrandir and I are discussing, I hope
<BenC> I hate my power company :/
<BenC> my power flicks off for all of a second atleast once a day
<Kamion> ah
<Lure> Kamion: ENTER after eject CD does not work after ubiquity Kubuntu istall
<BenC> Kamion: when would be the best time to do this upload?
<Kamion> ubiquity/kubuntu just does shutdown; it doesn't exit the session cleanly
<Mithrandir> BenC: UPS?
<Lure> mdz: there was a bug opened, but I though it was closed - will try to find...
<BenC> I have one more one-liner patch that fabbione is doing/testing for PPC radeon crashes
<Keybuk> so, I'm trying to work out how ENTER would even get to the init script
<Kamion> Riddell tried to fix that a while back but it was more complex than expected
<mdz> Mithrandir: I wonder if it's related to the gnome-session/g-p-m business
<Kamion> shutdown> well, os.reboot
<Kamion> BenC: ASAP
<BenC> Mithrandir: I don't have a UPS on the satellite modem :/
<fabbione> BenC: booting now
<mdz> Keybuk: read(2)
<BenC> Kamion: as soon as I get the patch, it's uploaded
<Mithrandir> Keybuk: apparently, something is now switching VTs.  Something used not to.
<Keybuk> mdz: yes, but why would read from an init script read from tty8? :)
<BenC> fabbione: sweet, thanks
<Riddell> dcop doesn't like being called from an app being run as another user :(
<Kamion> because it'll be 7 hours from source accept before all the builds are finished
<Riddell> actually that would block turning off mediamanager too
<mdz> Kamion: I got a usplash shutdown after a ubiquity kubuntu install with the current daily
<Kamion> Riddell: I'm pretty sure we just need to drop ids in a sane way, but we'll try it out early edgy
<mdz> Keybuk: it's reading from /dev/console I believe
<Keybuk> mdz: right
<Keybuk> I'm wondering whether this has something to do with usplash getting killed and restarted by killall5
<Kamion> mdz: all I know is that it does subprocess.call(["reboot"] )
<mdz> Mithrandir: I think it's http://launchpad.net/bugs/35182
<Ubugtu> Malone bug 35182 in gnome-power-manager "Shutdown from g-p-m doesn't use uspash" [Minor,Fix committed]  
<mdz> Mithrandir: or rather, a related bug
<mdz> so it might be fixed with new gnome-session
<jono> can someone take a screenshot of the logout window for me - I did have VMWare on here to take a shot of it, but I don't have it any longer
<mdz> which should be published any day onw
<mdz> now
<Kamion> Riddell: (you tried it with su or kdesu or something; os.setregid()/os.setreuid() would be better - see how gtkui calls gnome-screensaver-command)
<Mithrandir> mdz: well, I'm doing this from gdm, not gpm, though.
<Lure> mdz: bug 41352
<Ubugtu> Malone bug 41352 in casper "LiveCD: Asks to press enter but doesn't react" [Normal,Fix released]  http://launchpad.net/bugs/41352
<Lure> mdz: last comment might give some hint
<Lure> mdz: also bug 42938
<Ubugtu> Malone bug 42938 in casper "kubuntu live won't restart if ENTER pressed before door shut" [Normal,Fix released]  http://launchpad.net/bugs/42938
<Mithrandir> hmm
<Mithrandir> what's responsible for restarting usplash?
<Keybuk> Mithrandir: /etc/init.d/sendsigs
<Keybuk> I'm wondering whether it needs a "-c" on that usplash call
<Keybuk> oh, no, it does already
<mdz> Mithrandir: what was the issue in 42938?
<Mithrandir> mdz: unsure.  I think I closed it as a duplicate of 41352
<Mithrandir> Keybuk: I'll try removing that -c and see if it helps.  I think that might fix it.
* ogra still pokes around to find what added 4MB to edubuntu live while he was away
<Keybuk> Mithrandir: why would that fix it?
<ogra> dholbach, do you have any idea what size the additions to your ubuntu-docs upload were ?
<Keybuk> without that, usplash would just draw over whatever is the active tty, no?
<Lure> ogra: Riddell is also wondering that for Kubuntu... ;-)
<dholbach> ogra: hum, I looked it up yesterday, it was only translations - I can't tell how much it was
<ogra> seems it was fine until saturday
<Mithrandir> Keybuk: yes, and which tty does the init script read from?
<mdz> Riddell: is there a Kubuntu version of Testing/Short?
<ogra> dholbach, the translations are in the langpacks, no ?
<dholbach> ogra: downloading both versions from launchpad and doing a debdiff is what i'd do to test
<mdz> Mithrandir: what was the cause of 41352, then?
<dholbach> ogra: you better ask mdke
<Keybuk> Mithrandir: it doesn't read from any tty, it reads from /dev/console
<jsgotangco> looks like its mostly translations
<Riddell> mdz: there isn't, I should make one
<jsgotangco> the current docs don't hvae that much images 
<BenC> mdz,Kamion: Ok, fabbione tested the one-liner for ppc/radeon and it fixes his crash
<fabbione> confirmed that the fix works
<BenC> I need this kernel in dapper, and it's non-abi bump and trivial
<BenC> Kamion: btw, the rtc changes only affected i386/amd64, so if rtc is used somehow in d-i, it's only needed on those arch's
<seb128> ogra: maybe example-contents dholbach uploaded?
<Kamion> BenC: yeah, as far as I know it isn't anyway, it was the old backhacked-from-base-config hwclock code that we've ditched now
<ogra> seb128, nope, thats not in edubuntu
<dholbach> hrm, why doesn't the booting from DVD work for me ... hrm
<ogra> but thanks for the heads up
<ogra> it must be a change that happened on saturday
<jono> anyone know what the ubuntu logout box program is called, and can I bring it up without selecting Log Out from the menu? I need to take a screenshot of it
<ogra> and that apparently also affects kubuntu
<mdz> BenC: bug#?
<BenC> mdz: The radeon problem was noticed by fabbione, no bug
* Keybuk wonders how /dev/console maps to ttys
<BenC> airlied provided the suggested fix
<mdz> BenC: where did the 'need' come from?  a new kernel would delay this evening's candidate until tomorrow
<Kinnison> Keybuk: maps to the foreground tty inside the kernel doesn't it?
<fabbione> mdz: i noticed yesterday evening. It crashes badly on PB
<Keybuk> Kinnison: in other words, it shouldn't matter a buggery what tty is actually selected
<fabbione> mdz: i didn't open a bug.. just retested with today's images, debugged and got a fix for it
<BenC> mdz: the need is that it crashes on his computer consistently
<Kinnison> keybuk: probably not, no
<marcin_> hi guys - where can I find changelogs for packages in dapper?
<marcin_> (I mean - website - I know that there are changelogs in packages - but there is some list or something - I just forgot url)
<fabbione> mdz:
<fabbione> -       {0x1002, 0x4E50, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350|CHIP_IS_MOBILITY}, \
<fabbione> +       {0x1002, 0x4E50, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350|CHIP_IS_MOBILITY|CHIP_NEW_MEMMAP}, \
<fabbione> this is the diff
<fabbione> it adds a flag for my card to use DRI/DRM in the correct way
<mjg59> fabbione: It probably needs doing for all the RV350s based on what Dave was saying
<fabbione> mjg59: yes, but he was looking into it
<fabbione> in the meanwhile i change and fix what i can test and confirm
<mvo> I guess fixes like http://librarian.launchpad.net/2388364/fix_changelog.patch for bug 41767 are not important enough now for a new aptitude upload?
<Ubugtu> Malone bug 41767 in aptitude "aptitude changelog <package without candidates> segfaults." [Normal,Confirmed]  http://launchpad.net/bugs/41767
<neuralis> Keybuk: do you still use a dualhead setup with your nc4020? have you used it in non-clone (actual dualhead) mode with dapper?
<Keybuk> neuralis: not in a while
<Keybuk> neuralis: but afaik it still works
<neuralis> Keybuk: it does, but all video playback is broken on the external flatpanel -- cpu usage shoots to 100%, no video shown. i've been trying to chase it down for a week, still can't put my finger on it, and don't know if it's just my setup.
<fabbione> neuralis: is that ati?
<Keybuk> fabbione: aye
<mdz> mvo: correct
<neuralis> fabbione: intel 915gm
<neuralis> fabbione: (i'm using the direct successor of keybuk's laptop, the nc4200)
<mdz> mvo: if you are bored, run through Testing/Long ;-)
<fabbione> so it's not ati
<fabbione> neuralis: i would complain to sladen.. he knows i810 better than i do
<neuralis> fabbione: will do, thanks.
<neuralis> sladen: ---^  when you get a chance.
<fabbione> neuralis: check also LP.. the i810 driver is not exactly in the top 10 for being good
<mvo> mdz: I'm not yet bored ;) I going over my bugmail right now, but testing is next once I catched up
<neuralis> fabbione: right, though it's a regression; worked fine since either hoary or warty
<fabbione> neuralis: eh.. i know :/
<neuralis> fabbione: LP didn't turn up anything related when i looked a few days ago
<fabbione> neuralis: xorg 7.0 has tons of regressions compared to 6.8.2
<neuralis> yeah, so i've found out when trying to figure this out
<fabbione> this "let's go modular" had a price
<fabbione> and we will pay it for a while
<neuralis> a bunch of the regressions actually do appear to be in dualhead, though no one mentions my specific issue
<fabbione> neuralis: bug 42731
<Ubugtu> Malone bug 42731 in xorg "MULTIHEAD SUPPORT META BUG" [Normal,Confirmed]  http://launchpad.net/bugs/42731
<fabbione> and yes.. i know.. i also suffer from one of them
<neuralis> it's not a huge deal, dualhead still works for everything except non-video playback here, but it means i have to reboot to xp to play a dvd :/
<fabbione> neuralis: no, you can just go for -vo x11
<fabbione> it's only xv that's affected afaik
<fabbione> it sucks some CPU but i think the machine can cope with that for you
<neuralis> reeeally. let me take a look.
<fabbione> atleast afaik
<BenC> mdz,Kamion: kernel is ready to upload
<mdz> fabbione: when did it regress?
<fabbione> mdz: between -22- and -23- i think
<mdz> grrrrr
<mjg59> The DRM update fixed various /other/ regressions
<fabbione> WTF is wrong with sparc today
<fabbione> i can't get a clean install without something going horribly wrong
<BenC> mdz: it was the result of fixing another bug basically...radeon had a bad hack for ppc that broke a lot of i386 hw
<BenC> and the drm update removed all that, in the hopes that it wasn't needed anymore
<mdz> BenC: no other changes in the upload, and no l-r-m update needed?
<BenC> but yeah, updated DRM fixed a crap load more than this one thing
<BenC> nope
<mdz> go ahead
<BenC> it's just a straight kernel update
<BenC> ok
<fabbione> mdz: the real bug is in the interaction between radeonfb and dri. way more complex to fix
<mdke> janimo: no, the translations are in the docteam repo. See my email
<mdz> I'll be here all night anyway, I expect
<fabbione> and now silo-installer is going downhill
<mdke> janimo: it's all in xml, like the english
<fabbione> WHY!!
<fabbione> it didn't change in ages and it was working last week
<mdz> mdke: did you get in touch with jono regarding the book chapters?
<mvo> is it known that when I click on "set time" in the current espresso the time-admin window opens behind espresso=
<mvo> ?
<Mithrandir> Keybuk: hmm, -c doesn't change anything either way.  So, something is changing tty, but I'm not sure what.
* BenC lets the new kernel fly
<Keybuk> Mithrandir: I still don't see what effect changing the tty would have
<mdz> mvo: I've seen that
<Keybuk> Mithrandir: /dev/console is always the active tty
<Keybuk> Mithrandir: and the stdin of an initscript is /dev/console
<tritium> seb128: I don't know if it's possible at this point for you to pull in any evolution patches from 2.7.x, but evoQA tells me the exchange calendaring issues are fixed
<neuralis> fabbione: yeah, it does appear to work, though 1.8 ghz can't keep up with fullscreen video playback :)
<Mithrandir> Keybuk: apparently not?
<fabbione> neuralis: it should----
<mdz> Keybuk: switching to vt7 seems to fix it somehow
<fabbione> AHHHHHHH
<fabbione> ok
<fabbione> it works
<seb128> tritium: "the exchange calendaring issues" ... all of the bugs existing are fixed?
<seb128> tritium: or do you speak about some particular bug?
<BenC> BTW, everyone, 2.6.17 for edgy will be uploaded as soon as edhy opens up
<tritium> seb128: not all, I would presume, but the ones I pointed out..
* BenC has it building everywhere right now
<seb128> tritium: I backported a collection of patches from CVS some days ago, is that not good enough?
<BenC> *edgy opens
<seb128> tritium: which ones did you point?
<tritium> seb128: such as, bug #40005
<mdke> mdz, he pinged me just now, and I asked him to email me
<Ubugtu> Malone bug 40005 in evolution-data-server "No alarms or appointment list for Exchange calendar" [Unknown,Unconfirmed]  http://launchpad.net/bugs/40005
<tritium> seb128: they did not fix the issues, no.
<fabbione> no
<fabbione> hell
<Keybuk> actually, does /dev/console map to the current tty?
<seb128> tritium: http://bugzilla.gnome.org/show_bug.cgi?id=338909 is still open
<Ubugtu> Gnome bug 338909 in Connector "No alarms or appointment list for Exchange calendar" [Normal,Unconfirmed]  
<tritium> seb128: yes, I do see that.  This is what evoQA tells me, though.
<seb128> tritium: who do you call "evoQA"? and ask them to point the CVS changelog entries for it
<Mithrandir> Keybuk: apparently, /dev/console != stdin, since adding < /dev/console to the read call works around the problem
<seb128> tritium: there is no way to backport a non-existant patch
<Keybuk> Mithrandir: that's kinda kooky then
<tritium> seb128: ok, let me look into it some more
<Keybuk>                         if ((f = console_open(O_RDWR|O_NOCTTY)) < 0) {
<Mithrandir> Keybuk: I can always just work around it for now, but we should fix this properly for eft.
<Keybuk>                                 initlog(L_VB, "open(%s): %s", console_dev,
<Keybuk>                                         strerror(errno));
<Keybuk>                                 f = open("/dev/null", O_RDWR);
<Keybuk>                         }
<Keybuk>                         dup(f);
<Keybuk>                         dup(f);
<Keybuk> is how init runs /etc/init.d/rc
<jono> can someone send me the wallpaper without the ubuntu dapper text on it?
<jono> I need to re-screenshot
<Kagou> smurf, around ?
<Mithrandir> mdz: so, apparently I can work around the casper-reads-from-wrong-tty problem by giving it /dev/console as input.  This is not the "correct" fix, but it works for me.
<mdz> Mithrandir: perhaps arrange for the shells on tty2-6 to remain open for debugging?
<mdz> Mithrandir: ok, sounds reasonable
<mdz> I was about to try to hunt around and see what it actually has as stdin
<bddebian> Howdy folks
<Keybuk> Mithrandir: I'm wondering whether casper somehow changes the console
<bddebian> Keybuk: Thanks for all the syncs, etc!!
<Mithrandir> Keybuk: it cats a bunch of files to /dev/null and calls eject + usplash_write, so I doubt it.
<Keybuk> Mithrandir: I mean right at the start, before init is even called
<Mithrandir> Keybuk: oh, the exec stuff you mean?
<mdz> Keybuk: this doesn't happen consistently; seems like some sort of race
<Mithrandir> Keybuk: that's reversed after it has mounted root and run the scripts.
<Keybuk> just seems odd that "< /dev/console" fixes it
<Keybuk> that implies that something has left stdin as something else
<mdz> Riddell: the .xcf file in example-content gets opened with Krita, but Krita can't display it
<Mithrandir> Keybuk: anyway, init is called by run-init with exec run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >${rootmnt}/dev/console
<Mithrandir> so what casper has or hasn't done is irrelevant.
<Keybuk> Mithrandir: init closes whatever it's given as stdin and stdout anyway
<janimo> fabbione: radeon id 0x1002, 0x3150, which is RV380 does work fine without the NEW_MEMMAP flag. Mentioning to make sure it is not accidentally changed as well in the last minute
<Riddell> mdz: kwwii looked at that but couldn't find a way to make krita like the .xcf, krita's .xcf import isn't perfect
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Release preparation in progress: https://wiki.ubuntu.com/DapperReleaseRadar
<mdz> Riddell: oddly, the preview looks fine
<mdz> in konqueror
<janimo> pitti, did you approve x-s-t? So I know when I asked for it to be promoted as I'll need to upload a new xubuntu-desktop .  thanks
<janimo> s/asked/ask/
<Mithrandir> mdz: ok with uploading that fix for casper, then?
<pitti> janimo: not yet in the wiki queue, but go ahead
<janimo> pitti, ok thanks
<janimo> Keybuk: can you please promote evince-gtk and xubuntu-system-tools to main?
<mdz> Riddell: on the current kubuntu daily-live, I get the "Unsupported Platform" message from the network configuration tool - I assume this will be fixed by the new base-files which changes DISTRIB_RELEASE back to 6.06?
<mdz> Mithrandir: yes
<mdz> Mithrandir: but let's do a build without waiting for it; I'd like to test the current round of fixes which were just published
<Mithrandir> mdz: sure.
<Keybuk> janimo: done
<ogra> oh, if you kick off a live build, please do edubuntu as well (hoping the savings in hwdb-client and u-m fix the size)
<janimo> Keybuk: thanks
<Keybuk> pitti: mozilla-thunderbird-locale-* should be picked up by germinate automatically, yes?
<pitti> Keybuk: I hope not
<Riddell> mdz: changing DISTRIB_RELEASE will break that, so that should be fixed with the revert
<Keybuk> pitti: shall I demote them all to universe then? <g>
<pitti> Keybuk: the packages I added this morning should be in universe
<ogra> Keybuk++
<pitti> Keybuk: only the ones that were in main before should stay in main
<Keybuk> pitti: ah, helps if you mention that
<ogra> it eats a lot of unecessary space on edubuntu
* Keybuk moves them to universe
<pitti> Keybuk: the new packages from this mornign are transitional packages for universe only
<pitti> Keybuk: sorry, and thanks
* Keybuk put them in main with the rest
<Keybuk> easily fixed *click*
<mdz> Riddell: confirmed by upgrading it, thanks
<Keybuk> c0r, anastacia is going to be japanese at the next publisher run
<Kinnison> Keybuk: pardon?
<mdz> Riddell: please add status comments at the left, like "[done]  something to do" as the existing items are, this makes it easier to scan
<mdz> Riddell: (on DapperReleaseRadar)
<jono> mdke, mdz: just sent the HTML chapters now
<mdz> jono: where?
<Keybuk> Kinnison: empty
<jono> mdz: emailed
<jono> mdz: to you and mdke
<mdz> dholbach: ready for an example-content update?
<dholbach> mdz: sure
<jono> damn, it bounced back, let me stick it online
<jono> mdke, mdz: http://jonobacon.org/files/ubuntubook-ch3-html.tar.gz and http://jonobacon.org/files/ubuntubook-ch6-html.tar.gz
<mdz> dholbach: ^^^
<dholbach> mdz: ok
<mdz> jono: nice uplink
<jono> :)
<jono> a few notes:
<jono> I converted these in NVU for speed. As such, the HTML is not all that great, but I simply did not have enough time to hand hack it.
<jono> Each of the images is relative the current directory of the main HTML file.
<mdz> dholbach: you can leave out *~ from the final package ;-)
<jono> There is no Ubuntu stylesheet attached to the files, but I have
<jono> used consistant H1, H2, H3 and H4 headings and standard HTML elements.
<jono> As such, I am sure Matthew can apply a consistant HTML stylesheet to
<jono> it.
* jono kicks on some AC/DC...
<Riddell> jono: are we getting the kubuntu chapter?
<jono> Riddell: I think Jonathan Jesse is onto that one
<Riddell> jjesse ^^ ?
<jono> Riddell: last I heard he was getting the HTML sorted today
<jono> the news that the chapters needed to be converted to HTML came as something of a surprise to jjesse very recently :P
<mdke> i get to do the css for this?
* mdke isn't sure he is going to have time
<jsgotangco> heh
<mdz> jono: he thought someone else was doing it? or that we would ship plaintext?
<jono> mdke: is there not a standard Ubuntu stylesheet you can just drop in ?
<jono> mdz: I was told to convert it to HTML
<ogra> mdke, do the translations for ubuntu-docs get split out into langpacks ? i have major probs on edubuntu (where we have only *bytes* free)
<Riddell> ogra: they don't
<ogra> eeek
<ogra> !
<mdke> ogra: no, they are in ubuntu-docs. But there wasn't anything new on saturday from us
<ogra> the package grew by 300k 
<mdke> only today, but it wouldn't have been as much as 4 MB
<jono> mdz: I can knock up a stylesheet if you like
<ogra> (on sat.)
<jono> mdz: I didnt create one as I though that one may have existed already
<mdz> mdke: is there an existing one we can use verbatim?  or give to jono to tweak?
<jono> oops, I meant that for mdke
<mdz> jono: perhaps the one from the website would work?
<mdke> mdz: yeah, looking at it it won't be too hard. I can probably do it
<jono> its full of standard headings, so should be OK
<mdz> jono: there is a /usr/share/ubuntu-artwork/ubuntu.css
<mdke> (this evening)
<Kamion> mdz: oops; can I upload installation-guide to change 6.04 to 6.06 or 6.06 LTS or something slightly more accurate? :)
<mdz> Kamion: yes
<jono> mdke: just keep an eye onthe H4 headings for the notes, they are indented a little
<Kamion> 6.06 LTS should be fine everywhere in fact
<mdke> jono: the html will need some slight tweaks. If you want to do it yourself, you'd save me a lot of time. You can use the stuff in /usr/share/ubuntu-artwork/home
<iwj> FFS, this .co.uk cookie security problem has been known upstream since _at least 2004_.
<ogra> iwj, yes, thats an old one
<ogra> wasnt that fixed ages ago ? 
<iwj> No, it seems not !
<ogra> bah
<jono> mdke: what kind of tweaks? do you just want me to use ubuntu.css ?
<ogra> i thought the mozilla guys offered a fix back then
<mdz> iwj: what are you working on at the moment?
<Kamion> mdke: when installation-guide 20060102ubuntu6 is available (just uploaded), could you update doc.ubuntu.com to that?
<iwj> mdz: I've got a list of 5 unpleasant firefox bugs I'm trying to either nail or decide to ignore.
<mdz> iwj: if you could review 'Georgian Font/Language Support Issue/ttf-freefont and "D" letter confusion' and see if there's a low-risk fix, that'd be appreciated
<iwj> I think I'm going to have to punt on the cookie one.  No sane patch upstream and anyway it feels like fragility to me.
<mdke> jono, yes, and add the three divs that you see at the top of index.html
<mdke> (masthead, mastwrap, content)
<jono> mdke: ok
<mdke> Kamion: yes, i'll try
<Kamion> thanks
<mdz> iwj: my gut feeling is that what they really need is for these fonts to be added to ubuntu-desktop, but it's too late for that
<mdz> they can have whatever font preferences they want via language-support-ka though
<iwj> mdz: You mean Malone 45898 ?
<Ubugtu> Malone bug 45898 in ttf-freefont "2 Georgian letters are confused. You can Notice that from the screenshot." [Normal,Confirmed]  http://launchpad.net/bugs/45898
<mdz> iwj: that sounds like the same issue, but I was referring to the ubuntu-devel thread
<ogra> Kamion, is ship-live really needed ? seems thats the issue for edubuntu live
<Kamion> ogra: did you not see my comment about that to you some days ago?
<ogra> nope
<iwj> mdz: Err.  I don't seem to have that thread here but my feed of ubuntu-devel seems up to date.
<ogra> here ? 
<Kamion> yes
* fabbione takes a break
<Kamion> 11:42 Kamion          ogra: I'm just guessing, but I suspect you might want to
<Kamion>                       drop some bits of ship-live on non-powerpc ;-)
<Kamion>                       ogra: your merges from Ubuntu seeds look weird, btw -
<Kamion> 11:44 Kamion          they never seem to actually show the merged revisions in
<Kamion>                       'bzr log', unlike merges done by other people
* iwj investigates mail.
<Kamion>                       ogra: anyway, I wouldn't have merged ship-live yet except
<Kamion> 11:45 Kamion          that I needed to merge seeds for the kernel ABI change,
<Kamion>                       so sorry if that overflows stuff for you
<ogra> ah
<Kamion> (sorry about the horrible formatting, I'm pasting from the HTML IRC logs)
<ogra> thanks !!
<ogra> i guess the same goes for Riddell then
<Kamion> ogra: ship-live is there so that people installing on systems where the installer can't manage network access can have a chance of later setting it up
<jono> mdke: ok, moved them over to the CSS - do you want me to mail you them?
<Kamion> ogra: I can see that it might perhaps not be appropriate for Edubuntu, but I do not think the same goes for Kubuntu
<ogra> yep, i understand that
<Kamion> Kubuntu is a mass-market system; Edubuntu is not
<Kamion> and many of the things in ship-live are popular in areas where Kubuntu is also popular
<Kamion> (e.g. ISDN)
<ogra> but Riddell was searching for the cause of his oversizedness as well :)
<iwj> Hmm, my last mail from ubuntu-devel-bounces was at 2006-05-22 14:57:38 BST, a bit over an hour ago.
<iwj> But I'm getting other mail from esperanza.
<ogra> thats my prob, i dont want do drop stuff like isdn ... i think i'll hope for the hwdb-client and update-manager pngcrush fixes to hit the archive and hope that gains us enough in size
<iwj> mdz: Doesn't seem to be at https://lists.ubuntu.com/archives/ubuntu-devel/2006-May/thread.html.
<mdke> jono: well i'm not really in charge of this, but if you want me to check it, I can do so
<Riddell> looking at germinate ship-live is < 3MB, kubuntu CDs have jumped more than 10MB since yesterday
<jono> ahhh ok
<jono> is dholbach looking after them ?
<ogra> wow, i only have ~4M to sort it seems
<mdke> jono, i guess so
<mdke> I've never been involved in the book
<mdke> except for the reviewing bit
<mdke> dholbach: the book is going in example-content, right?
<dholbach> mdke: yes
<jono> ok, files sent
<jono> let me know if anything needs poking with a stick :)
<iwj> infinity: mdz has just asked me to look at what appears to be 45898.  Are you happy for me to reassign it to me ?  (I know nothing about Georgian but if I can manage to see the ubuntu-devel thread about it I can probably sort it out.)
<mdke> jono, you need to include the css file with the html, the absolute path won't work when the package that provides that path isn't installed
<mdke> either that, or example-content will have to depend on ubuntu-docs
<jono> mdke: ahhh I see, dholbach, are you ok adjusting the stylesheet path or do you want me to resend?
<mdz> iwj: looks like it was probably held for moderation; I've forwarded it to you
<dholbach> jono: I can do that
<jono> dholbach: thanks
* jono is quite chuffed that he has something in Dapper :)
<iwj> mdz: Oh, right, thanks.
<mdz> jono: received, thanks
<iwj> I'm afraid I don't know how the localisation machinery deals with font preferences.  But if the fonts our Georgian is recommending aren't in ubuntu-desktop then at the very least we should fix the wrong letter !
<iwj> mdz: ^
<mdz> iwj: if you can do that, great
<mdz> Kamion: speaking of the installation guide, its information about disk space requirements was wrong the last time I looked
<iwj> mdz: I'll look into it.
<mdz> ogra: you sent your followups to -devel-announce when they should have gone to -devel
<mdke> jono, just skimming through the chapters, i see you've used links to the wiki for extra information, rather than to the official docs :-(
<mdke> jono: what's the reason for that?
<jono> what official docs?
<jsgotangco> help.ubuntu.com
<ogra> mdz, ctrl-l in evo should use the reply-to ... i resent it manually already and cancelled the post to u-d-a
<jono> is the information from the wiki available elsewhere?
<jono> I didnt think it was
<iwj> mdz: BTW, I'm going to pull out that directory unifier.  I think the cure is worse than the disease.
<mdke> jono: for example for DVDs, http://help.ubuntu.com/6.06/ubuntu/desktopguide/C/video.html#dvdplayback
<Kamion> mdz: if you can point me to the places that are wrong, they'll be easy to fix
<Kamion> it talks about disk requirements in a few places
<Keybuk> ogra: Ctrl-L is explicitly "Reply to List, ignoring From/Sender/Reply-To/etc." :)
<iwj> mdz: In particular, I hadn't realised that packages existed which would make things fail to install later if the directories were unified.
<ogra> Keybuk, meh ... :)
* ogra just thought he found a last minute evo bug :P
<iwj> JOOI, any PPC users here who happen to be reading: does your firefox generally start ?  I'm assuming `yes' because you're not screaming at me to fix it.
<mdz> Kamion: http://archive.ubuntulinux.org/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/ch02s05.html
<Kamion> mdz: ok, will fix that one
<Kamion> I'd missed it because the figures are hidden in an entity
<mdz> iwj: what will the fix look like?
<Kamion> mdz: the memory requirement is correct for d-i so I'll leave that alone
<ogra> iwj, since when should that be broken ? 1.5.dfsg+1.5.0.1-1ubuntu12  runs fine here (but most of my system is one or two weeks outdated)
<mdz> Kamion: it's sort of misleading since it's quite insufficient for the default install
<iwj> mdz: The Georgian fix ?  A new font package, ttf-freefont AFAICT.
<ssam> iwj, firefox is working for me on powerpc
<mdz> iwj: I mean firefox
<mdz> iwj: I'm happy for the wrong glyphs in freefont to be corrected
<iwj> mdz: The `fix' will be just to let the plugin directory confusion continue.
<iwj> As in, to remove completely the new code which attempts to make /usr/lib/mozilla-firefox a link to /usr/lib/firefox.
<Kamion> mdz: I guess; I'll figure something out
<mdz> iwj: ok, and not attempt to clean up after it? good
<iwj> And not to add anything which attempts to un-unify them either.
<iwj> Right.  I want to make it less complex and fragile at this stage.
<mdz> iwj: so long as the flash and java packages in the archive work
<iwj> mdz: I'll check that, but they'll definitely work for upgrades from Breezy.  People like you who had the unifier run from late dapper might still have trouble.
<mdz> iwj: they need to work for fresh installs as well, of course
<iwj> mdz: Indeed.
<iwj> That at least is trivial :-).
* ogra hugs Kamion 
<iwj> mdz: Really, I'm just going to put it back the way it was before I tried to fix it, which has been quite well tested and the consequences are I think understood (some obscure plugins don't work right).
<iwj> Oh dear, this debug build is _still_ compiling.
* iwj goes to investigate fonts instead.
<mvo> Kamion: do you want a patch for 46008? or is the textual description I added enough?
<mvo> bug  46008
<Ubugtu> Malone bug 46008 in ubiquity "clicking on "Set Time..." opens time-admin window behind ubiquity window" [Normal,Unconfirmed]  http://launchpad.net/bugs/46008
<dholbach> mdz: ubuntu-artwork is up (just now) - I update the RADAR
<mdz> dholbach: thanks
<Kamion> mvo: I didn't think it was necessary to fix it for dapper
<Kamion> mvo: do you?
<mdz> mdke: I don't know what the licensing issues are for the book content, but if you and jono can agree on something we should be able to accept an update for corrections
<Kamion> it seems irritating but not fatal
<mvo> Kamion: it depends, the patch should be fairly trivial (one line), so if a new upload is done anyway it might be good to include it. but if not, we should probably just leave it
<heno> mdz: high visibility, sticky keys and screenreader works. the onscreen keyboard fails completely and the magnifier must be loaded manually to work on the live CD 
<heno> everything works on my installed system
<Kamion> mvo: I'm hoping the upload I made earlier today is final, but if not, I think your textual description should be adequate, thanks
<mvo> Kamion: ok, thanks
<jono> mdz: you would need to speak to Debra about the licensing - she has dealt with it all - it is open an open content license though
<heno> as of Thursday's daily live CD
<mdke> mdz: it's not so much that, I submitted these ideas via my feedback questionnaire. I can only assume they were rejected
<mdz> heno: ready for RC, then?  (i.e., nothing we can fix trivially and safely?)
<mdz> mdke: ah
<Kamion> dholbach: how was /rofs showing up in file names in lpi?
<mdz> not much I can do about that, then
<mdz> Kamion: via /proc/*/exe
<Kamion> urgh
<mdz> unionfs bogosity
<mdke> mdz: quite
<pitti> mdz: is archive freeze imminent? seb128 and I are working on a glib and bonobo bug fix ATM
<mdz> pitti: details?
<pitti> mdz: the panel addons crash for non-UTF-8 locales
<pitti> mdz: and menu strings from gnome-panel itself are messed up in non-UTF-8 locales
<mdz> raphink: please read the top of DapperReleaseRadar
<jono> mdke: I dont think your comments were rejected, just overlooked probably
<ogra> heno, while we're at it, nobody answered my question on the a11y list if it was supposed to work in edubuntu
<heno> mdz: The GOK failure has been in Malone for some time. I have no idea why it works on the desktop and not on the Live CD. I email Mithrandir suggesting we remove that option from the Live CD boot
<raphink> mdz: Riddell asked me to edit it to remove the entry for the bug I just uploaded a fix for
<ogra> (i dont even have an idea what to do to test it)
<jono> mdke: its been a pretty schedule for the book so some things got overlooked due to time constraints
<heno> besides GOK is not great ...
<jono> pretty tight schedule, that is
<raphink> mdz: I thought that was meant as a permission
<mdz> raphink: oh, apologies; it looked like you were adding, not removing
<heno> ogra: do you use the same casper settings as ubuntu?
<mdz> raphink: thanks
<raphink> mdz: no I just removed a line :)
<Riddell> raphink: don't remove, mark with [done] 
<Kamion> mdz: d'oh, you reverted my change too
<raphink> Riddell: ah right
* Kamion goes back to try again
<ogra> heno, since i use the same casper package i'd assume so, Mithrandir could tell i think
<raphink> so I should do it again, marking with [done] 
<raphink> sorry for that
<mdz> Kamion: I'm fixing
<heno> ogra: in that case that stuff should work now
<Kamion> ok
<mdz> raphink: please don't; I have several changes pending in my current edit
<heno> ogra: have you tried?
<raphink> argh
<ogra> heno, ok, what do i do to try and what should happen ?
<mdz> fixing dholbach's too
<mdke> jono, right. Well, even so, a single email to the documentation team mailing list would have improved things in terms of what documentation to link to. As for the rest of my questionnaire, naturally I don't expect you to take it into account
<raphink> mdz: sorry I just pressed the button :(
<raphink> mdz: :(
<Kamion> raphink: well you should honour edit locks then
<heno> ogra: press F5 at boot and select an option
<ogra> ok
<mdke> jono, if you want to do an update, feel free to have a look at my questionnaire or mail me
<heno> ogra: with the first one you should get a different theme
<raphink> Kamion: huh? there was no lock when I pressed
<heno> with the third the desktop should speak to you, etc.
<ogra> heno, ok, even though i guess that will be overridden on install by edubuntu-artwork
<mdz> raphink: it only warns you at the top of the page; it is easy to overlook if you aren't watching for it
<raphink> ok
<jono> mdke: I don't have time to, its already in copyedit
<mdz> Kamion: so it's safe to rename my .isos locally so that my next rsync works?
<mdke> jono, yes. oh well.
<jono> mdke: sorry
<Kamion> mdz: yep
<Kamion> due to the "keep previous not-built-this-time CDs around" change requested in cd-build-process I'm having to do some manual work to get rid of the -install- and -live- images
<wasabi> I find it interesting that we use things like gksu.
<wasabi> I didn't think X was any more secure against shatter-style things than windows.
<BenC> wasabi: gksu runs as root...does that keep non-root apps from capturing the input sent to it?
<wasabi> less capture and more subvert.
<wasabi> MS just spent a whole lot of time trying to minimize thigs problem by running things in the user session without elevated privs. I thinkit's interesting that we're sort of going the other way.
<wasabi> Unless X is in some way more secure than I think it is.
<BenC> certain things need those privs, how else would they get it?
<wasabi> In MS's case, they communicate with processes over sepereate mechs to do the work for them.
<wasabi> Mostly they contact services with RPCs.
<wasabi> For instance, the Windows Updater application, sits in the task bar, and doesn't ever run as root. Instead it contacts the Windows Update Service, which does the installs, and reports progress back.
<wasabi> s/root/SYSTEM/
<wasabi> Same with all the control panels.
<BenC> our updater applet never runs as root either
<wasabi> Does when you click on it.
<BenC> it's the updater itself
<dholbach> mdz: ready to upload example-content with those two chapters - right now there's still ~4M of padding to keep this space for the kubuntu chapter outstanding
<wasabi> Yeah... MS's doesn't.
<BenC> the applet doesn't ever, it starts an app that does
<_ion> MS doesn't run the updater as root? :-)
<wasabi> Okay. Well, I'm talking about the app then.
<Kamion> heno: you want pointing devices removed on just the live CD, not install?
<Riddell> dholbach: was that padding in before?
<Kamion> heno: I'll see what I can do ...
<heno> Kamion: just the boot option. It works fine on the installed system
<BenC> wasabi: I agree that the app itself should run as root...but we don't have the mechanisms in place for perm services to handle something like that
<BenC> shouldn't
<dholbach> Riddell: it was added with example-content-12 (we had some other files in there before, which were removed) -- version 12 has the space it's supposed to have on the CD
<dholbach> Riddell: does that answer your question?
<mdz> dholbach: great, thanks
<pitti> carlos: btw, do I still need to run the cronjob that late? last week you asked me to run it at 1600 UTC instead of the usual 1430 UTC
<dholbach> Riddell: we dropped things like the leaflet and introducing-ubuntu, etc
<BenC> I don't like the idea of a constant running service to handle callbacks for something that isn't used a lot
<wasabi> The services spawn as needed.
<heno> Kamion: thanks
<wasabi> Believe dbus can do that just fine.
<Kamion> heno: oh, so I can remove the boot option on both the desktop (live) CD and the alternate install CD?
<BenC> wasabi: No, on windows, the auto-updater runs _all_ the time, as system
<wasabi> Oh yeah, you're right. *it* does, because it updates on a schedule.
<Riddell> dholbach: ah, that could be why the kubuntu CDs have jumped in size then
<wasabi> There are other services similar that only run when requested.
<carlos> pitti: until we move it into production.. yes
<Riddell> I presume edubuntu doesn't carry example content?
<BenC> wasabi: no, it has to run even if you don't do auto-updates
<BenC> else "Update Windows" doesn't work either
<ogra> Riddell, no space, nope :)
<carlos> pitti: in fact... today, it finished at 16:28
<ogra> edubuntu doesnt even carry its own docs since there was no space
<BenC> it's weird that the manual updates require the auto-update service :/
<mgalvin> mvo, dholbach: just so you are aware, i noticed that the update-manager -d stuff displays release notes... i started adding more info to DapperReleaseNotes which might be useful
<carlos> hm, wait, I think that's UTC+1
<wasabi> It's not weird, because they tell the service to do the work for them.
<heno> dholbach: are you taking care of editing the book-toc file to link to the right files and such?
<wasabi> So you can log off in the middle of an update.
<wasabi> And so they don't run on the desktop as SYSTEM.
<dholbach> heno: yes, did that already
<Kamion> heno: do you happen to recall whether access=* does anything on the alternate install CD?
<BenC> wasabi: but you have a service that is constantly running as system for no apparent reason
<Kamion> I can't remember whether I did anything there
<dholbach> heno: nothing fancy though
<BenC> wasabi: atleast in our case we have an app that runs as root only on-demand
<carlos> pitti: so yes, I think is safe to execute it after 15:45 UTC
<wasabi> BenC: Windows Update has a reason. Let me find a better example.
<carlos> but not before that
<heno> Kamion: we were talking about having an option for everything, but decided against
<Kamion> heno: alternate install CD, not live CD
<heno> Kamion: oh, sorry
<wasabi> BITS: Background Intelligent Transfer Service. It is a service which you can submit URLs to and it downloads the files in the background. Supports resuming etc. I think it's ap oor choice for a service, but the point remains.
<Kamion> heno: I'm asking specifically whether we ever implemented it there - I know we implemented it in casper, but that's only desktop (live) CD
<heno> Kamion: I would think not
<wasabi> It is set to Manual by default, and not started. When another program requests a handle to it, it is started on demand.
<Kamion> right, so I can remove it for both and it makes no difference right now anyway
<wasabi> Our "update manager" service could be a dbus service which operated similarily.
<Kamion> that's easier than inventing a conditional
<heno> Kamion: sounds good
<wasabi> You request a handle to it, dbus spawns it on request.
<carlos> pitti: btw,  41644 .po files today vs. 38874 .po files we got with previous export
<wasabi> It runs only while it's needed. Maybe it keeps running in the background applying updates.
<BenC> sort of like esd
<wasabi> Yup.
<heno> the tools get installed with -desktop andcan be activated easily enough
<pitti> carlos: crossing thumbs for today's report; I cleaned the buildd tarball, it should look really good now :)
<wasabi> Logical Disk Manager Administrative Service: another windows serivce.
<wasabi> It runs only when you initialize the API to mess with LVM.
<carlos> pitti: I guess that's a good argument to do a language pack update today
<wasabi> So the UI can contact it and request changes to the configuration.
<pitti> carlos: yes, I planned to do that, if it's fine for mdz
<wasabi> Anyways, there are tons of those.
<Kinnison> Sounds similar to how dbus services activate
<pitti> carlos: can you help me with testing today's Spanish .debs?
<BenC> wasabi: Ok, point taken, so go implement it :)
<carlos> pitti: yes
<carlos> pitti: ETA ?
* Kinnison -> putting washing machine into kitchen, brb
<pitti> carlos: I'd guess 60 to 90 minutes
<wasabi> =) some day I might. I'm just curious if it's a concious decision to not deal with it, or if people don't realize it's a vulnerbility, or maybe X has some magic which makes it not a vulnerbility.
<carlos> pitti: I need to leave in one hour or so
<carlos> pitti: is ok if I check them tonight ?
<pitti> carlos: don't worry, I'll write a broadcast for testing 
<carlos> ok
<Kamion> mdz: any objection to me changing over the ISO volume labels now?
<iwj> mdz: I've just uploaded the fixed ttf-freefont, FYI.  The debdiff is about what you'd expect (although of course the mysterious numbers in the .sfd are impenetrable).
<Keybuk> ok, that's weird; rather than updating the file, rsync just truncated it and started again
<Kinnison> Keybuk: I think it does that if it thinks it stands a chance of being less bandwidth
<iwj> Keybuk: You're looking at strace ?  It might build it in memory.
<mdz> Kamion: none
<mdz> iwj: thanks
<fabbione> BenC: silo works just fine. i think the partitioner hickup made it barfing.
<fabbione> but this is a weakness we need to fix for edgy
<BenC> fabbione: excellent
<fabbione> BenC: tho it's quite strange.. but well
<BenC> maybe the partion map checksum was bad...who knows
<BenC> or maybe it had bad values and conflicted with what silo expected
<pygi> mdz, poke?
<mdz> pygi: yes?
<pygi> do we have a XML-RPC interface on LP?
<mdz> pygi: #launchpad
<ogra> pygi, #launchpad ?`
<pygi> ah,oki
<mdz> Riddell: what's the prognosis for the kubuntu chapter?
<BenC> do the buildd's use ccache?
<Kinnison> Yes
<BenC> good, then this kernel build should go really quickly
<BenC> whoa, things are failing
<Riddell> mdz: jjesse isn't responding
<Riddell> mdke: don't suppose you have a phone number for jjesse?
<BenC> fabbione: That I2C change on sparc caused an ABI change, but since it only affects i2c (and I doubt anything besides the kernel uses it) I am going to do a forced ignore
<BenC> it only affects sparc too
<janimo> Kamion: I'll file a bug for updating the xubuntu gfxboot image ok? the current one has the old colours
<fabbione> BenC: hmmmm
<BenC> amd64 build failure was a missing config option (asked a question during build)
<fabbione> BenC: i suggest you prebuild the kernel, get abi and slam it in the upload
<fabbione> BenC: without forcing the abi ignore
<fabbione> otherwise the first person that builds a custom kernel with sparc.ignore file will not detect the abi change
<BenC> I'll fixup git after the build is done
<BenC> get the abi in
<Kamion> janimo: sure
<BenC> but I need to do this upload now
<Kamion> janimo: /products/ubuntu-cdimage/+filebug
<janimo> Kamion: done
<bddebian> Hey folks, since we are getting down to the wire, anything I can do to help anyone?
<carlos> pitti: did your report script fail ?
<pitti> carlos: it just finished
<fabbione> BenC: the problem is more that the sparc.ignore will exist in the final published source
<pitti> http://people.ubuntu.com/~pitti/langpacks/rosetta-buildd-diff-report.txt
<fabbione> BenC: that's the one that people will use (or should) to build custom kernel
<pitti> carlos: ^ wow, that looks rad!
<carlos> pitti: ooh, right ;-)
<carlos> pitti: ;-)
<carlos> yeah, seems like we still miss some translation domains...
<pitti> carlos: 8 domains, that shouldn't take long to fix any more, I guess?
<carlos> but that's only 8 :-P
<pitti> carlos: po4a might be a bogus one
<carlos> pitti: no, in fact there are some of them that could be removed
<carlos> pitti: yeah
<pitti> carlos: don't worry, the first update packages for dapper will get them
<carlos> I think kio-locate is also wrong, it should be kio_locate
<bluefoxicy> pitti: ping
<pitti> carlos: hm, ubiquity would be nice to have, though
<pitti> hi bluefoxicy 
<carlos> pitti: not really
<carlos> pitti: hmm well, it's for .desktop files
<carlos> pitti: should I approve it?
<ogra> bddebian, fix universe :)
<bddebian> ogra: I have been trying :-)
<pitti> carlos: any reason to not do it?
<carlos> pitti: well, I guess we should take all .desktop translations as using native gettext now... my fault ;-)
<carlos> pitti: btw, discover is being exported
<Kamion> pitti: I keep half-thinking that I'd prefer ubiquity not to be stripped
<carlos> pitti: are you completely sure latest tarball is missing it?
<pitti> carlos: I think po4a is valid, it seems to be translations of the tools themselves, right?
<Kamion> it's not exactly totally outside the domain of language packs like the rest of the installer, but we don't have all the language packs on the live CD
<bluefoxicy> mmm.  You're busy right now, I'll wait.  :)
<pitti> Kamion: I see the point of not doing it, but wouldn't that require to not strip many other domains, too?
<Kamion> pitti: it only applies to the desktop files ...
<pitti> Kamion: since it re-uses other components?
<pitti> Kamion: ah, right
<Kamion> all the other stuff is in debconf and not stripped
<pitti> Kamion: you'll still have the merged translations in the .desktop file
<Kamion> I guess it's a question of whether we think it's valuable to have "Install" translated on the .desktop when nothing else is
<Kamion> I think it may well be, given that we're presenting it as the installer and mailing it out ...
<Kamion> pitti: ?
<pitti> Kamion: I think the question is rather if you plan to release dapper update CDs with updated langpacks
<carlos> pitti: ok ubiquity has been fixed
<Kamion> pitti: oh, you don't strip out the translations from the .desktop files?
<pitti> Kamion: no, I don't
<Kamion> and nautilus will use those?
<pitti> Kamion: yes, as a fallback if the mo file doesn't have translations
<Kamion> pitti: ok, then it doesn't matter and it can keep being stripped, thanks
<carlos> pitti: why are you using kio-locate instead of kio_locate ?
<pitti> carlos: I don't, I guess it's a bug in some kde-i18n file
<carlos> pitti: ok, could you confirm me that you don't have 'discover' translations from Rosetta?
<carlos> pitti: you should have 
<pitti> not so fast, please
<pkern> Hi, does http://ftp-master.debian.org/rene-daily.txt work in your Gecko browser of choice? Both Firefox and Epiphany keep crashing X here on current Dapper.
<Kamion> ogra: so, re bug 38088, do you mind the server (minimal install) option disappearing entirely, and not being able to select it in any way?
<Ubugtu> Malone bug 38088 in ubuntu-cdimage "edubuntu install menu should either hide "server" or have this option renamed to "minimal"" [Normal,Unconfirmed]  http://launchpad.net/bugs/38088
<pitti> carlos: so, kio-locate is from the kio-locate source package, and the domain is indeed kio-locate, not kio_locate
<ogra> Kamion, nope
<carlos> pitti: really? the .pot file is named kio_locate.pot
<ogra> either of the options i listed in the bug is fine 
<pitti> carlos: the pot file is named kio_locate.pot, but the mo files are ./kio-locate/usr/share/locale/fr/LC_MESSAGES/kio-locate.mo and so on
<Kamion> unfortunately I left it too late to rename it
<carlos> pitti: I see... weird
<bluefoxicy> wow... looks like someone is smoking .pot o.o
<Kamion> ogra: you said "hide it from the gfxboot menu"; it's possible (but harder) to hide it from the gfxboot menu but still leave it selectable in text mode, or for other arches
<Riddell> pitti, carlos: do you know what the status of k3b.po is?  I'm getting complains it isn't included
* ogra *sighs* but is happy this failed install was only bad media
<Kamion> i.e. by typing "server"
<ogra> Kamion, as long as it doesnt apper its fine ... either way
<carlos> Riddell: it needs a rebuild with your patch to set the encoding to UTF-8
<carlos> Riddell: I thought I already notify you... I guess next time, I should use mail... sorry
<ogra> if people want a server install they can use ubuntu-server or fiddle with expert mode
<Kamion> ogra: nobody ever tries to do a base-system-only install with an Edubuntu CD, then?
<ogra> if he does, i'll point him to the expert mode ;)
<Kamion> ogra: you could, but that would be pointless and a misunderstanding of expert mode
<pitti> carlos: discover> unpacking rosetta tarball right now and checking
<Kamion> are you aware of what expert mode does?
<pitti> carlos: so, tuxpaint-stamps just came too late for today's tarball IIRC?
<carlos> pitti: yeah, po4a seems to be correct, I will fix it
<ogra> Kamion, its a while ago that i used it in debian, but cant you select the packages for installation (iirc) ?
<pitti> carlos: you'll fix kio-locate, too?
<carlos> pitti: yes, it came too late, it's already imported will appear tomorrow
<carlos> pitti: it's already fixed
<pitti> carlos: confirmed, no file 'discover*' in rosetta tarball
<carlos> pitti: from where does thunar-media-tags-plugin come?
<Kamion> ogra: in Debian, yes, but it has never done that in Ubuntu
<ogra> oh, k
<pitti> carlos: from the very same source
<pitti> carlos: likewise for xfce4-mount-plugin and xfburn
<Kinnison> pitti: Can you look at 44055 and tell me if the suggestion Richard has made is likely to be safe for Ubuntu?
<Kamion> anyway, I'll remove the option; you can add 'preseed/file=/cdrom/preseed/server.seed' to the kernel command line to get a base-system-only installation
<pitti> bug 44055
<Ubugtu> Malone bug 44055 in gnome-power-manager "brightness changes rapidly up/down" [Normal,Confirmed]  http://launchpad.net/bugs/44055
<ogra> Kamion, well, then i'll live with what your time permits ... if you have time left to make it work with typing server, fine, if not, fine as well, put it on the bottom of your todo ;)
<carlos> pitti: ok. I don't understand the 'discover' issue, all things are in place...
<mdz> pitti: I've seen that bug
<dholbach> ubiquity install on a USB drive is a bit hard. the partitioning part is not happy if the drives are mounted (which I can understand), people have to unmount them before installation, which was easy enough for me to do, but for some reason they got mounted again between the partitioning (gparted) step and the real parititioning
<pitti> Kinnison: the hal side would be to add an .fdi file? do you have a direct pointer to that file?
<pitti> carlos: the funny thing is that mapping.txt mentions discover :)
<carlos> pitti: I need to debug that... that package has been there for a long time already...
<pitti> carlos: hm, wait
<pitti> carlos: the correct domain name is 'discover1', but in your mapping.txt, the domain name is 'discover'
<pitti> carlos: bah, scratch that, I lied
<Kinnison> pitti: Unfortunately not, I imagine it'll take a quick grobbling around in hal CVS would find it
<pkern> Somebody here to try an URL on Dapper current w/ Gnome, with the ability to trace an X crash?
<pitti> carlos: the *source* package is discover1, not the domain
<pitti> carlos: 'discover' is an universe package we don't use
<pitti> Kinnison: right
<carlos> pitti: oh
<pitti> Kinnison: generally, fdi files are safe if they are specific enough
<Keybuk> I thought we still used discover for X server?
<pitti> Kinnison: i. e. test properties for specific values like product names and such
<pitti> Keybuk: discover1 maybe?
* mvo_ is about for a bit
<pitti>  discover1 | 1.7.15ubuntu1 | http://archive.ubuntu.com dapper/main Packages
<pitti>   discover | 2.0.7-2.1ubuntu1 | http://archive.ubuntu.com dapper/universe Packages
<Keybuk> ah, of course
<Keybuk> that one always confuses me
<pitti> Kinnison: found it
<pitti> Kinnison: http://lists.freedesktop.org/archives/hal/attachments/20060514/7915a91d/hal-x31-laptop-0001.bin
<carlos> pitti: would be possible that the xfc packages were uploaded using universe and then promoted to main ?
<pitti> Kinnison: (that's a .patch, just badly renamed by mailman)
<carlos> pitti: they have the .pot file and thus, they should be imported...
<pitti> Kinnison: that looks quite safe
<carlos> pitti: anyway, I will fix them by hand
<pitti> carlos: indeed, very likely
<pitti> carlos: wait
<carlos> pitti: I mean, no upload directly to main
<pitti> carlos: we need to reupload them anyway to get them stripped
<pitti> janimo: ping
<janimo> pitti: pong
<janimo> do I need to reupload xfburn?
<pitti> janimo: can you please do no-change uploads for xfburn, xfce4-mount-plugin, and thunar-media-tags-plugin?
<pitti> janimo: and possibly other packages which were recently promoted without rebuilding?
<carlos> pitti: I think those are the only ones we are missing
<pitti> carlos: this is a nice way to catch promoted packages that need rebuilding :)
<janimo> pitti, for xubuntu-system-tools I set the GETTEXT_DOMAIN gnome-system-tools is that ok?
<carlos> pitti: that leaves po4a and discover as the only ones that need a manual fix
<carlos> pitti: ;-)
<pitti> janimo: yes, unless you changed any string
<janimo> pitti, I did not
<carlos> pitti: the others are alredy fixed
<janimo> ditto for evince-gtk
<pitti> carlos: anything you need me to do for the remaining issues?
<Kamion> mdz: hmm, do we still have room to add build-essential/linux-headers to ship-live?
<pitti> Kinnison: do you want me to apply that patch?
<Kamion> mdz: I'd only added the network access stuff to date
<ogra> ARGH !!!
* ogra throws away the third new DVDRW media ...
<ogra> grmbl
<janimo> pitti, so at this point adding new .po files is not ok right?
<carlos> pitti: no, thank you very much
<carlos> I can fix those two
<janimo> pitti, if dapper translations are to continue after release will we still be able to import upstream .po files?
<dholbach> did anybody else have a md5sum problem (restricted-nic-something-di) with the daily powerpc install iso?
<mdz> Kamion: we seem to; it's a tradeoff vs. langpacks though
<mdz> how much does it cost us again?
<Kamion> just noticed I still had bug 44313 open
<Kamion> IIRC it was c. 24MB
<jdub> mdz: do we have a policy about what constitutes 'desktop' and 'server' for the LTS periods?
<pitti> lol, that question sounds familiar to me :)
<mdz> jdub: for security purposes, it's germinate output
<mdz> jdub: for technical support, that's a jeff bailey question
<jdub> mdz: but supported includes server and desktop stuff
<mdz_> ok, that was weird
<jdub> btw, i thought we were going to fix the libpam-ldap/libnss-ldap in universe problem - but they're still there atm
<Ubugtu> Malone bug 44313 in ubuntu-cdimage "build-essential not on Dapper Flight7 ISO" [Major,Confirmed]  http://launchpad.net/bugs/44313
<Kamion> 18:11 < jdub> mdz: but supported includes server and desktop stuff
<Keybuk> jdub: bug# for the problem?
<Riddell> carlos: in k3b changelog "Alter debian/rules to mark .po files as UTF-8" a month ago, are the files still not valid?
<jdub> Keybuk: the 'bug' is that they're in universe
* dholbach assumes a broken CD
<jdub> Keybuk: it was being discussed months ago, i hadn't thought about it
<carlos> Riddel: hmmm, let me check...
* bddebian hugs dholbach
<ogra> jdub, i can tell you that ltsp is not a 5year supported server since it relies on desktop stuff :) thats all i could find out yet 
<Keybuk> jdub: discussed with whom?
<dholbach> hey bddebian
<jdub> Keybuk: it was being discussed here and on the lists, from memory
<mdke> Riddell: fraid not, but he's online afaik
<Riddell> he's not responding
<_ion> Sigh. /me is trying to fix bug #41148, but the source seems to be full of undocumented lists of magic numbers that mysteriously make things work.
<Ubugtu> Malone bug 41148 in xserver-xorg-driver-savage "buggy display of video in totem" [Normal,Unconfirmed]  http://launchpad.net/bugs/41148
<Keybuk> jdub: I see no discussion on here in over a year
<Keybuk> the only mention, in fact, was you asking mdz and being told what the procedure was
<Keybuk> and that was January 2005
<mdke> jdub: did you see either of my emails about planet? would really appreciate you making the change for my blog
<jdub> mdke: been travelling, will get around to it
<Kamion> iwj: speaking of seeds, shouldn't autopkgtest be added to supported?
<mdke> jdub: thanks.
<carlos> Riddell: http://librarian.launchpad.net/2731657/buildlog_ubuntu-dapper-i386.k3b_0.12.14-0ubuntu6_FULLYBUILT.txt.gz
<carlos> Riddell: the .pot file is not being regenerated
<Keybuk> jdub: for main inclusion (for edgy) you need to prepare a MainInclusionReport for them, and then get a developer (usually pitti) to security review the packages and check them for general supportability
<Keybuk> once approved, they need to be seeded somewhere appropriate (supported)
<carlos> Riddell: and thus, we are not getting the updated .pot files
<jdub> Keybuk: i know what the procedure is
<jdub> Keybuk: it's not a itch of mine, but i'm pretty gobsmacked it wasn't thought about or done for dapper
<Keybuk> jdub: it's clearly not an itch of anybody's
<Kamion> we apologise for the distro team being insufficiently omniscient
<jdub> oh, guys, come on
<jdub> don't be tools
<Kamion> dude, lots of other stuff has got into main, and that's because the people who cared pushed for it
<Kamion> if nobody who cares pushes for it ...
<Keybuk> hell, you don't even have to push that hard, it's more of a gentle prod
<jdub> Kamion: thus i am surprised, both because other people didn't care about it and we didn't care about it
<mdz_> Kamion: these new isos are a new build, right, not just renamed?
<Kamion> how many of the distro team do you think have time to run large corporate environments that authenticate off LDAP servers? :-)
<Keybuk> mdz_: rsync thinks so, yes
<Kamion> mdz_: yes
<Kamion> I just wanted to get the rename admin out of the way
<Riddell> carlos: how do you know it's not?  extract-messages is bring run in that buildlog
<jdub> Kamion: it's kind of a use case i had imagined we'd care about for dapper
<iwj> Kamion: oh, I knew there was something I'd forgotten.  Unfortunately I have to go now or I'll miss dinner.
<Keybuk> jdong: the network-authentication spec, which I imagine this falls under, was deferred to dapper+n
<Kamion> https://wiki.ubuntu.com/MainInclusionReportLibnss-ldap actually does exist
* iwj puts it on the todo list for tomorrow.
<Kamion> iwj: should I do it now?
<iwj> If you're there anyway, yes, please.
<carlos> Riddell: well, we didn't get any tarball for k3b since last year at people.ubuntu.com/~lamont/translations
<Keybuk> uh, jdub
<bluefoxicy> pitti:  still busy?
<Kamion> iwj: doing
<carlos> Riddell: pkgstriptranslations: processing control file: ./debian/k3b/DEBIAN/control, package k3b, directory ./debian/k3b
<carlos> pkgstriptranslations: k3b does not contain translations, skipping
<carlos> pkgstriptranslations: processing control file: ./debian/libk3b-dev/DEBIAN/control, package libk3b-dev, directory ./debian/libk3b-dev
<carlos> pkgstriptranslations: libk3b-dev does not contain translations, skipping
<jdub> Keybuk: (sure, but they're pretty critical beyond that larger spec)
<Keybuk> jdub: if they were critical, I'm sure somebody would have noticed in the last 8 months
<iwj> Kamion: Thanks.
* Keybuk tends to assume things aren't that critical if they go unnoticed
<jdub> Keybuk: again, this is why i'm surprised (and not attacking the distro team, thank you very much)
<Kamion> so the right answer would be to set the train in motion while you all remember now :)
<bddebian> heh
<carlos> Riddell: and the k3b_0.12.14-0ubuntu6_i386.changes file lacks the translations tarball
<Keybuk> jdub: except for calling us tools, you mean? :)
<jdub> Keybuk: when you're reacting as if i'm attacking you, absolutely
<Riddell> carlos: so the .pot is in rosetta?
<carlos> Riddell: the old version faild, the new version was not even exported to be imported into Rosetta...
<dholbach> either I'm imagining things (which I hope for the first time in my life), or I was too stupid to use gparted-in-ubiquity properly or my 150 GB of data just vanished like that
<kikidonk> I'm getting a segfault with liferea+mozilla: http://en.pastebin.ca/58060
<Kamion> jdub: I'm afraid that "how come we haven't fixed this thing we talked about ages ago" does come across a little like saying that the distro team dropped the ball
<Riddell> carlos: is pkgstriptranslations for .po files or .pot files?
<carlos> pitti: ^^^
<carlos> Riddell: I saw other packages that only had a .pot file and no .po files working
<carlos> Riddell: for instance, kdebase
<carlos> so it should work...
<carlos> pitti: po4a and discover are fixed now (well, waiting for the import queue that it's a bit busy atm...)
<jdub> Kamion: hardly something i can claim we-ship with
<pitti> carlos: it puts both into the tarballs, but it just removes .mo files
<janimo> dholbach: auch
<pitti> Riddell: ^
<Riddell> pitti: so pkgstriptranslations isn't finding any .pot files?  
<carlos> pitti: the problem is that k3b's .pot files are not being extracted
<pitti> Riddell: for which package?
<Riddell> the buildlog seems to suggest they're being generated
<pitti> ah
* pitti checks
<Riddell> pitti: k3b
<dholbach> Ok, I have a problem - 70 GB of data just went AWOL because of mis-partition
<dholbach> I'm out for a cigarette
<pitti> Riddell, carlos: hm, the k3b tarball has all POTs, and k3b-i18n tarball has all po files
<Riddell> that's right
<mdz> BenC: what went wrong with the kernel build?
* pitti hugs dholbach and hopes he had a backup
<mdz> dholbach: when you come back, try gpart
<carlos> pitti: but the build log shows that we are not generating the translations tarball
<pitti> Riddell: erm, wait - we didn't get a new tarball for *ages*
<pitti> Riddell: the last tarball we got: ./20051207/k3b_0.12.8-1ubuntu1_i386_translations.tar.gz
<Keybuk> Kamion: is there a magic script that would show up sources without any binaries in the archive?
<dholbach> mdz: does that help, if the installation happened after that?
<dholbach> pitti: of course not
<mdz> dholbach: depends on the circumstances
<Riddell> pitti: where do those tars appear from?
<dholbach> oh a tiny shimmer of hope then *phew*
<carlos> Riddell: from the build
<dholbach> thanks mdz
<Keybuk> Kamion: would it show up in outdate.txt, as the binary version is newer than the source (where the binary is now built by a different source)
<pitti> Riddell: http://librarian.launchpad.net/2731657/buildlog_ubuntu-dapper-i386.k3b_0.12.14-0ubuntu6_FULLYBUILT.txt.gz
<Riddell> carlos, pitti: seems to me like pkgstriptranslations is broken then
<carlos> pitti, Riddell: I need to leave now, please, mail me if you need anything from me....
<pitti> Riddell: that means that there are no files worth extracting, so pkgstriptranslations doesn't create a tarball
<carlos> Riddell: are you 100% sure the .pot file is being generated?
<Keybuk> http://people.ubuntu.com/~cjwatson/anastacia.txt
<Keybuk> ^ Woohoo!
<Riddell> carlos: I'm 99% sure
<pitti> Riddell: there is no sign of intltool invocation at all
<carlos> pitti: k3b is not using intltool...
<carlos> intltool is used with GNOME packages k3b is KDE ;-)
<Riddell> pitti: build log includes the magic line XGETTEXT=/usr/bin/kde-xgettext sh admin/cvs.sh extract-messages
<pitti> well, it uses intltool package at least
<Riddell> and that would complain if it was broken
<pitti> Riddell: aaaaah
<pitti> Riddell: it extracts the POT files as the very, *very* last step
<pitti> Riddell: but it has to do that before dpkg-deb invocation
<yuriy> looking at michael's comment in bug #41767, are bugs no longer being fixed for dapper? even a (albeit minor) segfault?
<Ubugtu> Malone bug 41767 in aptitude "aptitude changelog <package without candidates> segfaults." [Normal,Confirmed]  http://launchpad.net/bugs/41767
* carlos -> out
<carlos> see you
<zyga> hey pitti, carlos :)
<pitti> hi zyga 
<carlos> pitti: Thanks for your input in language packs!
<carlos> zyga: hi
<pitti> carlos: thanks to you too for the great progress :)
<Riddell> pitti: oh, how confusing
<Riddell> pitti: well, should be easy enough to fix
<dholbach> ok, using gpart froze that box
<mdz> Kamion: hmm, at least dapper-desktop-i386 doesn't seem to have any of the new versions of stuff fixed on DRR
<mdz> oh, no new livefs builds I suppose
* fabbione calls it a day
<mdz> fabbione: night
<fabbione> later
<fabbione> actually i mean shower -> dinner
<fabbione> but i might pass by later
<fabbione> mdz: phone is on if the world falls down
<fabbione> mdz: both mobile and land line
<pitti> @all: can you please dist-upgrade to "deb http://people.ubuntu.com/~pitti/langpacks/daily/ ./", restart your session, and tell me about any oddities you see?
<pitti> Riddell: can you please update to latest daily langpacks and particularly check KDE? the desktop files, flags, etc. should be up to date now
<Riddell> pitti: doing
<mdz> Kamion,Mithrandir: can someone kick off new livefs builds?
* Riddell pokes i386 buildds into compiling kdebase
<mdz> Riddell: chewing on oo.o right now
<Riddell> what does "NOT OK : Manual OpenOffice Builds... Patience." mean?
<pitti> Riddell: new packs working well for me
<Keybuk> mdz: there's a whole bunch of ubuntu-meta changes (language packs, mostly), should I upload?
<pitti> Keybuk: argh, I forgot that live CDs need an updated metapackage, too
<pitti> Keybuk: would be nice to get for the next CDs, to verify that my langpack stuffing was correct (and to check whether today's package changes changed the CD size significantly)
<Riddell> pitti: happens to us all
<Keybuk> pitti: looks like both ogra and dholbach forgot about ubuntu-meta too
<Riddell> pitti: french and georgian kde langauge-packs looks good here
<ogra> Keybuk, ?
<Keybuk>   * Added screensaver-default-images to desktop-i386, desktop-amd64,
<Keybuk>     desktop-powerpc, desktop-ia64, desktop-sparc, desktop-hppa
<ogra> err, but not in edubuntu i hope
<ogra> else i know whose fault it is that i seasrch for the 4M oversizedness of my live CD :P
<ogra> Keybuk, and i also thought you added them to supported ... they shouldnt end up on the CD
<kagou> smurf, always not around ? ;)
<Keybuk> ogra: that would appear to negate the term "default"
<mdz> Keybuk: langpack changes are expected
<ogra> Keybuk, as long as they dont show up in edubuntu i'm fine 
<mdz> Keybuk: screensaver-default-images is something which should have landed a long time ago; I'm not entirely comfortable with that
<ogra> i'm fighting around single bits and *bytes* here
<ogra> it should have gone to supported 
<mdz> that's not what the spec says
<Keybuk> ogra: if supported, then it should be called "screensaver-images", not "default"
<bluefoxicy> ogra:  edubuntu too big?
<LaserJock> bluefoxicy: no, the CD is too small :-)
<pitti> mdz: new langpacks ready for upload; is now a good time, or shall I wait?
<mdz> pitti: now is fine
<bluefoxicy> LaserJock:  lol!
<bluefoxicy> LaserJock:  Don't get media happy.  Nobody wants to download a DVD if a CD will do.  :)
<bluefoxicy> {BANDWIDTH}
<LaserJock> that's what uni lines are for :-)
<dholbach> is there anything else important apart from /var/log/installer/ I should save from that mispartitioned installation?
<bluefoxicy> LaserJock: they could always base on top of Xubuntu though... the CD for that is under 400 megs.  Then again, the software is a mix and match of KDE and Gnome software, which means KDE and GNOME platform libraries as well as GTK+ and Qt ne?
<ogra> Keybuk	ogra: are you intending to seed this in main?
<ogra> 	ogra	Keybuk, yep, its small, we can put it at least into supported
<bluefoxicy> I guess it can't be helped.
<ogra> Keybuk ^^^
<mdz> does anyone know the current list of hosts which do the livefs builds?  I should be able to trigger them, but for that that has changed (I think)
<ogra> thast from thursday 
<Kamion> Keybuk: it's the sort of thing you'd hope archive-cruft-check would do, but it doesn't at the moment. outdate.txt should I guess ...
<Kamion> Keybuk: anastacia> nice one!
<Kamion> mdz: correct, I didn't do livefs rebuilds
<janimo> mdz, UVF exception. xarchiver new upstream version fixes one of the bugs I labeled major, bug 45856
<Ubugtu> Malone bug 45856 in xarchiver "xarchiver close while opening *.tar.bz2" [Major,Confirmed]  http://launchpad.net/bugs/45856
<janimo> mdz, can either upload it myself or sync it from debian as they have it too now
<mdz> janimo: your call; it's your funeral if it has regressions ;-)
* janimo shudders but goes ahead
<Keybuk> janimo: didn't we only just sync that?!
<janimo> Keybuk, xarchive vs xarchiver :)
<mdz> janimo: I'd recommend backporting the fix instead unless it's a very small delta
<janimo> not very imaginative
<Keybuk> oh, right
<Kamion> mdz: I have a script that does it, will kick them off now if it's a good time
<janimo> mdz, the whole change is that bug + 3 new .po files
<Kamion> mdz: I thought I mailed you the script not that long ago
<janimo> mdz if you wish I just apply the patch
<mdz> Kamion: I had a script of my own that I thought i sent you
<mdz> Kamion: in any case, please send
<mdz> janimo: if it's only that patch + translations, new upstream is fine
<janimo> mdz, ok thanks
<Kamion> mdz: http://riva.ucam.org/svn/cjwatson/bin/ubuntu-build-livecd
<mdz> Kamion: mine is a bit fancier, but the list of servers is rusty
<Kamion> yeah, I suspect I never got around to merging it
<Kamion> I've started an Ubuntu livefs build
<mdz> it's python, captures the output from the script (though there is none) and times the builds
<mdz> nothing too compelling
<mdz> thanks
<Kamion> mine prints the dates, so I can work out the times easily :)
<Kamion> though not as cute
<yuriy> looking at michael's comment in bug #41767, are bugs no longer being fixed for dapper? even a (albeit minor) segfault? anybody?
<Ubugtu> Malone bug 41767 in aptitude "aptitude changelog <package without candidates> segfaults." [Normal,Confirmed]  http://launchpad.net/bugs/41767
* yuriy would find that hard to believe
<mdz> we should keep that list of servers in the wiki somewhere
<Keybuk> yuriy: only showstoppers
<Keybuk> minor bugs can get on the edgy bus
<mdz> yuriy: we are in the final stages of release preparation
<Kamion> mdz: I'll start a list somewhere
<yuriy> k thanks
<mdz> yuriy: and yes, that means that we're being selective about which bugs to fix
<mdz> yuriy: that one is quite minor
<yuriy> what happened to the "target to release" in launchpad? is that coming back? would be convenient for stuff like that
<yuriy> i only see "backport fix to releases"
<Kamion> yuriy: we use milestones for that instead now
<Kamion> target to release was badly designed so it went away
<mdz> Kamion: but it's destined to come back
<Kamion> oh, it is? bogosity ;-)
<Kamion> presumably it will set milestones rather than creating extra bug tasks
<Kamion> mdz: https://wiki.ubuntu.com/BuildDaemons/LiveFilesystems
<mdz> I wish
<pitti> so, can we still upload bug fixes which are simple and safe (like http://librarian.launchpad.net/2765349/fix_eintr_crash.patch), but aren't really showstoppers?
<mdz> Kamion: thanks
<Kamion> infinity: could you make sure to update the above if it ever changes?
<mdz> pitti: yes, that one is ok
<mdz> Kamion: would be handy to include your script there as well
<Kamion> mdz: done; I'll try to remember to merge it with yours at some point
<mdz> Kamion: not worth it, I'd say
<yuriy> how do milestones work? (I don't see it, sorry for the noise)
<Kamion> yuriy: click on the bug task and it's in the drop-down menu
<Kamion> yuriy: but there is no milestone for edgy yet, if that's your intention
<mdz> Kamion: the only interesting difference is that mine allowed multiple arguments (flavours) to be passed at once
<Kamion> it will be created along with the edgy development branch
<mdz> it doesn't do the architecture magic that yours does, either
<Kamion> mdz: that would be kinda handy actually
<Kamion> the architecture magic is very useful to avoid wasting time
<mdz> Kamion: I think there's a bug where you can only see the milestone if you have privileges to change it
<mdz> which in a sort of accidental way is useful
<mdz> gar, I thought we disabled gimp's obnoxious first-run wizard?
<Keybuk> mdz: nobody expects the first-run wizard!
<mdz> it's especially obnoxious for example-content
<ogra> yay
<ogra> finally after the 7th media i have a working install CD :)
<mvo> mdz: I can have a look if you want and patch it out (again)
<_ion> ogra: Why not use CD-RWs for testing?
<highvoltage> ogra: whohoo!
<ogra> and i386 install even worked :)
* mvo has very good experience with verbatim cdrw
<highvoltage> _ion: or even vmware ;)
<ogra> _ion, i use DVD+RWs with a very picky DVD ROM
<ogra> _ion, it only takes "intenso" media apparently and not all of a 10er pack
<sivang> Kamion: just to let you know I've tested with breezy powerpc, still does not boot on the pSeires. 
<ogra> highvoltage, i leave the easy parts (vmware) to the community ;) i like testing with real HW
<mdz> mvo: how complex was the original patch?
<mdz> sivang: breezy?
<Kamion> sivang: ok, at least it's not a regression
<Kamion> mdz: I asked him to
<mvo> mdz: IIRC it was not very big and pretty straight-forward
<sivang> mdz: yes
<highvoltage> ogra: heh
<ogra> mvo, my acer laptop only eats intenso ... i tried verbatim
<mdz> ok, I was confused by the 'still'
<mdz> if breezy didn't boot there when it was released, it doesn't now either ;-)
<Kamion> 'still' with respect to the dapper tests sivang was doing the other day, I think
<ogra> (saldy this lappie is my amd64 *and* i386 testmachine)
<sivang> mdz: yes, withrespect to testing with the -stripped and some other 2 images
<poimen> hi
<poimen> :)
<poimen> just updated my dapper
<poimen> :) does the code have been freezed?
<ogra> nearly
<mdz> Kamion: about how long do the livefs builds take these days?
<poimen> because it have been removed the beta name on the gnome splash
<poimen> using ubuntu with xgl and It seems stable to me :) xgl have some problems but there are minor with gnome
<poimen> :)
<poimen> in kubuntu by the other hand xgl does not work too good as in suse 10.1 on KDE
<mdz> poimen: https://wiki.ubuntu.com/DapperReleaseSchedule
<Kamion> mdz: 20min for i386, 30-35min for amd64/powerpc/sparc, 40min for hppa, ia64 dunno yet
<mdz> oh, so irelease arches should be done now
<Kamion> mdz: yes
<mdz> Kamion: ok to kick off cron.daily-live?
<poimen> so the last rc beta or alpha will be realesed today :D
<mdz> pitti: did you see this comment in 31775?  are those translations still missing from the latest langpack export?
<mdz> poimen: no
<pitti> bug 31775
<Ubugtu> Malone bug 31775 in Ubuntu Dapper "Ubuntu should have better links to support options" [Normal,Fix released]  http://launchpad.net/bugs/31775
<pitti> mdz: ah, we discussed that this morning; we tried to find the reason why the i386 build didn't update the pot, and seb uploaded another package
<mdz> pitti: so your pending upload will fix it?
<pitti> mdz: last time I checked the package wasn't yet build, lemme check again now...
<ogra> Riddell, why did you remove brtty-x11 ?
<Riddell> ogra: it's a gnome application
<ogra> oh
* ogra didnt know 
<ogra> the name doesnt really indicate its gnome *shrug*
<Kamion> mdz: yes
<Riddell> ogra: build deps on gtk etc etc
<Riddell> install deps too
<ogra> Riddell, yep
<ogra> i was hoping to get a valid reason to not do that meta upload :)
<Kamion> urgh, we never got round to revisiting bug 31661
<Ubugtu> Malone bug 31661 in kbd-chooser "ignores preseeding" [Normal,Confirmed]  http://launchpad.net/bugs/31661
* Kamion investigates
<ogra> since brtty-x11 is the only addition
<mdz> (live build in progress)
<mdz> Kamion: the 404s in the cd build log are normal?
<pitti> mdz: so, the new package's build on i386 still has an outdated pot file, althought he build log clearly says that it was regenerated; I have no idea about that ATM
<pitti> mdz: as for carlos' manual fix, I don't know whether the file made it into today's tarball, checking now...
<Kamion> mdz: they're for old .cloop images, and we try both .cloop and .squashfs; yes, they're normal
<Kamion> mdz: bug 31661 is still an issue; can I put it on DapperReleaseRadar and investigate?
<Ubugtu> Malone bug 31661 in kbd-chooser "ignores preseeding" [Normal,Confirmed]  http://launchpad.net/bugs/31661
<Kamion> it is going to piss off people doing automatic deployments something rotten
<mdz> pitti: it is gnome-panel in question, right?
<pitti> mdz: right
<omeg> Does anyone know when the Edubuntu and Xubuntu usplash screens will be packaged?
<mdz> Kamion: ok
<ogra> omeg, after the vote, i have your "not completely polished" version in edubuntu currently
<Kamion> thanks
<pitti> mdz: if there are translations for these new strings, then they didn't make it into today's tarball, so that's something we need to translate post-release (the pot file has been fixed ~ 10 hours ago only)
<Kamion> pitti: want to mark your final langpack changes [done]  in DapperReleaseRadar, if that's true?
<ogra> but given that i just discovered a bug in the edubuntu firefox css (which indeed only appears in such rarely used languages like english) i'll have to upload another -artwork package anyway it seems, where is your latest version ?
<pitti> Kamion: I hope these are the final ones :) Yeah, I'll do that
<dAndy> Kamion: did you see my report about ftp kickstart install not working?
<Kamion> dAndy: no
<Kamion> dAndy: was it in the bug tracking system?
<dAndy> Kamion: i pinged you on here, havent had a chance to file a bug yet
<dAndy> i will file one
<Kamion> dAndy: please don't do that unless I'm actively around - I'll miss it
<Kamion> I was away Friday and all weekend
<dAndy> Kamion: i see, i intended on filing a bug too, just didnt get to it
<ogra> omeg, ^^^ ?
<omeg> Hi ogra
<omeg> Oh, didn't see your message
<ogra> :)
<omeg> There was a vote on that?
<omeg> I didn't even realize. Well, cool. :)
<ogra> there is a vote on that by the artteam
<omeg> I thought that was only for Ubuntu?
<ogra> i thought you're subscribed to the list
<omeg> I follow the ubuntu-art list but I guess I must have missed that message.
<ogra> as i wrote in that thread, edubuntu will follow
<ogra> for consistency reasons
<mdz> pitti,seb128: I just did a build of gnome-panel and the .pot file doesn't have the Ubuntu Book Excerpt string in it
<omeg> Ah, okay. Will Xubuntu also get packaged at around this time, or is it not following the same release date?
<ogra> omeg, tsk, i even praised you in my mail :) you shouldnt miss such mails ;)
<omeg> Haha, I'll go find that right away. I wanna read that now.
<ogra> its following the same dates afaik
<ogra> omeg, janimo can tell you
<ogra> omeg, so is there a final version of the edubuntu one ? i have to fix a bug anyway in the artwork package and could even add that then
<omeg> Strange. I really don't seem to have that one mail.
<dAndy> Kamion: Bug #46052 sorry about that
<Ubugtu> Malone bug 46052 in debian-installer "FTP Support in Kickstart Stops working part way through the install" [Normal,Unconfirmed]  http://launchpad.net/bugs/46052
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_newsuggestion_0_8_TEST.png <-- this is my latest (it says "test", but I fixed the palette.)
<omeg> Let's see...
<janimo> omeg, yes same dates for xubuntu
<omeg> Yeah, I'd say that this is final.
<ogra> omeg, https://lists.ubuntu.com/archives/ubuntu-art/2006-May/001612.html
<ogra> yep, looks ok
<omeg> Ahh. Cool. :)
<dAndy> Kamion: it should be noted, this was primarily testing the ftp support, it is not critical for my deployment
<omeg> I guess I will go fix the palette of Xubuntu.
<ogra> i'll add that one (its the same as ubuntu designwise, right ? )
<mdz> Kamion: happily, the new iso filenames cause rsync's sorting to do what I want (give me desktop first)
<omeg> Yeah: http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_SCALED.png
<omeg> I hope the color scheme is okay.
<_ion> I did some more testing. The Xv overlay code in the savage driver is totally broken. The image gets damaged when 1) _either_ the horizontal or the vertical size of the overlay is smaller than the size of the original picture or 2) the overlay is partially outside the visible screen area.
<omeg> I don't really know much about Xubuntu.
<Kamion> mdz: heh, nice side-effect
<janimo> omeg, does the xubunt splash need changing?
<omeg> janimo: just the palette that isn't in the correct order yet.
<janimo> omeg, ok
<Kamion> dAndy: can you dump your /etc/apt/sources.list into the bug?
<Kamion> from that install
<omeg> Man, after 6.06 is released, and I finish all this work that I've been putting off a little, I'll make a wikipage about user interface things from here to tokyo. I kinda like working on this. I only recently started doing it but I think it's neat to be working on a project as big and interesting as this.
<omeg> Plus, it's good portfolio material...
<dAndy> Kamion: sure
<Kamion> the spacing in that error message is odd and suggests badness
<Kamion> "Unable to connect to  ftp:"
<Kamion> dAndy: oh, any funny proxy stuff going on?
<janimo> Kamion, do you know how much effort and risk would bug 41322  involve
<dAndy> Kamion: nope, no proxy
<omeg> By the way, I should file a bug report about this, but the American English translation of Breezy says "Analysing your system" in the update program.
<janimo> oh, ubuntu timed out
<janimo> ubugut
<glatzor> omeg: there was already a bug report about his
<Kamion> janimo: I should be able to do it tomorrow
<mvo> mdz: http://people.ubuntu.com/~mvo/gimp_2.2.11-1ubuntu3.debdiff (<- remove the first-time-wizard, taken from breezy, tested with pbuilder, verified that it really works)
<omeg> Ah, okay. I bet it's fixed already, then.
<glatzor> omeg: yep.
<janimo> Kamion: great
<mvo> glatzor: hello! 
<mdz> Kamion: I have the new live CDs booted now; is there any test case I should try for the ubiquity partitioning issues?
<glatzor> omeg: replaced "analy(s|z)e" by "examine" 
<glatzor> hi mvo
<omeg> Clever.
<glatzor> omeg: somebody else suggested this :)
<sladen> omeg: centre of the circle (around the mouse) looks a bit bright in the x* logo
<Kamion> mdz: ensure that ubiquity presents you with the auto-resize option (actually I'm not certain that's necessary, but let's pretend it is) and then try your choice of permutations of manual partitioning, without deleting the partition it offered to resize
<glatzor> mvo: sorry, but I haven't found the time today to finish the docu
<mvo> glatzor: no problem
* mvo hugs glatzor
<Kamion> mdz: make sure that it does not say "Resizing partition" at any point; to make certain, grep for RESIZE_PARTITION in /var/log/partman
<glatzor> mvo: it is a problem actually :)
<Kamion> it should not appear
<glatzor> mvo: polishing the German translation consumes nearly all my open source time
<omeg> sladen: yeah, I wanted to give the mouse some emphasis.
<mvo> glatzor: the current translation has a bug that makes the update-manager crash in ngettext
<glatzor> :/ what did I say? I don't know anything about the German translation :)
<glatzor> mvo: only in the German translation?
<mdz> Kamion: it doesn't present me with the auto-resize option
<mdz> I have 2 primary + 1 logical partition in this vm
<mdz> er
<mdz> 1 primary and 1 logical (1 extended)
<siretart> mdz: do you know if the TB meeting scheduled for tomorrow is going to actually happen or has it been canceled?
<mdz> siretart: I hadn't thought about it
<mvo> glatzor: yes, in the translation is a "%s" that is missing and so python can't subsitute the string. but I can't find the string in rosetta easily :/
<mvo> oh well
* mvo goes for dinner
<mdz> siretart: keybuk and I will definitely be busy, and probably sabdfl too
<glatzor> mvo: no it's a bug in the code
<siretart> mdz: I have a question about backports for the tb. shall I ask/discuss that on the mailinglist instead then?
<mvo> mdz: if you are ok with the debdiff for the gimp first-time-wizard I can upload it after dinner
<mvo> glatzor: is it?
<mdz> mvo: url?
<mdz> mvo: ah, I see it
<mvo> :)
<mdz> mvo: the patch from breezy applied unmodified?
<glatzor> mvo: I am not sure. one moment
<mvo> mdz: yes
<mvo> glatzor: sure, I'm about to leave for dinner anyway, take your time 
<ogra> omeg, your png is indexed to 256 cols 
<pygi> vuntz, are you around ? (emergency) :)
<ogra> )the edubuntu one)
<mdz> mvo: ok then
<glatzor> mvo: the code is ok. I misunderstood the syntax.
<sladen> mdz: could you time-shift the TB meeting.  At T-1week it would be really useful to have a chance for you to lay out timetable, area that need focusing on
<ogra> omeg, can i get one with 16 cols so i can include it right away ? 
<Kamion> mdz: there are various reasons why it might not
<mdz> Kamion: does it matter for the test?
<Kamion> mdz: try manual partitioning anyway and make sure it doesn't erase
<Kamion> the bug is essentially that it will go into autopartitioning without you asking it to
<Kamion> erasing was the dholbach manifestation
* Kamion is coming to believe that preseeding kbd-chooser/method was never actually meant to work
<mdz> Kamion: in the cases where it did the wrong thing, was the summary display correct or incorrect?
<Kamion> mdz: correct, IIRC; but the breakage happened before the summary was displayed
<j^> hm, resume stopped working, i just get a yellow "inu" and a blinking curser left of it
<mdz> Kamion: it doesn't seem to have erased
<mdz> Kamion: I don't have a /var/log/installer/partman
<xhaker> oh.. something changed in the install cd's? why is it called alternate now? pushing for ubiquity?
<mdz> xhaker: only the filenames changed, to match the new descriptions
<Kamion> mdz: /var/log/partman
<Kamion> xhaker: see ubuntu-devel-announce@
<Kamion> we announce major changes there
<xhaker> Kamion: maybe i have it set to digest mail, thanks
<Kamion> there's not very much point setting announcement lists to digest, usually :-)
<mdz> Kamion: mailed you the logs
<bddebian> Where are we supposed to put our names for core-dev consideration these days??
<omeg> Done. What a tedious job.
<omeg> [21:37]  <ogra> omeg, your png is indexed to 256 cols <-- The Xubuntu one?
<crimsun> bddebian: apply to the LP team.
<omeg> That's strange...
<ogra> omeg, edubuntu 
<ogra> omeg, ogra == edubuntu, janimo == xubuntu, Riddell == kubuntu 
<sladen> bddebian: https://launchpad.net/people/ubuntu-core-dev/+join
<omeg> Let's see.
<ogra> ;)
<bddebian> Thanks crimsun and sladen :-)
<omeg> Oh dear. I wonder if I can fix that. Photoshop might completely re-arrange the palette.
<omeg> It did. Tsk.
<janimo> are candidate CDs building tonight?
<ogra> omeg, thats why i didnt touch it with gimp now
<ogra> (to prevent palette rearrangement)
<mdz> 32gnome_power_manager seems awfully slow
<sladen> ogra: Gimp doesn't much with the order of the palette
<mdz> but it does run, so confirmed that fix
<ogra> sladen, if i shrink it down from 256 to 16 cols it might
<omeg> Let's see if I can do it with gimp, too.
<mdz> Kamion: er, never noticed all this module loading business at the end of ubiquity before
<mdz> Kamion: seems to say Installing system / Loading module[...]  while mkinitramfs is actually what's running
<omeg> I don't think I can remove colors with GIMP.
<omeg> I'd have to convert it to RGB first and that would definitely break the palette.
<ogra> omeg, switch it to rgb and back to indexed 
<ogra> yep
<omeg> So I guess I'll have to fix it manually, then.
<ogra> mdz, did the upload queue already get switched to manual approval mode ? 
<mdz> ogra: no, why?
<slomo> no uploads are currently ACCEPTED, even universe ones
<ogra> hmm, i'm missing my edubuntu-meta upload
<ogra> from 1h ago
* mvo misses his gimp upload too, but it was only a couple of minutes ago
* mvo goes and gets a ppc to do more testing
<mdz> ogra: ok, I may have lied
<mdz> the cron job seems to be commented out
<Kamion> mdz: that appears to have used the automatic erase option
<mdz> but I didn't do it
<Kamion> unless I'm misreading this
<Kamion> oh, sorry, I did it for the langpack uploads
<Kamion> I'll fix it
<mdz> Kamion: I used  manual
<bddebian> slomo: ??
<slomo> bddebian: hi :)
<Kamion> fixed
<Kamion> (queue)
<ogra> thanks :)
<sladen> Kamion: ta
<mdz> ogra,slomo: should be processed in ~1m
<bddebian> slomo: Hi.  What do you mean no uploads are ACCEPTED?
<bddebian> Oh, NM
<slomo> thanks :)
<Kamion> mdz: did you run ubiquity more than once there?
<mdz> Kamion: no
<Kamion> mdz: there's probably no progress message for mkinitramfs, oh well
<mdz> Kamion: I thought there was before; wasn't it "Detecting hardware" or such?
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_TEST.png
<omeg> Whew
<omeg> Finally fixed.
<omeg> It has 16 colors now. I'd prefer it if it's tested just to make sure that it IS correct, though...
<bddebian> Heya ivoks
<ivoks> hey bddebian 
* ivoks lurks for free main maintainer :)
<Kamion> mdz: oh, you appear to have selected "erase entire disk" on the autopartitioning page, gone forward to the summary page, gone back to autopartitioning, then selected manual partitioning; is that accurate?
<mdz> Kamion: yes
<Kamion> and are you just testing me to see if I can work this out rather than telling me? :)
<Kamion> I was rather scared when I found the evidence that "erase entire disk" had happened
<Kamion> but it seems correct and not a problem
* omeg fixes edu.
<mdz> I thought that was what I was meant to do
<ogra> omeg, yay \o/
<Kamion> mdz: depends whether you already had a VM with something useful installed in it
<Kamion> anyway, all seems happy
<bddebian> ivoks: Good luck :-)
<omeg> janimo: is it easy for you to check to see if that Xu splash screen is okay? Don't want to end up with a garbled screen...
<omeg> I think that it is, though.
<omeg> The palette is indexed correctly from what I can see.
<janimo> omeg, where do I take it form?
<janimo> although don;t rely on my taste for this, better post to the artwork list
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_TEST.png <-- fixed version (correct palette, 16 colors)
<janimo> I am and was fine with all usplashes so far
<mdz> Kamion: it had an older install
<janimo> omeg, very good looking :)
<Kamion> I have a candidate fix for bug 31661
<Ubugtu> Malone bug 31661 in kbd-chooser "ignores preseeding" [Normal,Confirmed]  http://launchpad.net/bugs/31661
<janimo> very ubunuish
<omeg> I would post it to the artwork list, janimo, but as far as I know, no other splashes for Xu have been made yet, and a decision for the final Ubuntu splash is going to be made tomorrow; there's not really anymore time for another debate, I think.
<omeg> But I'll check the Xubuntu wiki, too.
<ogra> shiny :)
<janimo> omeg, a minute
<janimo> https://wiki.ubuntu.com/DapperXubuntLookProposalSteel
<janimo> there was a splash in breezy alreday
<janimo> but this is the first which looks like ubuntu's
<omeg> Oh, I bet v550 made that. Looks like his style.
<omeg> Well, I don't know then.
<mdz> if someone who could reliably reproduce the problem with casper not responding to ENTER on reboot/shutdown could confirm the fix in the current daily-live, that would be much appreciated
<janimo> omeg, actually I think it was JOzsef Mak
<mdz> I'll need to go and forage for food soon
<janimo> omeg, I like yours, that's why if you could post to the artwork list it'd be kind of a vote
<omeg> Sure, I'll do that if you're okay with packaging it later.
<janimo> omeg, I am not sure but the colours shoul use the palette on the page I linked too
<janimo> steel blue it's called I think
<janimo> all our artwork is basedon that
<janimo> that's why consulting with jmak would be advisable
<omeg> I kind of tried to keep that color style while, like the other splashes, keeping the logo bright (since it's on a black background). It doesn't seem to perfectly adhere to the color scheme you linked to because of that.
<janimo> to combine our palette with the nice effects you made
<omeg> Looks like it needs to be a little more greenish blue.
<omeg> Mine is almost purple-ish blue.
<Keybuk> mdz: I'm going to try and find the real root cause of that tomorrow
<janimo> omeg, it's not my decision though, it needs someone with an eye for these things
<Keybuk> I suspect there's some fundamental bug in there that probably should be fixed
<Keybuk> bddebian: oh aye @ application
<omeg> janimo: sure, I'll put it on the art list then.
<bddebian> Keybuk: ?
<janimo> omeg, thanks
<Keybuk> bddebian: ubuntu-core-dev :)
<bddebian> Keybuk: Oh, thx
<Keybuk> we get e-mail when people apply
<Keybuk> shiny
<bddebian> Ack, I hate foo.desktop.in..  Escpecially with more than one binary package :-(
<Keybuk> bddebian: not sure whether there's a TB meeting tomorrow or not
<omeg> Argh.
<omeg> Now I'm going to have to fix the palette again.
<omeg> janimo: I'd say that this looks like the color scheme you mentioned: http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_UNFIXED.png
<janimo> omeg, still looks blueish to me, but am not sure.
<omeg> Hmm
<janimo> that's why I'd like someone else to decide :)
<janimo> I see no difference vs the previous one that's why
<janimo> omeg, althoug our wallpaper is very blue
<janimo> but our current spplash is bleak
<bddebian> Keybuk: Oh, it might be cancelled?
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_UNFIXED.png (updated)
<omeg> The thing is, my usplash goes into almost full white.
<omeg> That old usplash stays in mid-tone range.
<Keybuk> bddebian: it's not perfectly timed given the location and activity of the participants
<omeg> So it will look a little different, although the hue values are similar.
<Keybuk> it would be "now" which is the latest mdz has to get food
<bddebian> Keybuk: Aye.  No rush on my application anyway.  I was gonna wait until after release anyway
<omeg> https://wiki.ubuntu.com/DapperXubuntLookProposalSteel?action=AttachFile&do=get&target=login.png <--> https://wiki.ubuntu.com/DapperXubuntLookProposalSteel?action=AttachFile&do=get&target=login.png
<omeg> (Comparison)
<Keybuk> I've sent a mail to the others to ask whether we're planning to actually do it or not
<janimo> omeg, I like it as I said. But would like more people preferably from the art list to OK it. Not to fight over it or anything, just so I know there's at least some consensus
<Keybuk> we've cancelled the distro team meetings until after release too, for example
<omeg> Yeah, I fully agree with that. If there's no time issue, I'll do it right away.
<omeg> I'll toss it on the wikipage.
<janimo> omeg, those were the same links?
<omeg> Did I accidentally paste the same links?
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_UNFIXED.png <--> https://wiki.ubuntu.com/DapperXubuntLookProposalSteel?action=AttachFile&do=get&target=login.png
<omeg> heh, sorry
<janimo> omeg, yes please put them i the wiki and post to the art list
<janimo> someone will probably post a link to xubuntu-devel too then
<omeg> Is there a specific Xubuntu art list?
<omeg> https://wiki.ubuntu.com/DapperXubuntuUsplash
<omeg> Note: palette has not been fixed. Will do it now.
<janimo> omeg, no xubuntu-devel list is what I meant
<mgalvin> hmm, why are the desktop images stored as /usr/share/backgrounds/warty-final-* in ubuntu-artwork?
<omeg> Ah, okay. So you will post it there, and I'll post it to Ubuntu-art?
<janimo> omeg, you post in ubuntu-art please, and there are people (not me) following both, and they will probably link to your post
<janimo> the guy involved with xubuntu artwork is on the artlist, I assume he will
<omeg> Mail sent. I linked to https://wiki.ubuntu.com/DapperXubuntuUsplash in the post, so we'll be seeing votes appearing there shortly, I think.
<omeg> Now for the tedious and hopefully final task: fixing that damned palette (maybe I should beg my programmer friend to make a program for such things...)
<wasabi> Hmm. So how is the framebuffer resolution selected?
<omeg> Blam. Palette fixed.
<omeg> Huh. Wait a second... now it's in 256 again.
<omeg> Man, I give up. I can't do this. Photoshop keeps messing up my palette. Maybe GIMP will work.
<omeg> Unless someone can pull a really cool C trick that will strip the image of the rest of its 240 colors.
<omeg> Hmm...
<omeg> Seems to be 16 colors in GIMP. How is that even possible?
<ogra> strange
<Chipzz> omeg: xpm? :)
<omeg> Perhaps someone could double-check for me. It seems that it's correct now: http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_UNFIXED.png
<omeg> If it still has 256 colors... xmp?
<Chipzz> you could do cool tricks with xpm in perl ;P
<ogra> Chipzz, not sure usplash eats xpm 
<ogra> but indeed you can always try feeding :)
<Chipzz> ogra: I meant for playing cool tricks ;)
<Chipzz> s/play/pull/
<Chipzz> xpm rocks for that kinda shit ;)
<omeg> Can xpm reduce a PNG's colors, or something?
<Chipzz> omeg: no, but you can hand-edit xpm
<omeg> Because I would indeed greatly appreciate it if someone could do that to my Edubuntu screen so that it doesn't have to be done manually.
<omeg> Oh.
<Chipzz> omeg: have you ever seen an xpm file?
<omeg> Hand-editing the palette in text would indeed be useful.
<omeg> Nope.
<Chipzz> it's basically ascii-art
<omeg> But I'm not gonna check it out right now, since I'm a little busy. I'll quickly finish this and then finish other stuff... it'll be working past midnight tonight.
<ogra> omeg, so no new edubuntu splash ?
* ogra still waits with his artwork upload 
<omeg> I'm referring to the Edubuntu splash with "this" :)
<ogra> ah, yay :)
<omeg> Maybe you could check for me whether that Xubuntu screen shows up as 16 colors for you. I'm overly confused now. Photoshop shows 256 colors, GIMP shows 16.
<ogra> Display Type: Indexed Color (16 colors)
<ogra> omeg, thats what gimps info window tells me
<omeg> Great!
<omeg> I'm glad that it's right.
<ogra> so here it seems ok
<omeg> Photoshop is just really incapable of editing 16-color palette files without using "Save for Web" then (which ruins the palette by reordering it per frequency, which is actually against the PNG specification).
<ogra> yeah, gimp rules for web graphics development (while it totally sucks for professional print stuff)
<ogra> s/web/screen/
<sladen> is there a nice tool for producing split patches from  cvs rdiff  anywhere?
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_newsuggestion_0_8_FIXED.png
<omeg> I think this is fixed.
<ogra> omeg, Indexed Color (256 colors) :(
<omeg> I've tried to seriously use GIMP only twice, so I'm nobody to judge, but its interface seems a little strange to me. I work as a designer so I doubt I'd ever be making the switch, though.
<omeg> I don't see how it's even possible.
<omeg> Yep, seems like it...
<omeg> Arrrgh
<jcole> are you trying to reduce the colors in gimp?
<jcole> that has never worked well for me
<omeg> No, Photoshop.
<sladen> omeg: people are generally happy with whatever they used first.  After 8 years of using GIMP I will (and do) have a hard trouble with Photoshop.  (Indeed, I get exasparated that Photoshop can't do basic things like palette editing :)
<omeg> Yeah, I guess. I really don't like the fact that Gimp's separate windows also have separate task bar entries, though.
<omeg> My friend told me that PNGCRUSH can probably fix my palette for me.
<jcole> convert $BACKGROUND.png $BACKGROUND.jpg
<jcole> convert -colors 14 $BACKGROUND.jpg $BACKGROUND.png
<jcole> pngtopnm $BACKGROUND.png | ppmtolss16 "#000000=0" "#ffffff=7" | lss16toppm | pnmtopng > $BACKGROUND.png
<jcole> convert -colors 14 $BACKGROUND.png $BACKGROUND.png
<jcole> (sorry for the flood)
<jcole> omeg: ^^^
<omeg> Hmm?
<omeg> JPG?
<jcole> ya
<sladen> omeg: you're lucky they even *have* menu bars.  the menu bars only came in the last year or so---before that everything was via a right-click;  which is still the mode I use it in
<jcole> it removes the transparent png stuff
<jcole> it's a hack
<omeg> But won't that cause major artifacts?
<ogra> jcole, and that will preserve the right order for the text printing etc ?
<ogra> remember we talk about usplash ;)
<ogra> sladen++
<ssam> omeg, you could put a "--quality 100" in the first convert command, to use the least jpg compression
<omeg> Maybe jcole could try it for me. I don't have those "convert" and "pngtopnm" programs.
<jcole> omeg: apt-get install imagemagick netpbm syslinux
<jcole> omeg: but i'll hack at it also :)
<omeg> Awesome. I'll try that if pngcrush fails.
<sladen> ssam: you don't even need the first two lines.  completely ignore them---they're for people wanted to take $some_random_jpg_photo 
<jcole> $ file edu_newsuggestion_0_8_FIXED.png
<jcole> edu_newsuggestion_0_8_FIXED.png: PNG image data, 640 x 400, 8-bit colormap, non-interlaced
<jcole> it's 256 color palette
<sladen> jcole: it could probably be fine to convert to straight;  the 14 colours are all in the first 16 anyway
<omeg> It needs to be a 4-bit PNG with the 16 colors in the exact same order as the source file.
<sladen> omeg: obviously the palette needs to be correct, but the 4-bit may not matter, so long as it is indexed
<omeg> Well, the palette is already in correct order, it's just that there are 240 colors after them.
<jcole> omeg: got it -> edu_newsuggestion_0_8_FIXED.tmp.png
<jcole> err
<jcole> omeg: http://jcole.org/edu_newsuggestion_0_8_FIXED.tmp.png
<jcole> omeg: pngtopnm edu_newsuggestion_0_8_FIXED.png | ppmtolss16 "#000000=0" "#ffffff=7" | lss16toppm | pnmtopng > edu_newsuggestion_0_8_FIXED.tmp.png
<omeg> Wow, I think that this indeed did the trick.
<ogra> jcole, the palette order is still the same ? 
<omeg> But it would appear that there are 14 colors now?
<jcole> omeg: 15 actually
<omeg> No, 15.
<ogra> gimp says 15
<omeg> Hmm.
<sladen> jcole: except that you overwrote the existing text palette entry with white.  was that intended?
<omeg> I guess it needs an extra 16th color, then.
<ogra> i' also worried about the palette
<ogra> since thats the whole purpose of it 
<omeg> Thanks a lot, though! I'll add that extra color. I doubt the palette will be broken by that.
<ogra> (making the usplash text readable through the right order)
<jcole> i simple "convert -colors 16 edu_newsuggestion_0_8_FIXED.png edu_newsuggestion_0_8_FIXED.tmp.png" did that
<jcole> download the file again
<_ion> Sigh. The problem with the savage driver doesn't seem to be fixed in CVS.
<KaiL> great new ubuntu gnome splashscreen  (if the person, who made it, is here ;)
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_FIXED.png <-- one last check just to make sure, then? I added a 16th color (which is used on only one pixel)
<omeg> You mean the one that shows up when X is being started (after logging in), KaiL?
<KaiL> omeg, yes
<mdke> yes, very nice artwork all round
<Kamion> BenC: argh, the kernel failed to build on amd64 and powerpc
<omeg> Oh, too bad ;) I made another splash screen. But yeah, that one is also very nice.
* ogra gives a thumbs up to omeg 
<ogra> omeg, looks good
<ogra> i'll do a testbuild 
<BenC> Kamion: yeah, I see...fixing it up...it's silly crap too
<Kamion> ABI changes in both cases
<Kamion> are they real ABI breaks?
<KaiL> everybody makes better splashscreens, but nobody wants to make a not black usplash? ;)
<Kamion> KaiL: black is good, stops the border being visible
<omeg> Well, there are non-black usplash propositions, but apparently it's not entirely flawless on most systems. That's why it'll probably happen only for Edgy, if at all.
<mdz> back
<KaiL> Kamion, seen suse 10.1?
<Kamion> on many systems anything other than black is really ugly
<KaiL> there's not much good on their distribution, but the sclash looks great
<Kamion> KaiL: no, but if it uses a non-black splash then I bet I can show you systems where it's ugly
<Kamion> KaiL: on your system, the splash probably reaches roughly to the edge of the monitor
<mdz> KaiL: the artist isn't here, but I'll pass on your comments
<mdke> KaiL: usplash has been discussed to death, let's move on now
<Kamion> KaiL: it is not at all uncommon for this not to happen, and for the splash to occupy a relatively small area in the middle of the screen
<Kamion> with a black background, you don't notice this, and it looks more stylish on those monitors as a result
<KaiL> Kamion, that should only happen with vga= set, or?
<omeg> ogra: if you can make test builds easily, can you also test the Xubuntu splash? http://omega.avalanchestudios.net/personal/dropbox/usplash/new/xu_newsuggestion_0_8_FIXED.png
<Kamion> KaiL: nope
<omeg> I think that this is the fixed version of Xu splash.
<jcole> wow, you guys have been busy, went to javaone on thursday and missed a few hundred mb of updates since then :)
<KaiL> jcole, only? ;)
<KaiL> hmm, my test-laptop here has the black usplash - when was that? week ago? or better "200MB ago"? ;)
<Kamion> KaiL: we used to see this effect on the CD splash screen, too; now it has a black background and it's much less noticeable
<mdz> reboot time
<KaiL> oops, good guess - 181MB ;)
<omeg> I guess that turning off digest mode for the mailing list will cause me to receive all mails live?
<Kamion> yes
<omeg> That's better.
<KaiL> and brings some action to bored mail servers ;)
<ogra> ubuntu-art is not that high traffic
<omeg> Yeah, I'm always waiting for mailing list digests at work.
<omeg> Boring otherwise. :)
<KaiL> about the new logout-button: isn't that one a bit too colourful?
<omeg> I don't really like the new logout dialog, actually. I prefer a list of text.
<omeg> I also think the shadows are too heavy.
<KaiL> that too
<omeg> All things I intend to extensively write about from a designer's point of view for Edgy. But definitely too late to change now.
<KaiL> at least dapper artwork is a very bit steap ahead compared with breezy
<KaiL> very big step... late in europe
<omeg> I've got some issues with the new theme.
<omeg> I think I'll like working on an alternative proposal. My main beef with it is that the color orange for the title bar is very bright, and the text is white.
<sladen> Log out and Lock Screen really need switching
<sladen> the least intrusive should be on the left, and the most intrusive (Log out, Shutdown) on the right
<KaiL> hmm.. looks like the translations need a lot more promotion for edgy - only one language above 90% :/
<KaiL> sladen, the it would be lock, switch, logout in the first row?
<_ion> I'd prefer "Lock screen, Switch user, Log out"
<KaiL> +n
<crimsun> sladen: no one begins on the right and works left (I'm thinking bidi)?
<omeg> If you were to ask me what Ubuntu is, I'd say that it's a good, new-fashioned operating system with good, old-fashioned mannerisms. Which is a great thing. Some of the recent Dapper developments have steered it slightly away from the latter.
<KaiL> omeg, like?
<KaiL> except, that I guess, everybody has at least one bug, he (or she) doesn't understand, why it didn't get fixed - as always..:)
<BenC> Kamion: ok, uploaded...note these aren't "build failures", they are unexpected variations in the ABI, like some rtc functions moving from module to vmlinux :/
<BenC> sucks that this got so ugly for a few config changes and no real code changes
<omeg> Like, as I mentioned, the title bar that's too bright (it actually fails a color brightness treshold check suggested by the W3C). Or the new logout screen. The latter heavily relies on art but, in my opinion, seems to negatively alter the actual usability of the dialog. Or the tooltips that show up immediately over the top menu items. Or the gradient in those tooltips.
<KaiL> huh? Still kernel work?
<omeg> Or the border around the windows in the new Dapper theme. It's grey, but it's made to look as if it's almost not there. This causes a strange effect to appear when you actually do notice that it's there. These seem like personal preference issues, but I'll write about those things more in-depth later, after things cool down a little bit and we can begin to think about Edgy.
<omeg> I believe that if I can convey what I mean from a usability point of view, people will agree with me or at least start a dialogue about how we could make the interface even better. That's the area I want to commit myself to for Edgy.
<KaiL> the problem with this border is, that you can't life without one (technically) in X, but it normally looks awefull and is useless
<omeg> Would you recon it was useless in the old Breezy theme, or is in other operating systems that it's seen in (Windows NT, Mac OS 9, Mac OS X (metallic windows))?
<KaiL> Mac OS X has no border...
<omeg> The metallic windows do.
<KaiL> as you can best see in Safari
<KaiL> "metallic"? Theme?
<omeg> Open a Finder window in Mac OS 10.4.
<omeg> Or see here: http://upload.wikimedia.org/wikipedia/en/f/fe/TigerDesk.png
<KaiL> ah, yes
<omeg> The thing is, there still is a border; but it's being pretended like it isn't there. Why, I'd ask.
<omeg> (In the Dapper theme.)
<KaiL> sometimes it has, sometimes not.. interesting
<omeg> It hasn't got a border if you choose to use a small window (switched with the top-right button on the windows).
<omeg> E.g. the window at the center of the screen is in small mode.
<omeg> Safari doesn't have the border either.
<ogra> omeg, dark brown font, white porgessbar background and yellow progress indicator in edubuntu ...
<omeg> Ahhhh
<KaiL> ;)
<ogra> the only readable thing was the "failed" message of my disabled dhcp server
<omeg> Hmm. So I'll have to fix.
<omeg> Okay, so what exactly is wrong?
<ogra> as suspected, the palette was shuffled by convert
<omeg> But the logo itself looked okay?
<ogra> the default font uses a dark brown
<ogra> the logo is fine
<ogra> and the yellow on white progeress looks cool as well
<ogra> its only the default font color
<omeg> Well, yellow on white, that sounds scary.
<omeg> Or at least not as how I envisioned it. That would kind of spoil consistency. I'll try to fix it.
<ogra> ok
<ogra> but majorly the font is an issue ...
<omeg> Could you test the Xubuntu splash to see if that one works? Or is it a lot of work?
<ogra> i'm not really fond of breaking my test setup currently since i'm working on finalizing the edubuntu CD
<ogra> i could build a ppc xubuntu-artwork-usplash if you find anyone to test it
<ogra> (no other build machione around currently)
<omeg> I'll just test it by looking at the palette.
<ogra> hmm, janimo seems gone ... :/
<omeg> Okay. So I think that Xubuntu is correct.
<omeg> Let's check Edu.
<ogra> mdz, did you do livefs builds for the derivatives as well ? or was that only ubuntu
<omeg> Hmm. 8 --> 4...
<sladen> Kamion: is the cronjob running again?  I haven't since any emails from Ubuntu Installer for a few hours
<sladen> Kamion: oh, conincidence.  Got one in the last 15seconds
<omeg> ogra: I think I've fixed it.
<ogra> lets see :)
<omeg> I'm uploading it now. It's past midnight here. How long will it take you to see if it's really okay now?
<ogra> omeg, i'm in germany i know the time ;)
<omeg> Ah, okay :)
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_FIXED_retry.png
<omeg> Here it is.
<omeg> If it will take you longer than, say, 20 minutes to test, then I'd like to go to sleep. I've got lots of stuff to do tomorrow...
<ogra> building now ...
<omeg> Hmm, seems Viper550 voted for the other Xubuntu splash :P
<omeg> Well, I guess there will be more votes tomorrow.
<ogra> i didnt like his colors for the edu splash
<ogra> somehow tan (or pastel pink or how you wanna call it) doesnt work well with yellow
<omeg> I haven't seen it, but I doubt it does.
<sladen> where is this vote?
<ogra> omeg, https://wiki.ubuntu.com/Usplash/DapperPropositions?action=AttachFile&do=get&target=v550_eduratio.png
<omeg> https://wiki.ubuntu.com/DapperXubuntuUsplash
<omeg> Ick. Now that I see it again, actually, I do realize that I've seen it.
<ogra> :)
<omeg> Seems to be off-center.
<ogra> thats a color combo nobody forgets i guess :)
* omeg checks
<omeg> It's 20 pixels off-center.
<omeg> Give or take about 4 pixels because the logo should be centered using the logo's circle radius rather than the "head" to the far left, but that's still a lot. I wonder if he even tested it before saving.
<ogra> i doubt it
<ogra> he even sent truecolor proposals in the beginning
<Riddell> infinity, Kamion, anyone around who can rebuild the livefs for kubuntu?
<omeg> You know what really bothers me?
<omeg> https://wiki.ubuntu.com/DapperPropositionsClean?action=AttachFile&do=get&target=d_final_v550_ubuntu.png <-- viper 550's Ubuntu splash proposal's gradient is off-center, too.
<omeg> The gradient isn't centered at the middle of the logo.
<ogra> yep
<omeg> Upon further inspection, it seems that the image is 641x400 and 10 pixels off-center.
<ogra> installing the testpackage ...
<omeg> Awesome. I can't wait.
<Kamion> Riddell: I've started off a build
<Riddell> Kamion: thanks
<Kamion> although the cron job would fire in four or five hours anyway
<ogra> Kamion, ah, i was about to ask
<Kamion> keep an eye on http://people.ubuntu.com/~lamont/liveLogs/dapper/kubuntu/latest/ to see when it's done; I'll be in bed before that
<Riddell> well, I'll be asleep by then with any luck :)
<ogra> when is ETA for them to be switched off
<Riddell> Kamion: ok
<Kamion> ogra: "later"
<ogra> *good* :)
<Burgundavia> sladen, did you still want to play with the faq on the website?
<sladen> Burgundavia: the shipit faq.  Yes, I was going to
<sladen> Burgundavia: what's the raw URL again?
<Burgundavia> sladen, http://www.ubuntu.com/support/faq?action=raw
<Burgundavia> send me the diff
<omeg> And?
<ogra> omeg, no change ...
<omeg> Huh
<omeg> How's that possible? Did you hard refresh when you obtained the new image?
<ogra> yep
<ogra> i didnt see a "failed" might be that its dark as well now
<omeg> Well then let's have a look again.
<omeg> Failed should be brighter
<omeg> Okay now let's see.
<omeg> Background color: 000000. Correct.
<omeg> Progress bar foreground color: efb631. Correct.
<omeg> Right status text foreground color: 392008. Correct.
<omeg> Progress bar background color: 1c1004. Correct.
<sladen> ogra: update-initramfs ?
<omeg> Was the progress bar background color white?
<ogra> sladen, even dpkg-reconfigure linux-blah....
<ogra> omeg, yep
<omeg> Left text status foreground color: 794d14. Correct.
<ogra> or a very light yellow or khaki
<omeg> And the last is a66d1c.
<omeg> The image is correct. There's no doubt about it. I checked all colors in GIMP, and as you can confirm, they're right where they're supposed to be.
<ogra> i think taking the latter for the left status text would make it readable
<sladen> ogra: write  "FOOBAR" on it in big letters and see if that shows up
<omeg> There's no white color near the background color for the progress bar.
<ogra> #392008 seems to be the color all text has currently
<omeg> Just to be certain, this is the link you used? http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_FIXED_retry.png
<omeg> Here's a mirror: http://avalanchestudios.net/uploads/edu_FIXED_retry.png
<omeg> I'm following what's said on this page: https://wiki.ubuntu.com/Usplash/DapperPropositions
<omeg> Or here: https://wiki.ubuntu.com/USplashCustomizationHowto
<omeg> I just don't get it.
<ogra> ogra@edubuntu:/mnt/devel/packages/edubuntu-artwork-0.1.0$ ls -l edu_*
<ogra> -rw-r--r-- 1 ogra ogra 5812 2006-05-23 00:13 edu_FIXED_retry.png
<omeg> I don't see what else could be wrong besides the usplash accidentally being built with an old version. Maybe you should ask infinity.
<ogra> apparently the right one
<omeg> Can you check in GIMP for me to see if the colors are correctly palettized?
<omeg> Because it would appear so in GIMP.
<omeg> On my end.
<ogra> it wouldnt build the package with more than 16 cols
<ogra> yep, gimp agrees here
<kmr> jcole: if you're using imagemagick for converting an image to an icc profile with perlmagick, you'll want to use the patch I submitted on launchpad for imagemagick to fix an assertation failure
<omeg> ogra: wouldn't build the package with more than 16 cols? Hmm?
<omeg> That image does have 16 colors. 0 - 15.
<omeg> Did it give an error?
<kmr> jcole: not sure, though, if the imagemagick maintainer will ever put the bug fix in the ubuntu package
<ogra> omeg, nope, thats what i'm saying
<ogra> so its correctly 18 colors palletized
<ogra> err
<ogra> 16
<ogra> indeed :)
<omeg> It would appear that way.
<omeg> I don't get it... so the image is fine on your end too?
<ogra> yep
<ogra> but it definately uses 392008 for all text
<omeg> Hmm.
<omeg> Well, I doubt that I could do anything about that. I'm sure infinity could help you out. He built my other Ubuntu splash earlier and tested it. It worked fine for him. He could probably fix up the colors if they're faulty, too.
<ogra> yep, i'll talk to him... 
<sivang> night all
<omeg> Well, I hope you succeed, ogra. I'll come by tomorrow morning at 8 AM. Maybe if you're there, you can tell me if you got any further. Though I guess you too are going to stop working now and go to sleep. Maybe you can e-mail infinity and ask him to do it, since he lives in Australia.
<ogra> omeg, unlikely you'll see me that early 
<omeg> Well, then I just wish you good luck! It'd be a shame if such a bug were to mess things up. Well, I'll see you later.
<ogra> i usually dont go to bed before 3/4am german time 
<omeg> I don't know how you do it :P
<omeg> Bye
<ogra> ciao
<ogra> and thanks !
<dAndy> Kamion: I added the sources.list from the broken install to bug #46052
<Ubugtu> Malone bug 46052 in debian-installer "FTP Support in Kickstart Stops working part way through the install" [Normal,Unconfirmed]  http://launchpad.net/bugs/46052
<BenC> Kamion: The 2.6.15-38 build should be perfect, so consider it the final
<BenC> 2.6.15-23.38 I mean :)
<ogra> Riddell, wow, i was already wondering how you survive with so many languages on the CD :)
<Riddell> ogra: was doing fine until last week
* ogra looks envious
<ogra> i'm happy to have english left :)
<Riddell> just so long as you keep in British English, that's all I need :)
<sladen> Riddell: there's no screenshots linked from http://www.kubuntu.org/
<pianoboy3333> Does anyone here use pynotify?
<Riddell> sladen: a link to osdir good enough you think?
* Riddell adds
<sladen> Kamion: what are the new names.  Desktop CD and Alternate Install CD ?
<sladen> Riddell: anything, as long as searching for 'screenshot' in the page finds it
<Riddell> I think Kamion will be snoozing
<Riddell> but those are the names he announce on ubuntu-devel-announce
<sladen> ogra: do you have a Desktop CD for Edubuntu, or only an Alternate install CD.  Or an install CD ?
<ogra> i have a live and install CD ;)
<ogra> like breezy had
<ogra> edubuntu didnt change the scheme, since we only ship the install CD through shipit, thats our default
<sladen> so Ubuntu, Kubuntu are only shipping Desktop CDs (not Alternate).  Edubuntu is only shipping Install CDs (not Live).  Xubuntu to download only.
<neuralis> sladen: have a second?
<sladen> neuralis: ask away
<neuralis> sladen: don't know if you saw the discussion above where i pang you, re: dualhead. 
<Riddell> sladen: that's right
<Riddell> sladen: and kubuntu doesn't have shipit for ppc
<neuralis> sladen: intel 915gm, dualhead, video playback completely broken on external flat panel; 100% cpu usage, no video.
<neuralis> sladen: same config's been working fine since warty. any ideas?
<sladen> neuralis: repeatable?
<sladen> neuralis: what version of  xserver-xorg-driver-i810 ?
<neuralis> sladen: yes, fully. 
<neuralis> Version: 1:1.4.1.3-0ubuntu5
<sladen> neuralis: does it actually crash, or just use 100% CPU ?
<neuralis> no crash, just 100% cpu usage until the video player is killed (and the video player isn't showing video in the mean time.)
<sladen> neuralis: can you check what process is using 100% CPU?  It could be the playback software switching to a software-decode
<neuralis> well, it's the xv output that seems to break things; x11 works (still hogs cpu, but actually shows video)
<sladen> neuralis: there is only one scaler, so Xv will only work on 1 head at once
<sladen> neuralis: did you file a bug yet
<neuralis> sladen: no, i've been trying to track down what exactly is the issue for the past few days, and to verify that it's not specific to my setup
<neuralis> sladen: mind you, this has worked properly since warty, so i'm not sure where the 1 scaler business comes in
<bddebian> Howdy folks
<tseng> hi
<jsgotangco> hi
<neuralis> sladen: i'll file against x-x-d-i. anything you want me to attach?
<sladen> neuralis: even if it is specific to your laptop, it is still a bug and still needs filing!
<ajmitch> afternoon
<sladen> neuralis: can you attach  lspci -vn   and your /var/log/Xorg.0.log  along with any output from running xine on the second head
<sladen> neuralis: and a paste showing the CPU percentage from 'top'
<neuralis> sladen: everyone's busy. i'd rather do my legwork before screaming 'bug' in a crowded theater that's about to release a major motion picture in 8 days.
<sladen> neuralis: oh!  and your xorg.conf!:)
<bddebian> Heya jsgotangco
<neuralis> sladen: will do.
<jcole> infinity: can i ping you for 10 seconds? i just want you to verify something.. 4 lines
<jcole> infinity: i just don't want to sit here staring at the screen for 6 hours and it not work
<jcole> (4 line flood alert)
<jcole> apt-get source linux-source-2.6.15; cd linux-source-2.6.15-2.6.15
<jcole> cp /boot/config-`uname -r` .config; echo "CONFIG_REGPARM=y" >> .config
<jcole> dch #(bump ABI from 23 to 123)
<jcole> fakeroot dpkg-buildpackage
<jcole> it's building now
<jcole> wow, looks like it's going to build 80+ .deb packages
<jcole> 8 hours
<bluefoxicy> Hey does anyone know where daniels gets the source for xserver-xorg-driver-via, and how I would go about attempting to build myself a copy of the latest version?
<lifeless> it should be in the copyright file, or a watch file, in the source package
<bluefoxicy> Dapper's got 0.1.33.2 and it's not working too great (100% CPU usage in glxgears or with xcompmgr -c, armagetron immediately chokes the X server to death), and cvs has version 0.2.1 or so so I figure I'll try building it while I wait for him to build xorg 7.1 some time mid-Edgy :P
<bluefoxicy> lifeless:  I'll look... watch file???
<tseng> wow
<tseng> glxgears in xgl gives 100% cpu, news at 11
<bluefoxicy> no, not in Xgl
<bluefoxicy> in normal X, with direct rendering enabled
<bluefoxicy> bluefox@icebox:~$ glxinfo |grep direct
<bluefoxicy> direct rendering: Yes
<tseng> me too and i only get 13%
* bluefoxicy has not tried Xgl ... no point, looks like too much work for silly eye candy and he doesn't have GLX working yet anyway.
<tseng> xcompmgr i meant
<apokryphos> no direct rendering in xgl ;-)
<bluefoxicy> tseng:  nods.  It's a new driver, the version Ubuntu ships is probably incomplete.  *shrug*  Not important.
<bluefoxicy> lifeless: what's a watch file?  :)
<apokryphos> and Xgl isn't much of a hassle to install, really, depending on your card; eyecandy is good though, and not always pointless at all
<tseng> debian/watch
<tseng> its a text file
<bluefoxicy> ah, thanks.
<bluefoxicy> no README, COPYING is a stub, and there's no debian/watch
<bluefoxicy> meh
<sladen> mhmm:  host shipit.xubuntu.org  exists
<sladen> bluefoxicy: cvs -z9 -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg co driver/xf86-video-via
<bluefoxicy> I would rather be able to hit shipit.ubuntu.org and request a mix and match of ubuntu/kubuntu/xubuntu/edubuntu
<sladen> r.
<netdur> at my firefox there no web page open... but statusbar says it transfer data from stat3.cybermonitor.com
<netdur> should I open bug about this? it may be spyware!!! I use updated dapper
<bluefoxicy> ATTN:  Ubuntu is now a mainstream operating system.  We have spyware infections.  Congratulations.
<netdur> I'm serious... I got screenshot!!!
<jcole> crap
<crimsun> netdur: do you have tcpdump evidence for it, too?
<jcole> make[1] : Leaving directory `/home/jcole/kern_source/linux-source-2.6.15-2.6.15/debian/build/build-686'
<jcole> ABI has changed!  Refusing to continue; please update the ABINAME accordingly.
<jcole> brb
<netdur> crimsun, what's tcpdump?
<crimsun> netdur: a tool that you should use to verify that stat3.cybermonitor.com is actually being contacted. Please migrate this issue to #ubuntu.
<netdur> never mind!
<sladen> neuralis: that appears to be a internet cafe billing software site
<bluefoxicy> haha
<neuralis> sladen: huh?
<sladen> neuralis: netdur.
<neuralis> ah.
<sladen> Burgundavia: this page looked innocent, but it's a massive hunk of text (5k words)... remind me to carry on slogging another time
<tsume> anyone a grub devel here?
<fabbione> morning guys
<bddebian> Hello fabbione
<pitti> Good morning
<fabbione> heypitti
<jsgotangco> hey pitti
<ajmitch> morning pitti
<pitti> hi guys!
<Burgundavia> sladen, will do
<omeg> Hey guys
<imbrandon> 'ello
<infinity> Hey dude.
<omeg> So, any news on Edubuntu's usplash? Anybody know if ogra got it fixed?
<omeg> Hi infinity
<infinity> ogra uploaded something.  No idea what.
<omeg> Well, he was working on the edu live CD, I think.
<infinity> I mean he "uploaded a change to his splash, no idea what". :)
<infinity> https://lists.ubuntu.com/archives/dapper-changes/2006-May/011417.html
<omeg> Ah, looks like he didn't get it fixed, then.
<omeg> (He says "still some font issues to resolve.")
<infinity> I'm guessing it needed reindexing?
<omeg> Strangely enough, I had manually checked the image like twice. It seemed as though all the palette colors were in the right place.
<omeg> Still there were problems, like the progress bar background color being bright yellow.
<infinity> Curious.  I'll have to download it and have a look in a bit.
<omeg> I'll grab the correct link for the image.
<infinity> Can you give me the hex RGB for the "right" colours in the right places?
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/new/edu_FIXED_retry.png
<omeg> Yes, I'll regrab them.
<infinity> Cool.  I'll go hunt some breakfast.  Back in 10.
<omeg> Okay :)
<omeg> I'll PM it to you.
<jsgotangco> well the splash for edubuntu is much better now compared yesterday
<omeg> Hmm
<omeg> Looks like there are still only two Xubuntu splash votes.
<infinity> Has anyone voted for yours?
<omeg> I left a comment there to say that I think people should consider consistency, but I guess that can't really count as vote. I just reposted the link on the art list.
<omeg> Maybe people from the art list aren't that interested in Xubuntu.
<omeg> Huh
<omeg> In response to the link for Xubuntu splash voting, someone mailed the following:
<omeg> a link to the ubutnu one ?
<omeg> thanks
<omeg> ciao 
<infinity> I voted on the wiki for yours.
<omeg> Thanks. :)
<omeg> 40 minutes before usplash voting for Ubuntu finishes.
<infinity> omeg: Where is that taking place?
<omeg> I guess I'm thankful that then this will finally be finished. So that fun things can be worked on.
<omeg> Via e-mail.
<omeg> Let me forward you the post.
<infinity> On the -art list?
<ajmitch> hi dholbach 
<dholbach> hey ajmitch
<dholbach> good morning everybody
<omeg> adconrad AT ubuntu DOT com?
<omeg> infinity: yeah
<infinity> omeg: That'll do, yes.
<Keybuk> infinity: does infinity@ubuntu.com not work?  you should get elmo to look at that :p
<omeg> Sent.
<omeg> Heh
<infinity> Keybuk: I've never had an urge to have infinity@, or I would have asked for it.  Do you have keybuk@?
<Keybuk> infinity: I think I do
<Keybuk> I may not have
<nomed> omeg: i'll post in xubuntu-devel ...
<omeg> Didn't Janimo already do that, though?
<nomed> ummm .. i may be wrong .. but i didn't see it.
<nomed> anyway in general we'd like to have the same as ubuntu but with xubuntu colors and logo
<omeg> Seems that he didn't, indeed.
<omeg> Yeah, I've tried my best to keep the same colors. They're arguably not as close to the logo's colors as the other splash screen, but to keep consistency with the other usplashes and make it stand out on the black easier, I made the logo a little brighter. The highlights almost go into white.
<omeg> The hues are the same as the steel look, though.
<infinity> I just like that the mouse looks like a mouse on your splash.  I'm easy to please.
<janimo> mouse?where?
<dholbach> hey janimo!
<omeg> Hi janimo :)
<infinity> Or whatever rodent it's meant to be. :)
<janimo> dholbach.omeg: hey
<nomed> ehehe 
<Gloubiboulga> janimo, hello Jani
<janimo> Gloubiboulga: hey
<janimo> is a new xubuntu splash being discussed?
<janimo> nomed, satisfied with current settings manager looks?
<nomed> janimo: it seems nobodies care that much
<infinity> janimo: https://wiki.ubuntu.com/DapperXubuntuUsplash
<infinity> janimo: Vote for the same one I voted for and I won't break your livefs builds...
<nomed> janimo: if dholbach will accept it i'd a have a little patch ...
<infinity> *cough*
<dholbach> nomed: for what?
<nomed> janimo: anyway we got what i would :)
<nomed> still icon-naming ..
<dholbach> nomed: for the xubuntu icons?
<nomed> yep
<dholbach> nomed: I applied the patch from CVS already
<janimo> hmm I think  liked omeg's yesterday
<nomed> each patch i sent to you i usually send then to upstreamer too ...
<mdz> morning
<dholbach> morning Matt
<nomed> dholbach: yep .. but there is one more 
<janimo> morning mdz
<dholbach> nomed: send it to me, I'll have a look
* janimo goes to vote for michiels' mouse
<nomed> sure.
<dholbach> mdz: just preparing another ubuntu-artwork update (some SVGs they sent)
<imbrandon> morning mdz
<nomed> i'll do that this evening .. when i'll have the time to check it .. so hopefully it'll be the last one
<mdz> ogra: I'm not sure which livefs were built apart from Ubuntu; Kamion ran the build
<infinity> janimo: Well, if you and nomed like omeg's and the art team isn't interested in Xubuntu at all, I'd call that concensus.
<janimo> infinity: yup, I htink I'l lupload this soon
<mdz> infinity: any love from oo.o?
<infinity> mdz: The sort of love that hits you when it comes home from the bar at 3am.
<mdz> infinity: exactly the same failure then?
<infinity> mdz: I'm rerunning test builds right now AGAIN.  Clearly something went wrong last night (or I was half asleep when I started them)
<fabbione> morning mdz
<infinity> I'm doing -l10n on terranova, since it's an SMP machine, and -l10n has code to take advantage of that.
<infinity> So, hopefully they'll both get in today.
<janimo> omeg: did you test the splash?
<janimo> is there a link to current ubuntu/edubuntu splashes in the wiki?
<omeg> Xubuntu one? No, I haven't tested it. I checked the colors which seem to be correct, though. I don't know how to build new usplash binaries.
<omeg> See https://wiki.ubuntu.com/DapperPropositionsClean for the Dapper Propositions page.
<janimo> omeg: but besides the color are the proprtions the same as on the other splashes?
<janimo> ok
<mdz> infinity: my local build (i386-on-amd64 SMP) failed, but I can't see why from the output
<infinity> mdz: Erk, so not in the usual spot?
<mdz> ERROR: error 65280 occurred while making /home/mdz/src/openoffice.org-2.0.2/ooo-build/build/oob680-m5/ucb/source/cacher
<omeg> Yeah, they're all squished to adhere to the screen stretching.
<mdz> "gee, thanks"
<infinity> mdz: Is it too late to drop OOo from the distribution? :)
<Keybuk> pitti: language-pack-kde-tl-*, language-pack-gnome-{oc,dv}* to main>?
<infinity> pitti: No more mass langpack updates for a day or two, I hope? :)
<infinity> mdz: So, based on your above "morning", does that mean you also are pretending to be European for the release crunch?
<infinity> mdz: Or are you just suffering sleep issues? :)
<Mithrandir> infinity: I think he's in London
<infinity> Ahh, that would do it.
<infinity> Somewhere in the back of my mind, I knew that.
<infinity> Memory retention--
<Keybuk> infinity: they say it's the first thing to go
<infinity> Hey now.  I'm still a good 5 years younger than lamont...
<ivoks> Mithrandir: what's with mailman? :(
<mdz> infinity: I am in London
<mdz> since Sunday and through the release
<infinity> mdz: How many more months of back and forth before you just sell the place in LA and move to London?
<Riddell> Kamion: kubuntu is getting both install and alternate CDs made
<Mithrandir> ivoks: ETOOLATETOFIX.
<omeg> Well, guess I gotta go now
<mdz> infinity: too many
<janimo> omeg,splash looks ok
<janimo> a bit like the breezy one but ok
<ivoks> Mithrandir: i hope it will get in updates, tough
<omeg> Will you look into usplash Edubuntu sometime, infinity?
<omeg> janimo: I'm glad that there are no font issues, then.
<omeg> Thanks for checking to make sure.
<infinity> omeg: Yup, it'll fill the gaps when I'm waiting for longer-running processes to happen (like CD builds and such)
<omeg> Awesome. I hope that it doesn't need reindexing. Maybe it was just some kind of build error when the colors messed up.
<omeg> Well, see you around :)
<pitti> Keybuk: yes, please
<pitti> infinity: yes, these are meant to be the final ones :)
<Kagou> hi
<janimo> nomed, so did the vote end? can I upload the new usplash or wait some more?
<janimo> dholbach: ^
<dholbach> janimo: i think it'll end at 9:00 utc
<nomed> janimo: no idea ..
<janimo> ok
<nomed> i guess you can
<janimo> I'll wait two more hours
<dholbach> janimo: heno will be up soonish and he'll know the results
<pitti> infinity: wow, the langpacks built until just recently, so the current CD images don't even contain all the latest versions...
<infinity> pitti: I can re-roll images after we've done NEWing the lot and an archive cycle has gone by.
<infinity> pitti: Assuming you wanted to actually test images with the current langpacks. :)
<infinity> There are other builds that were stuck in the i386 queue while langpacks were building anyway, so I wouldn't mind re-rolling in a bit.
<pitti> infinity: I don't think it's necessary; I can't test *all* languages anyway :)
<pitti> and most of them are up to date already
<mdz> infinity: my failure seems to have been much earlier than the buildd's, and restarting debian/rules build lets it continue
<mdz> this package sucks
<infinity> You don't test all languages!? *shock and horror* :)
<infinity> mdz: Yes, yes it does suck.
* pitti quickly learns Georgian, Bengali, Chinese, and certain dialects of Danish
<infinity> mdz: vernadsky and terranova both seem to be grinding away okay right now, so we'll see.
<infinity> mdz: I'd still prefer to find out WHY it dies, but I just don't think we have the time to be chasing heisenbugs.
<mdz> infinity: have you been able to get a look at this?
<mdz> ERROR: Saved logfile: /build/buildd/openoffice.org-2.0.2/ooo-build/build/oob680-m5/instsetoo_native/util/OpenOffice//logging/en-US/log_OOB680__en-US.log
* pitti is stunned - I added a whole bunch of langpacks to the CDs yesterday, and now the i386 live one is only 636 MB; did we drop WinFOSS or anything?
<infinity> mdz: The builds have never died quite the same way on a manual build as they do on an automated build, so I'm not sure how useful that would be.
<mdz> infinity: I mean the log from the automated build, of course
<dholbach> to everybody who enjoys big scaled folders on the desktop: you'll have real scalable folders with this ubuntu-artwork upload - YAY!
<infinity> mdz: I can do an automated build and hack up lp-buildd to not kill the chroot afterward.  But I'd rather do that AFTER the crisis is averted with manually-built packages.
<mdz> the one which is redirecting its error output to that logfile
<infinity> mdz: Yeah, see above. The automated build keeps nothing, so I'll need to hack that.
<carlos> pitti: morning
<pitti> hey carlos
<carlos> pitti: dude, I just remember that I forgot to give you the updated gnome-panel .po files....
<carlos> did you download it from Rosetta?
<pitti> carlos: I noticed yesterday, too
* infinity starts making a "things we need to add to lp-buildd to make it less useless" list for him and cprov in Paris.
<pitti> carlos: no, too late unfortunately; we'll fix it via -updates
<carlos> ok
<carlos> I just approved the XFCE translation domains, so we should have all fixed now
<pitti> yay
<dholbach> hey mvo
<mvo> hello dholbach
<pitti> infinity: ah, the current desktop-i386 iso contains just very few langpacks, that's why it is so small
<pitti> infinity: however, ubuntu-meta is correct wrt live-i386 contents. any idea?
<pitti> infinity: ah, easy, ubuntu-live package is at 0.114 on the live-i386, so it's just too old
<mvo> iwj: hello, did you see the latest comment for bug #26436
<Ubugtu> Malone bug 26436 in firefox "gtkmozembed crashs with python" [Unknown,Confirmed]  http://launchpad.net/bugs/26436
<dholbach> infinity, mdz: is it ok to upload some small changes in example-content or are you preparing CD builds atm?
<mdz> dholbach: go ahead
<dholbach> mdz: ok, thanks
<dholbach> heya seb128!
<mdz> any sort of RCish builds are blocked on oo.o
<seb128> hi dholbach
<fabbione> what's wrong with oo.o?
<mdz> fabbione: FTBFS
<mdz> in weird and unreproducible ways
<fabbione> mdz: what arch?
<mdz> fabbione: i386
<fabbione> ok
<Kinnison> erk
<mdz> seems to work on powerpc and sparc, oddly enough
<Kinnison> Very odd
<fabbione> work -> build
<fabbione> from build to work there is another sea to cross
* fabbione will test later...
<fabbione> mdz: i *might* have to do a silo/silo-installer upload. i am not sure yet.
<fabbione> trying to reproduce a problem i had yesterday
<Kinnison> amd64 seems to fail too
<fabbione> Kinnison: amd64 is built from the i386 debs
<fabbione> it's not native
<infinity> Kinnison: amd64, ia64, and hppa are expected to fail. :)
<mdz> Kinnison: amd64 fails because i386 failed
<mdz> or that
<mdz> oo.o-amd64 needs uploading once i386 is sorted
<infinity> Yeah, I told doko I'd do that.
<infinity> Unless he gets home before I'm done.
<mdz> he's back around 1700 UTC today I think
<Kinnison> Oh right, still not native
<Kinnison> sucks
<infinity> iwj: Alive and at work yet?
<infinity> iwj: Your ttf-freefont patch doesn't apply: https://launchpad.net/+builds/+build/197438
<mdz> mvo: did sun java get added to app-install-data?
<mdz> ah, yes, good
<mdz> seb128: do you know why my System->Lock Screen is missing now?
<seb128> mdz: because it's a part of the session dialog
<pitti> mdz: apparently that is a last-minute feature
<pitti> and it sucks IMHO
<dholbach> mdz: Mark wanted to have it removed.
<seb128> pitti: not really last minute
<mdz> dholbach: when did he ask for it?
<Kinnison> eww, that's nasty
<seb128> I think it was a part of what Mark wanted for the session dialog
<infinity> It's "last minute" compared to the feature freeze everyone else had to adhere to. :P
<dholbach> mdz: he reminded me of it (seems he mentioned it before, when I was not around) in the last icon call
<infinity> But yeah, it was a couple/few weeks ago that it changed, I think.
<mdz> it was 15 May, though I didn't recognize the impact of the changelog at the time
<infinity> Week and a half, then.  I was close.
* infinity glares at his VMware sessions that appears to be hung..
<dholbach> What did we decide for the HUG DAY? Will we have it? Anything we want to focus on?
<pitti> ogra: piung
<pitti> ping, even
<Kinnison> pitti: anything LPish you need from me today?
<pitti> Kinnison: not right now; I guess I tortured the buildds enough for a while :)
<Kinnison> :-)
<Kinnison> apart from vernadsky being on manual, they're all idle :-)
<infinity> (It's manual for a reason, please don't switch it..)
* Kinnison won't
* Kinnison wouldn't
* infinity goes to put it in NOT OK, just to drive the point home anyway.
<Kinnison> :-)
<Kamion> Riddell: no it's not, it's getting them copied from previous directories. I thought I'd cleaned that up already, but I'm sorting it out now
<Kamion> mdz: did you notice that the latest kernel FTBFS on i386?
<fabbione> Kamion: we will need another upload anyway
<carlos> pitti: hi, vim is not generating the .pot file. Did we talked about it already?
<pitti> hm, can't remember
<hunger> Kamion: And the -23- kernel got really loud during bootup, too. Produces much more output than the -22- did.
<janimo> dholbach: HUG day tomorrow you mean?
<Kamion> hunger: you probably forgot to boot with 'quiet'
<Kamion> hunger: (or your bootloader did)
<Kamion> fabbione: ...
<dholbach> janimo: that was the plan
<fabbione> Kamion: we need to fix the dri/drm bits. we got input from upstream only 3 hours ago
<janimo> dholbach: for critical bugs in dapper or triaging for edgy?
<fabbione> Kamion: i am preparing patches and stuff for Ben but i also need to do other stuff
<dholbach> janimo: no edgy plans for now
<infinity> Kamion: The i386 FTBFS is easy enough to sort.  I could do it now, but I was going to wait for BenC to show up and make him do it.
<fabbione> infinity: what's the problem with i386?
<infinity> Kamion: Until these OOo builds all finish, RC's a pipe dream anyway. :/
<infinity> fabbione: ABI additions when RTC was added.  Simple to fix.
<fabbione> yeah
<fabbione> but additions are not fatal
<fabbione> or are not supposed to be
<fabbione> did we become more stricy?
<fabbione> strict
<infinity> They appear to be when the module we built in disappears.
<infinity> -drivers/char/rtc rtc_control 0xc9b27289
<infinity> -drivers/char/rtc rtc_register 0xfdab2b9c
<infinity> -drivers/char/rtc rtc_unregister 0xeddfe49d
<infinity> +vmlinux rtc_control 0xc9b27289
<infinity> +vmlinux rtc_register 0xfdab2b9c
<infinity> +vmlinux rtc_unregister 0xeddfe49d
<fabbione> oh right
<fabbione> because they disappear from the module
<infinity> Right.
<fabbione> but they maintain the same ash
<fabbione> hash
<fabbione> it's not a real ABI change
<fabbione> a depmod fixes that
<infinity> Yeah.
<infinity> So someone should be able to mangle those ABI files by hand, and we're on our way.
<infinity> (Which is what I was going to do)
<infinity> (If someone said we needed the kernel RIGHT NOW)
<fabbione> infinity: wait i am getting more stuff fixed atm
<fabbione> i can fix those manually in my tree in the meanwhile
<fabbione> did amd64 built properly?
<infinity> Yes, it did.
<fabbione> actually..
<fabbione> who did upload 23.37 ???
<fabbione> it's missing changelog entry ...
<Kamion> infinity: yes, could you do it please?
<Kamion> oh, not if fabbione wants other changes I guess
<fabbione> Kamion: we need the other changes. really
<Kamion> but I really really need to upload final d-i to-freaking-day!
<infinity> fabbione: 23.37 and 23.38 have the same changelog entry.  I assume he changed the changelog but forgot to make the actual changes in 37..
<Kamion> so any more kernel crap and I'll be very very unhappy
<Kamion> (i.e. this time round it needs to build)
<fabbione> infinity: ok thanks
<jordi> mvo: ping
<mvo> jordi: pong
<ogra> pitti, pong
<jordi> mvo: for a week or so, I've had this debian unstable box that takes a long, long time to get upgraded by apt
<Kamion> hmm, these NTFS resizing bugs with gparted are kind of annoying, I wonder how hard a backport would be
<pitti> ogra: I just changed the edubuntu seeds to fill the ppc/live with langpacks, as discussed yesterday
<pitti> ogra: I also updated my langpacksize script to be useful for edubuntu, too :)
<jordi> After the "Do you want to continue" prompt, I get the %% [Working]  prompt, which takes around 20 mins to reach 100%
<pitti> ogra: shall I update ubuntu-meta now?
<jordi> the sources list is a local http and a file:/ repo for unstable
<pitti> ogra: s/now/whenever http://people.ubuntu.com/~cjwatson/seeds/edubuntu-dapper/live is updated/
<jordi> After a long wait I managed to get to 96%
<jordi> and I suspended it in case you want to try anything
<ogra> pitti, go aqhead if you like :)
<pitti> alright
<pitti> carlos: so, vim needs to be fixed?
<mvo> jordi: thanks, interessting. This is definitely strange. does it print how fast it is downloading (the speed)? 
<infinity> Kamion: Hrm.  Looks like the LAMP install works fine now, despite no intervention on my part.... I wonder if the failures during the Flight-7 era were some transient bug...
<jordi> no, it doesn't download anything
<jordi> (in Catalan)
<carlos> pitti: I think so, yes
<jordi> 237 actualitzats, 2 nous a installar, 1 a eliminar i 0 no actualitzats.
<jordi> Es necessita obtenir 0B/162MB d'arxius.
<jordi> then it says
<jordi> Desprs de desempaquetar s'usaran 21,0MB d'espai en disc addicional.
<jordi> Voleu continuar [S/n] ?
<jordi> 96% [Treballant] 
<jordi> and that's the veeery long wait
<infinity> Kamion: Ergh.  Is there a way I can get grub to not have "splash" on the kernel commandline for a server install, though?
<jordi> mvo: want me to cancel so we can preserve this condition?
<mvo> jordi: very strange, can you see with strace what it is doing at 96%?
<jordi> I can start over
<jordi> I fear it'll eventually start the upgrade
<Mithrandir> jordi: did you get to test hot spanish keyboard love for me?
<Kamion> infinity: not without hacking grub-installer, sorry
<jordi> Mithrandir: you didn't seem y msgs?
<jordi> That same day I wasn't able to
<pitti> dholbach: shall I bump the test cd version on https://wiki.ubuntu.com/Testing/Current? also, should the matrix be flushed? or only flush once we have dedicated canditate CDs?
<jordi> but this laptop I have here does work
<infinity> Kamion: Crap.  Okay, then I guess -server installs are stuck with a vga16fb framebuffer by default.. :/
<pitti> dholbach: (I think the latter would make more sense)
<jordi> it's not a normal desktop keyboard, tho
<jordi> mvo: ok
<dholbach> pitti: yeah, just flush it
<Mithrandir> jordi: yeah, I saw your stuff from Friday, but that was a day off for the distro team and I never got around to responding.
<dholbach> infinity: are you going to do the openoffice.org-amd64 upload?
<jordi> Do you want to continue [Y/n] ?
<jordi> 17% [Working] 
<infinity> dholbach: Only when the i386 one builds...
<jordi> Mithrandir: seems to work here
<Kamion> infinity: you could set debian-installer/framebuffer=false but it would slow down the installer a lot
<Kamion> and de-support non-English installs
<ogra> hrm, the CDs look odd
<infinity> Kamion: That will will the "splash" in the target system as well?
<fabbione> Kamion: i might be able to give you a kernel before Ben wakes up
<ogra> (at least the logs)
<dholbach> infinity: can you please add   dh_iconcache  to  debian/rules  if it's not there?
<infinity> Kamion: Ahh, so it does...
<jordi> and if that didn't work for all people, we'd really have more bug reports.
<dholbach> infinity: I think doko added it to openoffice.org, but not to openoffice.org-amd64
<jordi> has anyone else said "me too"?
<jordi> select(11, [10] , [] , NULL, {0, 500000}) = 0 (Timeout)
<jordi> gettimeofday({1148374725, 783387}, NULL) = 0
<jordi> rt_sigprocmask(SIG_BLOCK, [WINCH] , [] , 8) = 0
<jordi> rt_sigprocmask(SIG_SETMASK, [] , NULL, 8) = 0
<jordi> write(1, "\r25% [Working] ", 14)         = 14
<jordi> mvo: stuck there
<fabbione> infinity: can you please do me a favour? look into the amd64/ppc build logs and check if the abi changes are the same as on i386
<jordi> every now and then, the % updates
<jordi> the date of the box is up to date
<pitti> dholbach: ok, as you wish. flushed and bumped version
<dholbach> pitti: super, thanks
<mvo> jordi: there is probably a "worker" process (http maybe) that it is talking to? can you see it?
<jordi> yup, file process
<jordi> mvo: taking this to privmsg, there's more strace output when the % changes
<mvo> jordi: ok, thanks
<Mithrandir> Seveas: why did you reject 43428 without any further comment?
<Mithrandir> oh, sorry
<infinity> Kamion: Well, if the installer's using a framebuffer, then it should work on the installed system.. And vice-versa, if people disable it in the installer, they'll get what they want.  I suppose that will do for now.
<Mithrandir> I should learn to read the full bug log.
<Mithrandir> Seveas: sorry, ignore me. :-)
* dholbach starts powerpc install
<pitti> dholbach: I just finished that :)
<dholbach> pitti: live cd install?
<pitti> dholbach: no, alternate CD
<dholbach> i'll do alternate custom partitioning
<dholbach> (so mvo can play with this box again :-))
<Kamion> dholbach: I sort of regret not taking the effort to go to gparted 0.2.x now
<sladen> Kamion: could you add a second hook for d-i to do whatever it does to not pass 'splash' later, but without getting it not to use splash during the install
<mvo> dholbach: is it up again?
<Kamion> dholbach: I'm going to attempt a backport of some of the ntfs fixes, I think
<ogra> mumble mumble, why are all Cds broken currently ?
<Kamion> sladen: not now
<dholbach> mvo: I said "/me starts powerpc install" :-p
<dholbach> Kamion: I should have pushed that more and earlier :-/
<dholbach> Kamion: there was one cvs commit about MB<->MiB confusion too - I'll try to find it
<Kamion> yes that's the one I'm looking at
<Kamion> that and the ntfsfix stuff
<Keybuk> ugh, people aren't still trying to use the "MiB" term, are they?
<Kamion> it's all tied in with the progress feedback improvements though
<Kamion> Keybuk: frankly I don't care what term they use any more as long as they agree with the tools they're using, which gparted didn't
<infinity> fabbione: Yeah, amd64 had an ABI override, but those 3 symbols jumped to vmlinuxfrom rtc...
<infinity> fabbione: The RTC change wasn't made on PPC.
<fabbione> infinity: yes thanks i got all of it
<infinity> fabbione: So, it should be for all amd64 kernels, and all i386 except for -386
<fabbione> abi files should be fixed now...
<simira> sladen: I still don't get that cpu fan to work 
<fabbione> uh?
<infinity> fabbione: And you may as well remove the amd64 ABI override then. :)
<fabbione> infinity: i already removed the overrides for all of them
<infinity> fabbione: uh?
<fabbione> infinity: so -386 was not to be touched?
<infinity> fabbione: Yeah, -386 didn't get the RTC change, since -386 is the "safe kernel for ancient hardware"... And ancient (like, 15 years or more) hardware is the only place where rtc could break something.
* mvo is impressed by the new gnome splash screen 
<fabbione> infinito: craptastic.. you could have told me 10 minutes ago
<fabbione> infinity: ^^^
<pitti> Kamion: hm, I just installed the current ppc/install and l-support-en was not installed (and with it, oo.o-help-en is missing)
<infinity> fabbione: Sorry, I was in a full-screen VMware.
<infinity> fabbione: You didn't go an upload with the -386 ABI changed, did you? :/
<fabbione> infinity: no i am still waiting for one last fix
<infinity> fabbione: Okay, then no harm done. :)
<fabbione> and still quadruple checking the changes i am doing
<fabbione> it has been too long since i did a kernel upload...
<infinity> fabbione: When you hand-edited the ABI files, did you make sure to run them through sort? :)
<fabbione> i am not exactly in the mood to fry it
<fabbione> infinity: did that already
<fabbione> and i used scripts.. no hands
<infinity> Look ma, no hands!
<dholbach> hrm, why doesn't gnome's bonsai have gparted
<infinity> Riddell: ktorrent FTBFS from an empty .po file.
<fabbione> infinity: do you think we can run a test build on all arches before upload?
<fabbione> i can have the sources on people in about 10 minutes
<infinity> fabbione: Of the kernel?  Sure.
<fabbione> infinity: yeah 
<infinity> fabbione: It'll double Kamion's wait, that's all. :P/
<infinity> s/P//
<Kamion> pitti: syslog etc.
<fabbione> infinity: it has been too long since i did hack this stuff.. and i would feel better to know that it will go in one shot
<pitti> Kamion: the installer log complains about l-support-en being broken because of wamerican, wbritish, etc. being virtual packages
<infinity> fabbione: If you're 99% sure it's right, one build beats two...
<ogra> pitti, http://cdimage.ubuntu.com/daily/current/report.html
<fabbione> infinity: i am 99.9% sure
<infinity> fabbione: But yeah, I can spin up tests on all the buildds.
<Kamion> pitti: see http://cdimage.ubuntu.com/daily/current/report.html
<Kamion> what ogra said :)
<ogra> :)
<Kamion> we're oversized
<fabbione> Kamion: what do you want me to do? upload or testbuild -> upload?
<infinity> The changelog already has enough "oops, fucked up, upload again" in it.  One more won't kill anyone.
<Kamion> fabbione: can you do a test build faster than the buildds will build it?
<infinity> Kamion: The test builds would be on the buildds, so "no".
<fabbione> Kamion: only on sparc..
<infinity> sparc is meaningless, it always finishes first anyway. :)
<infinity> i386 takes the longest.
<Kamion> fabbione: go ahead and test it, but don't wait for ia64; it's the pathetically slow one
<infinity> (Because of all the images)
<Kamion> infinity: isn't ia64 slowest? it was last time
<infinity> Oh, ia64 takes forever, cause it sucks.  Right.
<Kamion> or last time I looked
<fabbione> i only need i386/amd64/ppc/sparc
<pitti> Kamion: hm, so http://cdimage.ubuntu.com/daily/20060523/ doesn't contain .OVERSIZED warnings any more for overflowed CDs?
<ogra> pitti, only for live
<infinity> You can test i386 and amd64 on the porter box that's faster than the buildds.
<pitti> ogra: ah, ok
<fabbione> infinity: ok
<infinity> The one that replaced concordia, but I forgot its name.
<fabbione> ronne
<infinity> That one.
<fabbione> actually i will also need faure for sparc
<ogra> infinity, did omeg talk to you ? i'll need your help with the font coloring for the edubuntu splash before release
<fabbione> my sparc was in re-install me hard mode
<pitti> ogra: any chance to get to know by how much they have overflowed?
<ogra> pitti, http://people.ubuntu.com/~cjwatson/cd-build-logs/
<ogra> pitti, search for "CD 2 will only"
<infinity> I can do sparc on a buildd, if faure's chroots aren't set up for kernels.
<infinity> I just don't want to do i386 on the buildds, cause I'm using them all for OOo BS. :/
<infinity> And I know ronne is kernel-ready.
<infinity> Or, should be.
* infinity needs to put "beg Mark for faster buildds" on his TODO.
<infinity> Or beg HP for buildd donations, in the case of ia64 and hppa.
<pitti> ogra: thanks
<infinity> ogra: Yes, he talked to me.  I'll look at it shortly.
<ajmitch> "more hamsters needed"
<ogra> infinity, no hurry, just before release is fine ...
<simira> ajmitch: you can have my gerbils
<ajmitch> simira: ship them off to the data centre
<simira> ajmitch: do you pay for shipping?
<ajmitch> sadly not
<pitti> ogra: holy crap, 26 MB?
* ajmitch is just a poor developer :)
<dholbach> Kamion: http://daniel.holba.ch/ubuntu/gparted.patch is the MiB upstream patch
<ogra> pitti, dholbach uploaded a new example-content packge, look for the 26M of his private conference photos ;)
<pitti> ogra: ah, e-c might indeed be the culprit, yes
<dholbach> ogra: pffft
<ogra> :)
* mvo suspects its the hires picture of daniel on the beach
<dholbach> Kamion: oh, it seems there were other mib changes before :-/
<dholbach> Kamion: http://daniel.holba.ch/ubuntu/gparted2.patch too *urgh*
<ogra> mvo, "the tanned face of MOTU" ?
<Treenaks> why are .doc files thumbnailes, but .od* files not?
<seb128> Treenaks: .doc are?
<Treenaks> seb128: on my system, yes
<seb128> Treenaks: like you have the content display like for pdf?
<Treenaks> seb128: yes
<seb128> Treenaks: what mimetype has that .doc?
<Treenaks> seb128: application/msword
<ogra> Treenaks, apt-get remove microsoft-office ?
<Keybuk> woohoo!  I got my PowerBook to work! :)  http://people.ubuntu.com/~scott/DSC00012.JPG
<seb128> Treenaks: /desktop/gnome/thumbnailers/application@msword/command
<seb128> Treenaks: what do you have for that gconf key?
<ogra> Keybuk, "FORBIDDEN !!"
<Keybuk> ogra: too quick :)
<Treenaks> seb128: gsf-office-thumbnailer -i %i -o %o -s %s
<ogra> ehee
<ogra> shiny
<Nematode85> will dapper (final) include X11R7.1?
<seb128> Treenaks: it comes from gsf-office-thumbnailer then
<seb128> Nematode85: no
<ogra> Keybuk, but i think iBooks look rather compact comared to this :)
<Treenaks> seb128: ok.. but it looks weird, non-free formats are thumbnailed while free formats aren't (in example-content)
<seb128> Treenaks: dpkg -S gsf-office-thumbnailer ?
<Keybuk> ogra: the top of the CD drive was touching the CDs and preventing them from spinning
<Treenaks> seb128: libgsf-1: /usr/bin/gsf-office-thumbnailer
<Keybuk> so I bent it back into shape
<seb128> Treenaks: is that package a part of the standard install?
<ogra> Keybuk, broken by you or by apple ?
<Keybuk> ogra: assumedly whoever owned it before me
<Kamion> dholbach: ahead of you already on gparted2.patch :)
<ogra> ah, its a used
<Keybuk> it was an ebay job, so I can do powerpc testing
<ogra> one
<Nematode85> seb128: but will it at least be available a little later, as an update?
<Kamion> stripping it down a lot though
<seb128> Nematode85: no idea
* mvo wonders if it is intentional htat the openoffice.org desktop files seems to not have a german translation for the names 
<Keybuk> ok, let's see if it'll work when I put it back together
<dholbach> Kamion: historically gparted2.patch happened before gparted.patch - sorry for that
<Nematode85> seb128: btw, will we get any further flight before dapper final?
<seb128> Treenaks: that doesn't seem to be a part of the default installation
<Treenaks> seb128: it's in dapper/main.. libgoffice-1 depends on it.. an abiword-plugins too
<Kamion> dholbach: yep
<Treenaks> seb128: (which is probably how it got installed: abiword :))
<Kamion> dholbach: I'm working from CVS right now
<seb128> Treenaks: right, but now is not the moment to work on stuff not-installed by default
<seb128> Nematode85: no
<dholbach> Kamion: ok
<Treenaks> seb128: true
<seb128> Treenaks: https://launchpad.net/bugs/25827 on the topic
<Ubugtu> Malone bug 25827 in nautilus "Thumbnails for Openoffice.org documents" [Wishlist,Confirmed]  
<pitti> Kamion: I'll reduce langpacks on the alternate CDs to fix the overflow
<Kamion> ok
<pitti> it would mean that we have almost no langpacks on the ppc CDs any more, but on the others there should still be some left
<infinity> Poor PowerPC...
<ogra> Kamion, http://people.ubuntu.com/~cjwatson/cd-build-logs/edubuntu-daily-20060523.log doesnt indicate any oversizedness for me ... but amd64 and ppc have a bunch of uninstallables in http://cdimage.ubuntu.com/edubuntu/daily/current/report.html
<ogra> hmm, mighht be mvo's gimp upload causing this ...
<pitti> carlos: I just fixed vim
<ogra> ahhh, it was glib whichh wasnt built when the CD builds started :)
<janimo> mdz: UVF exception for xfdesktop svn? I had a 4 fixes locally including a crasher locally, and were taken by upstream. They also have 3 more bugfixes since our last upload.
<janimo> mdz, this goes in hand with a thunar workaround which I need to revert as is properly fixed in xfdesktop now. I can either apply a reverse patch, or sync thunar which is exact same codewise, but there is a new translation upstream as well.
<mdz> janimo: your call
<janimo> ok
<infinity> pitti: If you're on the po/pot fixing warpath, want to fix ktorrent for Riddell, since he doesn't seem to be around?
<mdz> infinity: how is oo.o looking?
<infinity> mdz: "not failed yet"
<pitti> infinity: package needs to build a pot? or what is wrong?
<infinity> mdz: I'm hoping that means "good".
<infinity> pitti: FTBFS due to empty .po
<pitti> infinity: ah, I see; yes, I'll look into it
<infinity> pitti: Much love to you.
* fabbione grabs some food
<fabbione> Kamion: kernels are building.. it shouldn't take too long from now
<mdz> infinity: has iwj acked that other ftbfs?
<infinity> mdz: No, I'll poke it in a sec.
<infinity> mdz: Just looks like a bad patch, but since I don't know the context of the patch, I preferred to defer to him before fixing it myself, that's all.
<ogra> is anybody needing lithium currently or can i trigger an edubuntu install build ?
* ogra sees infinity logged in
<mdz> iwj: ping
<infinity> ogra: Go nuts.
<infinity> ogra: I'm idle.
<ogra> yay :)
<carlos> pitti: ok
<carlos> pitti: how is that your buildd script didn't detect it?
<pitti> carlos: probably because I ignore vim translations, since vim doesn't use gettet
<pitti> s/t$/xt/
<carlos> pitti: are you completely sure?
<carlos> pitti: the .po file has references to .c code
<pitti> ===== Processing /home/lamont/public_html/translations/20060518/vim_6.4-006+2ubuntu5_i386_translations.tar.gz =====
<pitti> wasabi: vim_6.4-006+2ubuntu5: no mo and pot files, but po files
<pitti> wasabi: sorry, that was a "W:' in copy&paste
<mdz> Riddell: any word from jjesse about the chapter?
<seb128> pitti, carlos: is https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/46051 fixed by your changes from yesterday?
<Ubugtu> Malone bug 46051 in language-pack-gnome-es-base "Broken gnome-panel translations" [Normal,Unconfirmed]  
<pitti> carlos: well, it doesn't use translations from /usr/share/locale, but it's own homebrew system
<carlos> pitti: could it be a bug in the package?
<pitti> seb128: will check in a minute
* pitti forks three times more
<carlos> pitti: oh, that sucks...
<pitti> carlos: it's filed as a bug, but nothing for dapper ;)
<carlos> seb128: it should, yes
<carlos> seb128: well, but it was not included in latest language packs
<seb128> ok, let's wait for next update then
<seb128> carlos: alright
<carlos> pitti: what's filed as a bug?
<pitti> carlos: bug 30078
<Ubugtu> Malone bug 30078 in Baltix "vim package has all translations (look at /usr/share/vim/vim63/lang/) instead of using langpacks" [Normal,Confirmed]  http://launchpad.net/bugs/30078
<carlos> pitti: so they use .mo files
<carlos> pitti: should I export them as part of language packs?
<mdz> infinity: still very confused about this oo.o failure; the file referenced in the failing command doesn't even exist after a successful build
<mdz> ERROR description: Couldn't open registry file:///home/mdz/src/openoffice.org-2.0.2/ooo-build/build/oob680-m5/instsetoo_native/util/OpenOffice/services.rdb/en-US_inprogress_1/regcomp.rdb for reading
<mdz> .../OpenOffice doesn't even exist
<mdz> and there is no regcomp.rdb or services.rdb anywhere in the tree
<Riddell> mdz: got an e-mail from him "I know I'm working on getting it as quickly as possible."
<iwj> mdz: Hi.
<infinity> mdz: Are you hoping beyond hope that I have insight, or using me for wall debugging? :)
<mdz> infinity: I'm "collaborating"
<infinity> mdz: Cause the OOo build system is just as confusing to me as it is to you (and any rational human) :/
<iwj> What FTBFS ?
<infinity> iwj: ttf-freefont
<ajmitch> infinity: got any universe FTBFS info for us?
<iwj> ?
<infinity> iwj: I pinged you about it up there somewhere ^^^
<infinity> iwj: Looks like it's failing to apply a bad patch.
<mdz> oh, I see; that bit is run in the binary target, not build
<iwj> infinity: Oh, yes, so you did.
<infinity> ajmitch: I'll dump a big mbox somewhere in a sec... Hold on, while I get my headless chickens in order.
<iwj> infinity: Oh, FFS, cdbs.
<ajmitch> infinity: no problem, thanks for that
<iwj> I didn't edit any patch, I just edited the damn thing and now some _other_ patch doesn't apply.
<iwj> I'll sort it out.
<infinity> iwj: Thanks.
<Kamion> dholbach: is your gparted.patch strictly necessary? it seems to be primarily a UI change
<iwj> dbs should be an expletive.
<pitti> seb128: g-panel is fine now
<dholbach> Kamion: I hope it's not, the ChangeLog referred to a mb<->mib change
<pitti> seb128: i386 pot file is current and has the 'Book excerpt' stuff, too
<seb128> pitti: what I thought, but I had some language pack update this morning and they are still bugged
<pitti> mdz: ^ FYI
<Riddell> Kamion: could you do a kubuntu live fs build?
<pitti> seb128: actual translations are missing, that's known
<seb128> ok
<mdz> pitti: yay
<Kamion> Riddell: running
<iwj> mvo: 26436> Seveas already pointed it out to me earlier, thanks.
<pitti> infinity: ktorrent fixed, tested, uploaded
<infinity> mdz: Permissing to upload a MySQL with an init script verbosity fix (redirects more junk to syslog, instead of bouncing delayed background ops to the console)?  The current behaviour appears to royally piss off debconf on the install CD when the timing of certain postinsts is just wrong.
<infinity> s/Permissing/Permission/
<mdz> infinity: diff?
<infinity> mdz: Let me roll it into a package and diff it.  'sec. :)
<infinity> (was testing on my local install)
<Seveas> iwj, I also tried working on a real fix for it, but unfortunately my knowledge of the firefox build system is not enough
<mdz> pitti: the CDs don't look oversized to me; is DRR out of date?
<ogra> mdz, http://cdimage.ubuntu.com/daily/current/report.html clearly something is borken 
<mdz> indeed
<Kamion> mdz: you don't always get .OVERSIZED warning files unfortunately, depending on exactly what fails
<infinity> mdz: http://cerberus.0c3.net/~adconrad/mysql-dfsg-5.0.debdiff
<mdz> Kamion: I'm also looking at the file sizes
<mdz> Kamion: do you know what's causing the issues in report.html?
<pitti> mdz: I checked the logs, and a test install showed that some packages are  missing
<Kamion> mdz: remember that debian-cd has an inbuilt limit
<infinity> mdz: And if that's cool, I'd also like to merge with Debian SVN, where there's one more init script fix (free space check breaks in certain locales, fixed by specifying BLOCKSIZE), and some debconf translations.  Nothing else.
<Kamion> mdz: it overflows onto a second CD internally
<Kamion> mdz: one day I'll stop it doing that
<Kamion> mdz: grep for 'CD 2' in the build logs
<mdz> infinity: how much output can that script generate?
<iwj> seveas: Thanks, but yes, it's all a bit nightmarish.  I haven't decided for sure and will look at the build system but I suspect I wouldn't want to make the proper -rpath fix now.  It might be that gtkmozembed apps will have to use LD_LIBRARY_PATH :-/.  Shame we didn't discover this a week or two ago.
<mdz> oh
<Kamion> mdz: provisionally, I'd like to apply something like http://people.ubuntu.com/~cjwatson/tmp/gparted-upstream-resize-fixes.patch to gparted; the MB->MiB stuff and the improved NTFS tool handling seems rather important unfortunately
<infinity> mdz: Worst case?  Could be one line per DB table on a freshly-updated system.  Usually, it only produces a few lines.
<infinity> mdz: Concerned that I should buffer it and spit it back out to avoid overflowing?
<Seveas> iwj, how horrific is setting LD_LIBRARY_PATH in the (py)gtkmozembed initialization functions so you don't need to patch all (py)gtkmozembed applications?
<Kamion> I haven't tested that patch yet; it's my attempt at a reasonably minimal backport without the huge piles of rearrangements that have happened upstream
<infinity> mdz: I was going to slam it in a logfile, but the init scripts already output to syslog in other areas, so this was the path of least confusion.
<mdz> infinity: maybe better to pipe it into logger rather than use backticks?
<infinity> If logger reads from stdin...
* infinity tries.
<mdz> infinity: it does, and in fact it's used that way elsewhere in the init script
<infinity> Ahh, didn't notice that. :)
<infinity> Right pipe it is.
<Kamion> the changelog summary for gparted is basically:
<Kamion>     - Run a simulation before performing an NTFS resize.
<Kamion>     - Pass an exact byte count to ntfsresize, rather than a decimal megabyte
<Kamion>       count (which does the wrong thing).
<Kamion>     - Return failure from resize if suboperations fail.
<infinity> mdz: Silly me.
<mdz> infinity: does it actually break the installation of the package as it is now?
<infinity> mdz: It broke installation of my LAMP setup on some tries, but not others.
<infinity> mdz: Seems to really irritate debconf in other packages, when the output comes at just the wrong time.
<mdz> Kamion: gar
<mdz> infinity: ok, go ahead with it then
<infinity> Ahh, it's much happier with the pipe.
<iwj> Seveas: Fairly but I'll consider it :-).
<infinity> mdz: Okay to include the debconf translations and BLOCKSIZE fix while I'm uploading anyway?
<Seveas> iwj, ok, fun thing for me to work on
<mdz> infinity: the what?
<infinity> 04:38 < infinity> mdz: And if that's cool, I'd also like to merge with Debian SVN, where there's
<infinity>                   one more init script fix (free space check breaks in certain locales, fixed by
<infinity>                   specifying BLOCKSIZE), and some debconf translations.  Nothing else.
<Kamion> mdz: I can't exactly claim to be happy about it.
* Riddell starts a kubuntu live CD build 
<Kamion> Riddell: you what?
<Kamion> Riddell: weren't you waiting for the filesystem build?
<iwj> Seveas: Cool.  Don't be too long though.  I think I've pinned down this crasher I've been hunting and now there's just a few things left on my firefox todo list.
<ogra> heh
<Riddell> Kamion: looks like it's done no?
<Kamion> Riddell: not from here
<sladen> mdz: what was wrong with the 0.40ubuntu31 patch to add a message about resume?
<mdz> Kamion: what's "the wrong thing" in this case?
<Kamion> Riddell: only ia64 is done, and that failed
<ogra> Riddell, you need more sleep, keep the sleepless nights for end of the week :)
<iwj> Seveas: Note that this LD_LIBRARY_PATH setting should be in the gtkmozembed init function (in firefox) and not in the py... one, since the latter would only fix Python apps.
<iwj> If you don't want to tackle this do say and I'll put it on the end of my list.
<mdz> sladen: the script doesn't have any knowledge about whether there is actually a resume pending, and initramfs doesn't have the tools to check
<Riddell> Kamion: right I see, I'll be patient
<Seveas> iwj, I'd figured that
<infinity> mdz: ^^^
<Seveas> iwj, and I'm already tackling it
<Kamion> mdz: ntfsresize expects binary megabyte, gparted was passing decimal megabyte ... but then gparted would try to actually resize the physical partition and the filesystem would end up not matching the size of the partition because the units were different
<Kinnison> Kamion: Ye gods that's nasty
<mdz> infinity: sounds reasonable, but I still want to see the diff first
<infinity> mdz: Kay.  'Sec.
<mdz> Kamion: partitions can't be on decimal megabyte boundaries anyway, can they?  they have to be on a cylinder boundary
<sladen> mdz: would be happy if I add it back in along with a check for the signature "SWAPSPACE2S1SUSPEND" at offset 4076 of the device we are about to echo into /sys...
<Kamion> mdz: yes, it rounded
<mdz> Kamion: so would it round and get it wrong only some of the time?
<Kamion> mdz: the archaeology is a bit hard, but I believe so
<mdz> sladen: after the release, yes
<pitti> mdz: current tetex-base has broken hyphenation (see bug 36145 a dn duplicates); I verified that debian's -16 fixes this
<Ubugtu> Malone bug 36145 in tetex-bin "hyphenation does not work after upgrade from breezy to dapper" [Normal,Unconfirmed]  http://launchpad.net/bugs/36145
<infinity> Oh crap, that never got merged?
<pitti> mdz: http://changelogs.debian.net/tetex-base has a reasonable changelog
<infinity> That one crossed my radar for all of 20 seconds several weeks back.
<pitti> infinity: it occured to me just now, since an user mailed me for help
<Kamion> Riddell: sorry, you should probably look at /current/ rather than /latest/
<Kamion> Riddell: /latest/ lists the builds in progress; /current/ lists the last successful build
<Kamion> s
<pitti> mdz: can we sync -16? (we shouldn't take -17, it removes some documentation)
<sladen> mdz: if I come up with a patch that is a one-line delta from yours and which works, would you be happy allowing that?
<mdz> pitti: except that half the archive build-depends on it
<mdz> pitti: let's defer that one to dapper-updates
<iwj> Seveas: Excellent, thanks very much.
<pitti> mdz: ok
<mdz> sladen: it's a cosmetic problem (one which no one except me seemed to care about for months) and involves touching a highly criical package
<mdz> critical, even
<iwj> Seveas: when you're ready, it's probably easiest if you mail me (iwj@ubuntu.com) your diff.
<mdz> sladen: it's a candidate for dapper-updates
<Seveas> will do
<Riddell> Kamion: ok
<sladen> mdz: it's only recome relevant in the fortnight, because there is no longer a console change as soon as it starts.  Formerly, the usplash disappeared immediately and was replaced with the kernel text-based progress-bar.  10 Minutes ago was the first hibernate test I did since that change and it caused me to file a bug immediately;  and itched me enough to fetch the source (which showed me your change log, reverted yesterday)
<mjg59> sladen: Massively longer than a fortnight
<sladen> mjg59: which kernel?  That's the first hibernate I've done where it hasn't switched to text-mode
<mjg59> sladen: http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commit;h=73879f0a8da7ec3efd0715f6df3dd7a12a53addc
<sladen> mjg59: -pm_restore_console();  ta
<Kamion> mdz: I'll see if I can do some vmware snapshot magic to test out NTFS resizing before-and-after that change on the exact same filesystem
<Kamion> (which I deliberately unmounted uncleanly for good measure)
* Kinnison ponders going for lunch
<infinity> mdz: http://cerberus.0c3.net/~adconrad/mysql-dfsg-5.0.debdiff  <--- New debdiff, piping to logger instead, and with added faff.
<infinity> mdz: And the BLOCKSIZE thing was in the preinst, not the init script, my bad.  So it's even nastier than I originally thought.
<Riddell> we're still OK to upload fixes to universe yes?
<dholbach> Riddell: yes, the motu crew is still working
<infinity> Riddell: Yes, if MOTU is cool with it.
<fabbione> dholbach: can i push a patch to the MOTU guys?
<infinity> Riddell: I wouldn't just go uploading random packages without poking -motu. :)
<Mithrandir> sivang: my power5 doesn't like me.
<dholbach> fabbione: sure
<fabbione> shawarma: you have it in your inbox..
<fabbione> dholbach: ^^
<dholbach> fabbione: hm?
<fabbione> i just fw it to you
<fabbione> the patch
<dholbach> fabbione: why do you send it to me? and not to them?
<fabbione> because i don't know their email address??
<dholbach>  ubuntu-motu@lists.ubuntu.com ? :-)
<fabbione> and you are still my favourite motu's face ;)
<pitti> mdz: permission to upload http://paste.ubuntu-nl.org/14547 ?
<pitti> mdz: this patches a patch, so it's a bit ugly to read, sorry
<Kamion> infinity: any idea what's going on with the Kubuntu livefs build on terranova? seems to have hung
<infinity> Kamion: I'll go look.
<Kamion> ta
<Mithrandir> mdz: there's a new nvidia driver out, which in addition to adding support for some minor gfx cards fixes a problem where using two LCDs on DVI hardlocks the system when X starts.  At least their changelog seems to hint in that direction; I'll test it later today.
<Mithrandir> mdz: so, any chance of a UVF exception?
<infinity> Kamion: mksquashfs claims to still be running..
<infinity> Kamion: And indeed, it is.  I just saw more output (thanks, Mithrandir!) in the log.
<infinity> mdz: If that diff is okay, I'd like to upload it before I run off to buy some dinner before the stores all close...
<Kamion> infinity: ok, thanks, I guess it was just busy
<Kamion> http://people.ubuntu.com/~lamont/liveLogs/dapper/ubuntu/latest/livecd-20060523-i386.out <-- very broken though
<Kamion> why doesn't it like language-pack-fi?
<Kamion> ah, that's this morning's log ...
<Mithrandir> hmm, should we possibly turn off automatic livefs and cd builds?
<infinity> Probably.
<Kamion> not yet, but soon, I think
* infinity runs off to buy stuff before the grocery store closes and leaves him hungry.
* Kamion rebuilds Ubuntu livefses since this morning's were obviously dodgy
<fabbione> Kamion: we are almost there with the kernel.. waiting x86* to finish
<ogra> fabbione, are there any known probs with mac mini G5 machines ? i have a report about a failed edubuntu install
<fabbione> ogra: give me one and i will test it :)
<fabbione> ogra: also. please ask these people to file bugs on lp
<fabbione> with all the proper info
<fabbione> it's not the first of the last time that a bug in foo is assigned to kernel or X
<fabbione> because people just do NOT know
<ogra> <pips1> basically, the last error is ERROR: The file 'dev/pmu' doesn't exist. 
<ogra> <pips1>     [fail] 
<ogra> looks very much like kernel
<ogra> it doesnt even boot
<fabbione> looks very much like something that is not kernel related... 
<fabbione> if it boots and can install and get tehre... 
<ogra> i sent him to -kernel
<ogra> ah, k
<fabbione> dev/pmu is create by udev
<fabbione> or should be
<ogra> yep
<ogra> indeeed
<pitti> oh, crap; ppc/ubiquity install failed to create file system on 'erase entire disk'
<ssam> ogra, mac minis are g4 or intel. typo?
<ogra> ssam, nope
<Mithrandir> pitti: did you have LVM on that machine already?
<pitti> Mithrandir: no, never
<ogra> there is one g5 series
<pitti> Mithrandir: there was previously a broken apple bootstrap partition, that's why I erased the entire disk
<pitti> Mithrandir: (or, rather, asked it to do that)
<Kamion> fabbione: that's just the test run, right?
<fabbione> Kamion: yes
<Kamion> ok
<fabbione> but as it is now we could just upload
<Kamion> pitti: bug#?
<pitti> I didn't install with verbose logging, will do it again now
<fabbione> i only want to make sure this will hit archive 100%
<pitti> Kamion: it just happened to me now, I'll look if it's already reported
<Kamion> pitti: /var/log/partman might be enough
<fabbione> well.. modulo ia64/hppa that i am not testing
<Kamion> pitti: I'd rather have a new bug anyway, please
<ssam> ogra, there was a imac g5, but i'm pretty sure not a mini
<ogra> ssam, ah, sorry, it was an imac ... i muddled that
<ssam> ogra, ok :-)
<carlos> pitti: hi, around?
<pitti> hi carlos
<carlos> pitti: the tuxpaint-stamps .pot file is completely broken
<carlos> it has a bunch of duplicates
<mdz> Mithrandir: sounds like a dapper-updates candidate
<mdz> infinity: I was at lunch
<mdz> pitti: nagios fine
<mdz> infinity: mysql-dfsg-5.0.debdiff OK
<mdz> Kamion: I don't know what to say about this gparted patch
<pitti> Kamion: filed 46135
<pitti> Kamion: shall I leave the system alone for now, in case you want to know anything else?
<Toadstool> hi everybody! what do you think about bug 45639? (mvo ? :))
<Ubugtu> Malone bug 45639 in libgksuui1.0 "When prompted to type in root password, right clicking causes carrot to permanently disappear" [Major,Confirmed]  http://launchpad.net/bugs/45639
<pitti> Kamion: hm, might be PEBCAK in the end, see my last comment
<fabbione> Toadstool: Major???
<Toadstool> fabbione: I didn't change the status, Sebastian Heinlein did
<fabbione> that's at the best Normal
<ogra> carrot ? 
<ajmitch> fabbione: more bug inflation, prices are rising
<fabbione> ajmitch: yeah
* ogra looks fo a carrot on his desktop
* Mithrandir looks for a carrot in his garden
* fabbione thinks that ogra needs a carot to walk...
<Toadstool> :)
<ogra> :P
<ogra> :)
<simira> Mithrandir: what garden?
* mvo considers lunch now that carrots are brought up
<Mithrandir> simira: the beach in our backyard.
<Keybuk> Mithrandir: usplash vanished on PowerPC LiveCD
<infinity> mvo: Both carrots and lunch were brought up, actually.  It's my cure to cook what I just bought.
<infinity> mdz: Thanks, uploaded.
<Keybuk> pretty much, fwict, before it started booting the main system
<Mithrandir> Keybuk: vanished as in?
<Keybuk> Mithrandir: did "Configuring X", screen went black with flashing cursor
<Mithrandir> Keybuk: X broke your ppc, then.
<Keybuk> stayed like that for a while, then "Preparing restricted drivers..." came up on console
<sladen> Keybuk: ogra was saying something like that yesterday;  I guess that explains why omeg was getting so perplexed
<Mithrandir> Scott, meet Fabio, Fabio, meet Scott
<Mithrandir> :-)
<Keybuk> interestingly, X doesn't seem to want to use all of the display
* Mithrandir hides
<Keybuk> it's got a black bar down the *right* hand side
<Mithrandir> Keybuk: seriously though, I just call dpkg-reconfigure xserver-xorg
<mdz> Kamion: what's upstream's opinion of pushing it in at the last minute?
<Kamion> mdz: I haven't talked with upstream
<Kamion> was mostly prompted by various rather panicky-sounding bugs I came across recently
<Kamion> though not with sufficient actual detail to figure out what was going on, so I started investigating myself and got worried by the obvious brokenness of the current code
<Kamion> mdz: there's one more conservative option available I think, which is to just take the portion of the patch that does a simulation run of ntfsresize before doing resizing proper
<Kamion> that way we at least apply some extra insurance to resizing
<Keybuk> fabbione: http://people.ubuntu.com/~scott/DSC00013.JPG
<Keybuk> (note where the screen starts and ends, horizontally)
<ogra> take a saw
<fabbione> Keybuk: yes i can see.. is the config correct?
<fabbione> Keybuk: compared to previous run?
<fabbione> oh hold on
<Keybuk> fabbione: this is the first run I've done
<fabbione> what chipset is that?
<Keybuk> fabbione: "PowerBook G4"
<fabbione> yes i can read that.. what ATI chipset is that one?
<fabbione> can you give me an lspci -n ?
<Keybuk> not sure, trying to find the | key :p[
<Keybuk> "ATI Rage Mobility M3 AGP 2x (rev 02)"
<fabbione> can you give me an lspci -n ? <-----
<Keybuk> 1002:4c46 (rev 02)
<fabbione> please??
<fabbione> thanks
<mdz> Kamion: it's not as bad as its hugeness made me guess
<Keybuk> xdpyinfo says it thinks the display is 1024x768
<mdz> Kamion: but it's not practical to judge whether it's correct; there could be further changes which are missing
<seb128> mdz: could we get a milestone for dapper-update maybe? To mark bugs that would be nice to fix to -update later
<mdz> seb128: I've been adding to DapperReleaseRadar
<Kamion> mdz: I agree, I can't say I'm comfortable with it
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/gparted-upstream-ntfsresize.patch is just the ntfsresize handling changes
<seb128> mdz: ah, right ... still would be handy to have a launchpad milestone ;)
<Kamion> er
<Keybuk> fabbione: xresprobe ati -- blanks the screen, and then just says "id:\nres:\nfreq:\ndisplaytype: lcd/lvds"
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/gparted-upstream-ntfsresize-fixes.patch
<fabbione> Keybuk: can you please try to disable UseFbDev in xorg.coinf?
<mdz> seb128: done
<seb128> mdz: thank you
<fabbione> Keybuk: you need to exit from X to run xresprobe
<Keybuk> fabbione: I did that, obviously
<Keybuk> Xorg.log during xresprobe says "Video BOIS not detected in PCI space!"
<fabbione> exit as in kill...
<fabbione> that's ok
<fabbione> can you please change that config option?
<fabbione> from true to false
<Keybuk> right
<Keybuk> and just start gdm again?
<fabbione> well whatever makes that black border
<mdz> Kamion: I'm fine with that patch at least
<Keybuk> fabbione: no difference
<fabbione> Keybuk: can you please slam config and logs somewhere?
<fabbione> Keybuk: also.. if you have the specs for that machine to see what res it expects
<Keybuk> which config and logs would you like?
<fabbione> xorg.conf and Xorg.0.log ?
<Keybuk> ok, will make a fresh live session
<Keybuk> I imagine the res it expects is the same as any other PowerBook
<fabbione> Keybuk: well we usually detect it with xresprobe
<fabbione> that's why.. it might have wrote down the wrong config
<fabbione> Keybuk: please be as fast as you can.. i have upstream already waiting for the logs
<Keybuk> interweb says res should be 1152x768
<fabbione> Keybuk: and what's in the config?
<Kamion> pitti: was "Creation of file system failed" (#46135) the exact error message?
<Keybuk> fabbione: 1024x768
<pitti> Kamion: it was in German, but I think so
<pitti> Kamion: btw, after unmounting /dev/hda6, it seems to work now (still in progress)
<fabbione> Keybuk: well that explains.. can you try to just fix the config?
<pitti> Kamion: so that should be converted to a minor bug saying that mounted file systems shuold be unmounted before repartitioning
<Keybuk> fabbione: how does it explain it/
<pitti> Kamion: I'll update the bug when the current installation finished
<Kamion> pitti: what was the German message?
<fabbione> Keybuk: that if the config is wrong you get the wrong resolution. AFAIK PB doesn't scale
<Kamion> I'm trying to track down exactly where it came from
<fabbione> scale to fit i mean
<Keybuk> fabbione: but the config shouldn't be wrong
<Keybuk> it was autogenerated
<fabbione> Keybuk: can we please go one step at a time?
<fabbione> Keybuk: i did ask you to fix the config and check
<mdz> Kamion: having stared at it for a while longer, if it builds -Wall clean then let's do it
<Keybuk> fabbione: first let me get the current set of logs and current config online
<Keybuk> it's just finishing booting again
<fabbione> Keybuk: i assume this is today's live cd
<fabbione> or is it an older one?
<Kamion> mdz: there are some warnings from /usr/include/gtkmm-2.4/gtkmm/treeview.h and an old warning in Win_GParted.cc, but both are unrelated
<Keybuk> fabbione: today's
<Kamion> mdz: I'm trying to reproduce the problem here
* infinity eats lunch.
<infinity> mdz: FYI, both OOo and OOo-l10n are still building... Cross your fingers.
<Kamion> vmware snapshots are fabulous
<pitti> Kamion: darn, I don't remember exactly any more. In which package's PO file is this?
<mdz> infinity: how long have they been building now?
<Kamion> pitti: that's what I'm trying to work out ;-)
<pitti> darn, sorry
<Kamion> pitti: it'll be somewhere in ubiquity/d-i/source/partman*, I expect
<Keybuk> fabbione: http://people.ubuntu.com/~scott/mac-problems/
<Keybuk> fabbione: that's the generated log and conf file
<fabbione> Keybuk: checking
<pitti> Kamion: I can't find the string anywhere in ubiquity source now; I can reproduce the issue later and check again
<fabbione> Keybuk: can't fix 
<fabbione> (WW) R128(0): Can't determine panel dimensions, and none specified.
<fabbione> 	Disabling programming of FP registers.
<fabbione> not for live at least
<mdz> Kamion: I only get the Win_GParted.cc warning
<fabbione> you get asked for the resolution on alternate
<Keybuk> fabbione: I didn't ask for anything?
<Keybuk> what's "alternate" ?
<fabbione> Keybuk: new policy says that we are not allowed to ask questions on LiveCD
<Keybuk> fabbione: dude, this is a PowerBook ... they're practically standard equipment
<Keybuk> are you seriously telling me that the PowerPC live CD won't work properly?
<fabbione> Keybuk: if your panel doesn't return info there is nothing i can do
<fabbione> Keybuk: alternate -> see u-d-a about renaming CD
<fabbione> Keybuk: it could even be your panel that's broken
<fabbione> or an older modle
<fabbione> model
<fabbione> works fine here
<fabbione> mine does return the info
<Keybuk> it's a not unreasonably old model
<Riddell> hmm, kubuntu amd64 live CD has magically grown by 40MB
<ogra> woah
<fabbione> Keybuk: and the concept of standard is crap like it is for x86. Apple did upgrades internal stuff across time
<ogra> 40 ?
<fabbione> Keybuk: like they did with mine
<Keybuk> changing the resolution in xorg.conf didn't work
<Keybuk> X ignored it and used 1024x768 anyway
<fabbione> Keybuk: you will also need to fix the HorizSync and VertFresh
<ogra> Keybuk, modeline ? 
<ogra> yeah or what fabbione said
<Keybuk> dude, the LiveCD should do this!
<Mithrandir> Keybuk: does ddcprobe return useful values?
<Mithrandir> Keybuk: no, it shouldn't since that breaks installs from live cd.
<fabbione> Mithrandir: no it doens't.. 
<fabbione> <Keybuk> fabbione: xresprobe ati -- blanks the screen, and then just says "id:\nres:\nfreq:\ndisplaytype: lcd/lvds"
<Riddell> ogra: yes
<Mithrandir> Keybuk: casper.log svp?
<Keybuk> Mithrandir: what would be "useful values" from ddcprobe?
<Mithrandir> Keybuk: the resolution you expect as well as sane frequency information
<ogra> Riddell, thats heavy ... did pitti add your langpacks back secretly ? 
<Keybuk> Mithrandir: neither of those are returned by ddcprobe
<Riddell> oh, I added de to language-support, that'll be it
<Keybuk> there aren't even empty fields for them
<Mithrandir> Keybuk: what does casper.log look like, then?
<Keybuk> Mithrandir: http://people.ubuntu.com/~scott/mac-problems/casper.log
<Kamion> Riddell: I recommend never adding anything but en to language-support
<Riddell> less learnt :)
<Riddell> lesson
<infinity> mdz: Just around 6.5 hours... So... They'll fail soon... Or not.
<infinity> mdz: Oh, crap.  OOo just failed.  Karma.
<mdz> infinity: well at least we have a build tree where we can try to reproduce now
<mdz> right?
<pitti> ogra, Riddell: I didn't touch the kubuntu seeds
<infinity> mdz: Oh well, at least i have a build tree to play with now.
<mdz> infinity: I wouldn't mind a copy of the log
<infinity> mdz: Yeah.  I'll play after I'm done eating lunch.
<KaiL> Xorg 7.1 is raus - mit AIGLX ;)
<mdz> infinity: not the useless output from the build, but the log file it mentions in the error message
<infinity> mdz: Yeah, I'll pass you the log, and tar up the tree too.
<KaiL> oops, wrong window
<Kamion> mdz: I may have to take this back. I can't reproduce any difference between gparted before and after.
<ogra> pitti, i was kidding :)
<Kamion> (on the upside that means the backport works)
<pitti> Kamion: hm, the ubiquity part succeeded, but boot fails with '/pci@...,/boot/vmlinux: Unknown or corrupt file system'; not my day, I suppose
<ogra> pitti, indeed you didnt
<Kamion> pitti: am I lucky enough that that was with debugging?
<infinity> mdz: You don't want the log.  I'll give it to you anyway, but it's useless at first glance.
<Kamion> pitti: and does the OF path in that error message look right?
<Kamion> pitti: and can you mount the file system from the live CD?
<pitti> Kamion: disk@0:4 is /dev/hda4? that might be the swap partition, I thought /dev/hda3 was /
<pitti> Kamion: will check
<mdz> infinity: it doesn't contain the output which was redirected 2>&1 from the failing command?
<lifeless> Kamion: what are usful diagnostics when the livecd (current) fails to setup a working X?
<infinity> mdz: http://vernadsky.buildd/~adconrad/
<pitti> Kamion: no debugging, I didn't stop and start ubiquity after unmounting the device; I just did partitioning again
<fabbione> Kamion: missing the docs on x86, otherwise we are there :)
<Kamion> pitti: partitions are 1-based from yaboot, yes
<lifeless> Kamion: friend of mine on his work machine, does not have IRC from his office.
<Kamion> lifeless: /var/log/casper.log, /var/log/Xorg.0.log, I believe
<Kamion> fabbione: what happened to the docs?
* infinity goes back to lunch/dinner.
<pitti> Kamion: oh, I think I know what's wrong - yaboot also offers me hda7-Linux, which doesn't even exist any more, and /dev/hda4 was my old /
<fabbione> lifeless: xorg.conf, output from xresprobe $driver and lspci -n + a bug in LP please
<pitti> Kamion: so I think it didn't install yaboot
<Kamion> pitti: so yaboot installation failed
<fabbione> Kamion: nothing.. it's building the docs now...
<fabbione> Kamion: nevermind. installing now :)
<fabbione> lifeless: + what Kamion said
<Kamion> pitti: damn, that means it probably didn't save the logs either
<Kamion> I'm really tempted to add a last-minute fix to at least detect errors from install.py and tell the user, even if the message isn't translated and isn't very helpful
<Kamion> mdz: ^-- ?
<Riddell> pitti: language-pack-kde-tl-base lacks the needed entry.desktop file
<pitti> Riddell: if you have one, I can quickly upload just this one
<Riddell> [KCM Locale] 
<Riddell> Name=Tagalog
<Riddell> voila
<Riddell> there isn't one in KDE's SVN
<mdz> Kamion: I thought you did something similar already?
<Kamion> mdz: for everything but crashes from install.py
<mdz> Kamion: I'm happy to review a patch
<fabbione> Kamion: x86 is go
<Kamion> preparing one
<fabbione> Kamion: uploading...
<Kamion> fabbione: thanks
<fabbione> Kamion: no problem.. thanks Ben for the release.. i just did the builds and smoothed a couple of corners
<pitti> Riddell: alright, I'll add it
<Riddell> pitti: thanks
<Riddell> carlos: shall I post to KDE translators about rosetta?
<infinity> mdz: I'm tarring up the failed chroot so I can mangle it and return to the point of failure... Will start investigating after that.
<mdz> infinity: good plan
<carlos> Riddell: don't worry about it, I'm writting the annoucement email for the whole dapper archive
<omeg> Hi there.
<Riddell> carlos: oh cool
<omeg> Not a whole lot going on here.
<omeg> I'm a little bored at work.
<iwj> Kamion: Can I delete that test yaboot stuff from the other day or might we need it again ?
<Kamion> iwj: could you keep it for a while?
<Kamion> I suppose I should have taken a copy
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-install-crash.diff
<pitti> Riddell: uploaded
<mdz> Kamion: fine with me
<j^> these subpixel font rendering patches <http://turnerdavid.neuf.fr/freetype/patches/font-patches.html> are realy nice
<iwj> Kamion: sure.  I was just having a tidy up.
<Kamion> mdz: mistake in the kde-ui bit; updated
<pitti> Kamion: there's no /etc/yaboot.conf on the installed partition
<mdz> Kamion: ah, right. ok
<pitti> bah, and neither an installer nor partman log
<mdz> BenC: it is time to start taking the kernel freeze seriously.
<Kamion> pitti: yeah, logs are copied afterwards unfortunately
<Kamion> after yaboot installation
<pitti> Kamion: I guess the best I can do is to reattempt the installation with verbose logging and save the logs right away
<pitti> before rebooting
<Kamion> pitti: yeah, I was just about to ask for that
* pitti does that
<Kamion> pitti: the fix I'll upload once I've tested it will mean you won't be able to miss this sort of failure by accident again
<BenC> mdz: Yeah, this mess from yesterday on was unfortunate
<pitti> hi BenC 
<ogra> hmm
<BenC> hey pitti
<pitti> BenC: any chance to add the missing CVE numbers to the next upload? I also added more stuff to https://wiki.canonical.com/KernelSecurity (some trivial, but important fixes)
<BenC> pitti: I have all those updates, just checking the new ones now
<ogra> Kamion, did edubuntu not get a new livefs in last nights build ? i still have the old usplash on my recent isos
<Kamion> ogra: dunno, check the logs
<mdz> BenC: yes, this is the reason why the deadline was last week rather than this week
<pitti> BenC: the new ones are starting from CVE-2006-1528 downwards on that page
<Kamion> http://people.ubuntu.com/~lamont/liveLogs/dapper/edubuntu/current/livecd-20060523-i386.out says usplash 0.2-4
<Kamion> ogra: oh, there just hasn't been a CD build since the livefs build. the cron job timings are perhaps unfortunate
<Kamion> ogra: feel free to start one
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-install-crash.png <-- result
<infinity> I wonder if that tar will ever return...
<infinity> ogra: I'm going to poke at your usplash right now.  What was the complaint, exactly?
<Kamion> and the actual reason install.py crashed shows up in /var/log/installer/syslog
<mdz> Kamion: the word wrap on the URL is unfortunate
<mdz> Kamion: maybe just leave off +filebug since there's a "Report a bug" link on /ubiquity/
<mdz> or make the window wider
<infinity> Or make it /+bugs, since they'll get to see all the duplicates beforehand. :)
<Kamion> https://launchpad.net/distros/ubuntu/+source/ubiquity/ is a little overwhelming to the uninitiated
<ogra> KaiL, oki
<ogra> err
<ogra> s/KaiL/Kamion
<Kinnison> Kamion: Hehe
<KaiL> ;)
<ogra> infinity, the fontcolors are wrong
<Kamion> I'll see if I can make it wider somehow
<mdz> Kamion: don't sweat it; it's fine as-is if that's not trivial
<infinity> ogra: Kay.  Poking.
<ogra> infinity, i have a white progressbar background with a yellow bar, dark brown font scrolling and no sight of ok or failed messages at all
<ogra> infinity, intrestingly there is no white defined at all according to omeg
<infinity> ogra: Okay.  omeg sent me the right colours in /msg, so I may just have to reindex the palette for you.
<ogra> yep
<infinity> ogra: I'll look anyway.
<sladen> Kamion: could you get the installer-crash dialogue to copy all the files it needs onto the desktop
<Kamion> sladen: not for dapper
<ogra> sladen, would you make the effort to set up a mail account on a liveCD to send these files if you're annoyed already that it didnt work ?
<Kamion> sladen: plus I want to do as little as possible in the crash handler
<Kamion> sladen: I would generally appreciate a reduction in the density of random ideas at the moment, btw :)
<Kamion> now is not the best time
<infinity> ogra: Uhh, the PNG you're shipping isn't the one omeg gave you....
<infinity> ogra: That could have something to do with the problem.
<ogra> infinity, yep, i didnt have any other, wasnt aware there were many changes
<infinity> ogra: I'm confused.  You had his latest copy in edu_FIXED_retry.png in the root of your package, but didn't actually use it in art/usplash.
<ogra> oops
<infinity> ogra: So, is it the stuff in art/usplash that's broken, or the one he sent you? :)
<ogra> i forgot to clean up, its copied into art/usplash as well
<infinity> ogra: Anyhow, I have it all sitting here now, let me test locally and I'll upload what works. :)
<ogra> it should be the same png all over
<infinity> ogra: No, it's not copied.  Those images are different (diff doesn't lie, and the palettes are different too)
<ogra> i just didnt clean up the source package
<ogra> hmm, k
<ogra> then i was probably to tired, sorry
<infinity> Anyhow, let me test with his and see how it looks.  If it looks cool, I'll just upload what I have here.
<ogra> yep
<infinity> ogra: Figured I'd fix your clean target while I was at it..
<ogra> :)
<ogra> whats wrong with it ? 
<ogra> (admittedly i didnt change anything in the packaging since i created the package based on the old ubuntu-artwork)
<infinity> ogra: Doesn't delete usplash-artwork.png, so you end up with two copies of the PNG in the source.
* janimo just realizes that for some unexplained reason his clock is in UTC, and tarballs 3 hours in the future cause FTBFS on the build servers
<ogra> infinity, oh, i thought that was intentional *g*
<_ion> Now that the "Ubuntu Dapper Beta" text was removed from the Ubuntu Lagoon wallpaper, it looks nice scaled to the 8:3 aspect ratio i'm using. :-)
<Kinnison> mdz: Is http://people.ubuntu.com/~dsilvers/acpi-support_83-84.debdiff okay for me to upload?
<mdz> Kinnison: sure
<Kinnison> cool
<mdz> Kinnison: "Uknown" isn't a typo?
<Kinnison> Nope
<Kinnison> It's what comes out of dmidecode
<Kinnison> gotta love gash laptop manufs
<_ion> Hehe.
<seb128> mdz: http://people.ubuntu.com/~seb128/shared-mime-info.debdiff ok to upload?
<_ion> It probably would be a good idea to add a comment about that string.
<_ion> # "Uknown" is not a tpyo
<Kinnison> _ion: true :-)
<seb128> mdz: we didn't have the alias before and it used to work fine, dropping it seems to be fine and workaround the issue
<Kamion> mdz: I can't manage to make the URL not wrap without making the filenames wrap in turn. I'll just leave it as-is.
<mdz> seb128: why was the alias added; does it serve a purpose?
<mdz> Kamion: no worries
<Kinnison> _ion: thanks for the suggestion
<mdz> Kamion: I now have an XP install in VMWare for testing purposes so I can fiddle with gparted a bit
<mdz> ick, the gnome-power-manager reconfig adds a good 10 seconds to live CD boot
<mdz> we should minimize that after dapper
<seb128> mdz: I'm not sure of why upstream added the alias, the ChangeLog has no detail about it. Looks like upstream added aliases and sub-classes information where it made sense, but that particular change confuse gnomevfs. We had shared-mime-info without it previous cycle and it's not likely that dropping it would create an issue
<mdz> seb128: ok, thanks.  fine to upload
<seb128> thank you
<hunger> What are my chances of seeing the shutdown-after-resume regression fixed in dapper?
<hunger> Whom do I need to promise a beer to improve them? ;-)
<Lure> Kinnison: can you whitelist HP nw8240 too (only minor glitch on resume on some models - see bug 33827)
<Ubugtu> Malone bug 33827 in acpi-support "suspend to RAM does not work on HP nw8240" [Normal,Needs info]  http://launchpad.net/bugs/33827
<Kinnison> Lure: let me read that bug, one se
<Kinnison> +c
<mdz> Kamion: hmm, just tried an ntfs resize with that patch applied and it failed
<Kinnison> Lure: that bug doesn't look desperately positive
<KaiL> huh? nonworking STR is worth a model specific bug? How many bugs do you want? ;)
<janimo> infinity: can a build which failed but should work now w/o changes be kicked or does it need an explicit reupload for this?
<Kamion> mdz: anything in /var/log/installer/syslog saying why?
<iwj> Did I miss the introduction of some magic thing that edits .desktop files with data from Rosetta ?
<janimo> tarball had timestamp in the future
<mdz> Kamion: no, I'm trying it from the command line to see if I get any output from gparted
<seb128> iwj: that magic is some months old
<mdz> Kamion: (unless you have it going somewhere else)
<mdz> the error dialog was unhelpful
<seb128> iwj: it was a proper dapper spec and pitti has described changes made to the weekly meetings I think
<Kamion> iwj: it doesn't edit them magically, but the code that reads .desktop files looks in language packs for extra translations
<infinity> janimo: I can smack it.  What build?
<janimo> infinity, thunar and xfdesktop
<Kamion> mdz: not somewhere else, no; although gparted does act a little differently when called from the installer. hopefully not relevantly
<janimo> thanks
<sladen> Lure: 32785 was fixed a while back.  Can you get the latest packages and check that it works.  If it does, then we can white-list it
<iwj> I have a bug report (Mlaone 45447) which has a diff for a Polish translation, and it's against a .desktop file which isn't one I've ever shipped.
<Lure> Kinnison: other users have no problems - I was one of the rare one's with nw8240 that had this problem, but works with workaround (lid close/open)
<infinity> janimo: In the future, try to avoid working in the future. :)
<Lure> sladen: it works, but only after close/open lid workaround (Kubuntu up-to-date, will text Ubuntu thsi week)
<seb128> iwj: language packs don't ship new .desktop, the changes are just for stuff using glib
<janimo> infinity: yep :).  My clock only changed to UTC today, no idea why.
<seb128> iwj: the change consist to make glib use gettext to get the translation before looking to the .desktop
<iwj> So (a) where did this user get the old .desktop file and (b) where shall I have them send their translation ?  Or should I just take their translation and add it to my file ?
<seb128> iwj: what bug #?
<iwj> Malone 45447.
<Ubugtu> Malone bug 45447 in firefox "Add Polish language to .desktop files" [Normal,Confirmed]  http://launchpad.net/bugs/45447
<Lure> sladen, Kinnison: will test Ubuntu today and report back and then we can decide if it is time left to sneak it in ;-)
<seb128> iwj: $ grep "Firefox Web Browser" /usr/share/applications/*
<seb128> /usr/share/applications/firefox.desktop:Name=Firefox Web Browser
<seb128> firefox: /usr/share/applications/firefox.desktop
<iwj> Yes ...
<seb128> hum
<iwj> Note that their diff has  < Name[pl_PL] =Firefox Web Browser   etc.
<seb128> iwj: you have to edit the source package to add Name[pl] =Przegldarka WWW Firefox
<iwj> So obviously something odd is going on.
<mdz> Kamion: ooh, nice
<Kamion> mdz: https://wiki.ubuntu.com/CodeNamesToVersionNumbers seems to imply that we want to remove "Dapper Drake" (and for that matter "Breezy Badger" etc.) from synaptic's repository names; is that true?
<seb128> no, diff is fine
<mdz> Kamion: I get an empty dialog box with title "Error"
<iwj> seb128: That's what I've generally been doing.  But normally the translator's diff is against a file which resembles mine.
<Kamion> mdz: cool
<iwj> Since this time it wasn't I thought I'd check that I'm not missing something.
<mdz> Kamion: and on the console "Error reading inode 6435" and "Error reading inode 10410"
<Kamion> mdz: anything special about the ntfs filesystem?
<mdz> Kamion: it's a fresh XP install, booted once
<mdz> Kamion: linked clone VMware guest
<Kamion> I did a fresh XP install likewise, resized, worked for me
<Kamion> how odd
<iwj> Obviously their desktop file was generated by something which defaulted the [pl_PL]  to the English string.
<iwj> (something = might be a person I suppose)
<mdz> Kamion: let me try with the old gparted
<seb128> iwj: dunno where the guy has found his file, that's not a part of the language pack changes afaik
<mvo> Kamion: this page (codenametoversionnumers) is news for me
<seb128> iwj: the language pack changes are to get the translation from gettext but since firefox doesn't use gettext, it doesn't apply
<iwj> Then there's some source for these .desktop files that we don't know about ...
<seb128> iwj: changing as you do usually should be just fine
<iwj> OK.  And I should apply the translation to [pl]  and not (as the guy asks) to [pl_PL] , I presume.
<Kamion> mdz: also the default home page and "About Ubuntu" still say "Dapper Drake" although they also mention the version number
<Kamion> mdz: firefox says "Ubuntu/dapper" in its version info
<seb128> iwj: I would say that "pl" is correct yep
<mdz> iwj: as long as we're waiting on kernels and oo.o, could you fix that ^^^ ?
<iwj> seb128: Right.
<mdz> Kamion: ntfsresize -n succeeded fine
<mdz> Kamion: ntfsresize -s tells me the journal is unclean, which is odd
<iwj> Kamion: you mean the files in ubuntu-docs ?  I can fix that.
<Kamion> iwj: I'm not sure yet whether we want to
<Kamion> mdz: the firefox build version is the only place of those listed in CodeNamesToVersionNumbers where I see dapper without 6.06; do we even want to bother changing the rest now?
<mdz> Kamion: booting windows confirms it thinks the fs was fucked
<iwj> I don't think we should change the version info string; that appears in the user agent too and randomly messing with it is a bad idea.
<Kamion> mvo: it was the result of an e-mail thread between me, mdz, silbs, and others
<seb128> iwj: TomaszD on #ubuntu-bugs is the submitter
<Kamion> mdz: fucked before gparted or after?
<seb128> iwj: feel free to join #ubuntu-bugs if you want to speak with him
<Kamion> iwj: happy to treat it like lsb-release DISTRIB_CODENAME
<Kamion> (i.e. used by code, don't change)
<iwj> seb128: Willdo.
<mdz> Kamion: urgh, they don't say LTS yet either
<mdz> we should fix as many as we can
<mdz> dholbach: will you do ubuntu-artwork?
<Kamion> mdz: so yes to removing "Dapper Drake"?
<mdz> Kamion: yes
<Kamion> mvo: can you remove codenames from released versions and dapper in synaptic, then, and change "Ubuntu 6.06" to "Ubuntu 6.06 LTS"?
<mvo> Kamion: ok, I'll change the software properties tool and the dist-upgrader
<Kamion> iwj: please go ahead and fix ubuntu-docs, then: "Ubuntu 6.06, Dapper Drake" -> "Ubuntu 6.06 LTS"
<Kamion> hopefully it's possible to adapt translations too
<iwj> Kamion: wilco.
<mvo> I can't say that I'm happy about this because it will break some translaitons (e.g. CD dist with Ubuntu 'Dapper Drake') 
<ogra> mdz, does that apply to Riddell, janimo and me as well (removing dapper everywhere) ?
<Kamion> mvo: can "Dapper Drake" simply be removed from translations?
<mdz> ogra: yes
<Kamion> mvo: if not, the lesser evil would be to manually unfuzzy the translations rather than breaking them
<Kamion> mvo: can you clarify your (e.g.)?
<ogra> mdz, oki
<janimo> ogra, you mean from the desktop guides as well?
<janimo> I that's the only place DD is mentioned in xubuntu
<janimo> no artwork AFAIK had it
<ogra> janimo, yep
<Kamion> janimo: if it is possible and reasonably straightforward to do so
<ogra> janimo, dont you have a firefox default page 
<mvo> Kamion: well, there are strings like "CD disk with Ubuntu 6.06 'Dapper Drake' " I can try to unfuzzy them by hand 
<mdz> Riddell: you get that?
<janimo> Kamion: well xubuntu-docs will need an upload anyway these days to get the translated guides in so I'll ask the doc writer 
<ogra> janimo, ah, i remember, its in -docs for xubuntu
<Riddell> mdz: yes
<janimo> ogra, oh right ff start page besides the guide
<mdz> Kamion: resize worked this time
<OculusAquilae> carlos: ping
<mdz> Kamion: somewhere along the line the filesystem must have been corrupted, and ntfsresize was bailing out (and gparted not reporting anything useful)
<Kamion> mdz: the "more useful reporting" patches in the new upstream release were one of the things I skipped, because they were huge
<Kamion> so hopefully we'll get that fixed in edgy
<carlos> OculusAquilae: pong
<Kamion> mdz: you know ship-live has actually worked out fairly well
<mdz> Kamion: oh good
<Kamion> mdz: if you leave the live CD in post-installation, you get a pop-up when you first log in asking you if you want to launch synaptic, which then does apt-cdrom and sorts it all out
<Kamion> not a bad UI
<OculusAquilae> carlos: could you check if the language-files of ktorrent get imported in the language-packs? They are firstly builded today.
<mdz> Mithrandir: have you been able to confirm the casper /dev/console fix in an official CD build?
<Kamion> we decided to give up langpacks for build-essential and linux-headers, didn't we?
<Kamion> I'd better do that soon
<mdz> Kamion: resize was successful, and XP booted and succeeded in its filesystem check
<carlos> OculusAquilae: is the first time we build that package in main?
<OculusAquilae> carlos: no, but the first time the language-files are generated
<mdz> interestingly, windows claims it found new devices since the reboot
<carlos> OculusAquilae: then it will not be part of the dapper's language packs until the update we will do a month after release
<carlos> OculusAquilae: the final language packs were already built
<Kamion> pitti: is your report on langpack sizes on the web somewhere?
<pitti> Kamion: it will be in a minute :)
<carlos> OculusAquilae: anyway, let me check to be sure that it's all ready to have it as part of the next update...
<OculusAquilae> carlos: also when the translation-freeze is on thursday?
<Keybuk> oh, wow, that's kinda off
<Keybuk> odd, even
<Keybuk> a filling just fell out
<pitti> Kamion: http://people.ubuntu.com/~pitti/langpacks/langpacksize.txt
<Kamion> pitti: thanks
<ogra> Keybuk, so head to the dentist then ...
<pitti> Kamion: 'G' for base+gnome (i. e. ubuntu), 'K' for base+KDE (kubuntu)
<pitti> Kamion: G+K for edubuntu (which has both)
<carlos> pitti: OculusAquilae did a good point... the language pack translation deadline is next Thursday... you should do an update...
<pitti> Kamion: second half of columns are cumulative sizes
<pitti> Kamion: and the ordering is the one we prefer (English first, then the top 11, then alphabetically)
<Kamion> carlos: this Thursday, not next Thursday
<Keybuk> ogra: it's not hurting, so I'll do it when I'm less busy :)
<Kamion> next Thursday is release
<OculusAquilae> carlos: that's also what the guys in the german translator MailingList think
<carlos> Kamion: well, sorry, I was talking about the day after tomorrow
<kagou> smurf: around ?
<bddebian> Morning folks
<kagou> is smurf in vacations ?
<bddebian> Keybuk: Is the meeting on today or no?
<Kamion> bddebian: see ubuntu-devel-announce@
<Kamion> mdz: with the exception of the codenames stuff and the release announcement, I believe the rest of ReleaseChecklist "Before building candidates" is done
<Kamion> and the release announcement doesn't really have to be before building candidates
<mdz> Kamion: excellent
<ogra> bddebian, i think only the kubuntu meeting took place this week, all others are cnacelled
<Keybuk> bddebian: no.
<mdz> Kamion: traditionally it hasn't been, but we can try ;-)
<bddebian> OK, thx
<mdz> Kamion: I'll work on the announcement
* iwj finds a 6.04 in ubuntu-docs.
<mdz> iwj: eek
<Kinnison> sladen: what do you think about Lure's whitelist request?
* mvo waits for rosetta to bring him new trnalsations to unfuzzy for the codename change
<carlos> OculusAquilae: ktorrent is missing the .pot file
<OculusAquilae> hm
<carlos> OculusAquilae: you should create it on build time
<mdz> seb128: what version of GNOME should we say that we ship in final?  we seem to have 2.14.0, 2.14.1, 2.14.2, 2.14.3 and 2.14.4  packages
<mdz> Riddell: same question for KDE
<Keybuk> mdz: "2.14" ? :)
<seb128> mdz: we have 2.14.1 
<Riddell> mdz: 3.5.2
<seb128> mdz: technically it's 2.14.1, 2.14.2 is due next week
<OculusAquilae> carlos: hm, that's right
<seb128> (mdz: with a good part of the CVS fixes for 2.14.2)
<mdz> seb128: ok, thanks
<seb128> np
<Kamion> did the release notes get removed from ubuntu-docs?
<Mithrandir> mdz: doing so now, had to sync down the latest image first
<Kamion> ReleaseChecklist says to check them but I can't find them
<seb128> mdz: http://people.ubuntu.com/~seb128/enchant.debdiff ok to upload?
<seb128> s#beeing#being
<mvo> Kamion: do we want: "Ubuntu 6.06 Security Updates" or "Ubuntu 6.06 LTS Security Updates" for the repository label? i.e. LTS after every 6.06? with or without a single space? (6.06LTS vs 6.06 LTS)?
<Kamion> mvo: LTS, with space
<sladen> Kinnison: I'm was happy with it.  Now I think about it more, we're white-listing machines with known-perfect working Suspend.  In this case there's a hardware bug (it seems) that requires the LID switch pressing to turn on the backlight
<mdz> Kamion: trivial first draft based on Beta announcement: https://wiki.ubuntu.com/DapperReleaseCandidateAnnouncement
<Kinnison> sladen: Right
<Kinnison> sladen: I think I need to go and register at the local doctor's surgery, but once I get back from tha acpi-support (0.84) dapper; urgency=low
<sladen> Kinnison: and g-p-m allow Suspend to be enabled with a warning otherwise anyway
<Kinnison>  .
<Kinnison>    * Whitelist another laptop (Ubuntu #44781)
<Kinnison>      - Hewlett-Packard Pavilion ZV6000
<Kinnison>    * Add whitelist for bizarre old laptop (Closes: Ubuntu #38174)t I acpi-support (0.84) dapper; urgency=low
<Kinnison>  .
<Kinnison>    * Whitelist another laptop (Ubuntu #44781)
<Kinnison> My trackpad has taken to pasting at odd times
<Kinnison>      - Hewlett-Packard Pavilion ZV6000
<Kinnison> I'm really sorry about that
<Kinnison> feck
* Kinnison apologises
<Kinnison> sladen: Once I get back from the surgery I'll whitelist that laptop
<Mithrandir> mdz: seemed to work fine for me.
<sladen> Kinnison: is it seeing three-fingers as a middle-button paste?
<mdz> Kamion: I thought you said the 0% new partition size was just a display problem, but clicking Forward without twiddling it failed for me
<Keybuk> mdz: still says "text-mode installer" under "Installation and Upgrades"
<Mithrandir> Kinnison: hmm, yours too?  My desktop's mouse has begun behaving weirdly too.
<Mithrandir> Kinnison: unsure if it's a hardware failure or not.
<Mithrandir> (old mouse)
<Kinnison> sladen: It doesn't do multifinger
<Kamion> mdz: oh, I *thought* it was just a display problem then. :(
<Kinnison> Mithrandir: I think mine is being sensitive. My thumb hovers near the corner which I have set as middle button
<Mithrandir> Kinnison: ok, probably not a software bug, then.
<Mithrandir> anyway, gotta go to the shop and suck, bbl.
<sladen> Kinnison: Rejected.  non-default config.  Go and see the doctor
* Kinnison ruffles mithrandir
<Kinnison> sladen: *g*
<mdz> Keybuk: please fix
<Keybuk> mdz: done
<jcole> honestly, what works better totem-xine or totem-gstreamer
<Kamion> Mithrandir: happy sucking
<bddebian> uhh
* jcole suspects that there are some totem-xine'rs here
<seb128> jcole: depend of what you play
<ogra> depends on your arch :)
<Kamion> Riddell,ogra,janimo: I'd suggest being very careful about your next merge of the Ubuntu seeds; only take my addition of build-essential/fakeroot/linux-headers to the ship-live seed if you have room
<ogra> Kamion, i'm alsways careful about the  merges :)
<infinity> Kamion: So, ship-live IS happening?
<ogra> its already there :)
<Kamion> I left out bzr and cvs, those take 2MB or so
<Kamion> infinity: it's there, I'm just extending it
* infinity must have missed the day it actually happened.
<Kamion> infinity: couple of days ago
<seb128> mdz: did you read about http://people.ubuntu.com/~seb128/enchant.debdiff ? that's a trivial g_new to g_new0 change and fix a crasher; it's ready to upload :p
<tseng> jcole: this really isnt the place and definately not the time, please try #ubuntu
<infinity> Kamion: Cool.  I vaguely recall some flamefest about it, then nothing.
<Kamion> 2006-05-18 according to my batched-up activity reports
<jcole> tseng: ok
<dholbach> mdz: I'll have a look - any particular occasion you spotted it in u-a?
<mdz> seb128: no, if you mentioned it before I must have missed it
<mdz> seb128: looks fine
<mdz> dholbach: it's on the list
<seb128> mdz: yeah, some minutes ago, thank you
<mdz> dholbach: https://wiki.ubuntu.com/CodeNamesToVersionNumbers
<mdz> dholbach: and the default firefox home page is rather visible ;-)
<dholbach> mdz: that's ubuntu-docs - don't ask, why it install to ubuntu-artwork - we deferred that to edgy
<mdz> dholbach: well, in that case shame on me for assuming that /usr/share/doc/foo belongs to foo ;-)
<dholbach> mdz: yeah - shame on you :-p
<Kamion> s,doc/,, at least ;-)
<mdz> whatev
<infinity> mdz: How fast can you download 2 gigs from the DC? :)
<infinity> (That's how big the tarball ended up)
<bddebian> Heya infinity
<mdz> infinity: fast
<dholbach> mdz: i see that example-content needs some love - I'll look at it
<mdz> dholbach: thanks
<mdz> infinity: under an hour, I estimate
<mdz> infinity: any progress with it?
<infinity> mdz: I'm dangerously close to bedtime here, but if you wanted to give OOo more love, it fails nearly instantly if you "sudo mount -t proc proc-test chroot-autobuild/proc ; sudo chroot chroot-autobuild/ su - buildd", then cd to /build/buildd/whatever and "fakeroot debian/rules binary"
<infinity> mdz: If you've not the time, I'll have to attack it with fresh vigor and a fresh mind tomorrow morning.
<ogra> mdz, going there by tube with a dvdrw in your bag would be faster ;)
<Kamion> from Mossop Street to Angel and back? no it wouldn't :)
<ogra> oh, really ? i didt think its that far
<ogra> *didnt
<Kamion> takes five/ten minutes to get to the tube station, if nothing else
<mdz> yep
<jono> hey all
<mdz> infinity: where is it?
<bddebian> Hello jono
<infinity> mdz: Making its way to chinstrap via scp...
<jono> which package should a user install to install java?
<jono> hey bddebian
<Kamion> damn, forgot to upload ubuntu-meta so I overflowed the desktop CDs; working on it
<pitti> Kamion: sorry for the delay, I had a RL business here; I finished the install with verbosity, and put the log to http://people.ubuntu.com/~pitti/tmp/syslog
<infinity> jono: #ubuntu, please
<jono> infinity: sorry, this is for the book, but your right I think
<pitti> Kamion: it seems that it has trouble finding the kernel (from the exception); do you want me to file this as a bug? it might be something transient
<Riddell> jono: do you have a phone number for jjesse?
<jono> Riddell: nope
<jono> Riddell: has he sent you the chapter?
<dholbach> hum, seems that not even example-content needs changes
<Riddell> jono: no, he says he's working on it but I'm not sure what the delay is
<Kamion> pitti: bugger. please file bug
<Kamion> it's not transient
<jono> Riddell: hmmm, not sure
<jono> Riddell: I thought he was getting it to you yesterday
<dholbach> mdke: seems that ubuntu-docs needs some changes according to https://wiki.ubuntu.com/CodeNamesToVersionNumbers - if you want me to upload, once you guys could look at it, just tell me
<infinity> mdz: chinstrap:~adconrad/chroot-ooo-failure.tar.bz2
<Kamion> pitti: and it affects all powerpc installs. I WISH my powerbook's CD drive worked
<ogra> Riddell, tsk, you want me to keep en_GB in edubuntu but drop de_DE from kubuntu ... pfft ...
<pitti> Kamion: done, bug 46160
<Ubugtu> Malone bug 46160 in ubiquity "yaboot not installed" [Major,Unconfirmed]  http://launchpad.net/bugs/46160
<Kamion> ogra: he dropped language-support not language-pack
<ogra> Kamion, :)
<Riddell> ogra: only language-support, langauge-pack de is still there
<heno> dholbach: I sent you a mail about example-content changes (I shrunk jono's book :) )
<dholbach> heno: ah nice
<jono> heno: shrunk? does this mean only mice can read it ?
<jono> :P
<ogra> its <6pt now :)
<heno> jono: all the images are now rendered in 5 shades of pink, takes less space
<ogra> to test our a11y implementation 
<heno> no, I just did some png crunching
<mdz> Kamion: will it not boot from a USB drive?
<Kamion> mdz: probably, if I could find mine
<Kamion> I just haven't had time for hardware maintenance around here
<dholbach> hum - what's the question? I did two installs on a USB drive today
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-fix-46160.diff OK once I've test-built it?
<Kamion> we filter out base-installer/* from the templates file because it saves a credible amount of memory on the live CD, but base-installer/kernel/linux/link_on_boot is used by scripts/install.py on powerpc
<infinity> s/on/in/, or is that typo entrenched in the code?
<mdz> Kamion: I'm trying a test with auto-resize now, and it's taking *forever*. is that normal for ntfs/vmware?
<infinity> Oh, I see it's "in" in the diff.  Phew. :)
<Kamion> s/on/in/, correct (I cut-and-pasted it for the actual diff)
<Kamion> mdz: it takes a fair while without feedback, yes
<Kamion> might want to check that ntfsresize is actually still running
<mdz> Kamion: it isn't
<mdz> partman is
<Kamion> https://launchpad.net/distros/ubuntu/+source/partman-partitioning/+bug/14100
<Ubugtu> Malone bug 14100 in partman-partitioning "partman doesn't provide ntfsresize status details" [Normal,Confirmed]  
<Kamion> what's it doing?
<mdz> no hard disk activity either
<mdz> good question
<Kamion> tail -f /var/log/partman
<mdz> it's running 55divider_up at the moment
<Kamion> that's not usually good
<mdz> seems to be looping
<mdz> main_loop: iteration 1174
<pitti> mdz: ok to fix a bunch of exploitable format string issues in dia?
<Kamion> can I get the partman log?
<mdz> Kamion: sure
<mdz> Kamion: ignore the mail I just sent
<mdz> Kamion: correct log is in the second message
<Riddell> are packages being blocked?  I don't see kubuntu-meta 0.81 in launchpad
<Kamion> Riddell: kubuntu-meta is in accepted
<Kamion> Riddell: you uploaded it just over half an hour ago; the publisher has not run since then
<Riddell> right, thanks
<ogra> infinity, thanks for -artwork :)
<Kamion> mdz: you don't happen to be running with UBIQUITY_DEBUG=1?
<mdz> Kamion: no
<mdz> Kamion: shall I kill it and try to reproduce again?
<Kamion> mdz: could you strace the ubiquity process for a few seconds (enough for a loop or two) and send me that trace?
<Kamion> mdz: also, anything interesting in /var/log/installer/syslog?
<Riddell> hmm, there's a lot of "Dapper"s in kubuntu-docs, this is going to break every translation there is
<Kamion> perhaps ssh access would be easier
<Kamion> if possible
<dholbach> mdz: ok to upload example-content in a bit? henrik saved us 1,7 MB
<Kamion> Riddell: if it's not easy to do, then it's probably better to leave it as it is and remember to make it easy for next time
<iwj> Riddell: I just ran a Perl script to update all the translations too.
<mdz> dholbach: yes
<iwj> (in ubuntu-docs)
<mdke> erm
<mdke> in all the docs we use Ubuntu 6.06 (Dapper Drake)
<mdke> so we use the version number
<mdke> where the code name is used it is often intentional, I don't see how we can possibly script that change
<mdke> and some languages won't be scriptable
<mdz> Kamion: mailed
<iwj> mdke: See above ^ where I was asked to change occurrences of `Ubuntu 6.06, Dapper Drake' to `Ubuntu 6.06 LTS'.  The ocurrences seem almost entirely to be in the startup page.
<Riddell> iwj: are you going to commit to SVN?
<iwj> Riddell: What, ubuntu-docs svn ?  No, I was going to upload.
<mdke> iwj: I think my concerns apply
<Riddell> iwj: it would be nice to be able to review it before uploading
<mvo> mdz: do you want to see the debdiff for the 6.06->6.06LTS changes for the software-properties application ? 
<mvo> or can I just upload
<mdz> mvo: I'm happy to review it
<iwj> mdke, Riddell: I have reviewed the diff (to source and to output).  The only files apart from *index*.html that have changed in the output is generic.ent, which had a 6.04 in it.
<Kamion> if any change for this is hard or non-trivial, we should leave it be
<Kamion> and change the processes for next time round so that we can switch more freely back and forward between codename and version number
<mdke> iwj: we don't use generic.ent. is that installed?
<Kamion> we want to be able to have user-facing documentation etc. refer to codenames (only) during development and version numbers (only) for release
<iwj> Yes, /usr/share/ubuntu-docs/ubuntu/libs/generic.ent.
<iwj> My only change to that is 6.04 -> 6.06.
<mdke> iwj: ok, that's superfluous i think.
<mvo> mdz: thanks, its at http://people.ubuntu.com/~mvo/update-manager_0.42.2ubuntu20.debdiff (a bit big, I update the translation from rosetta and unfuzzied all by hand, aptsources.py is not actually two times in the source tree but only once and a symlink, but the debdiff shows it two times, just ignore it, they are identical)
<iwj> So are you now happy with me uploading ?
<mdke> iwj: are you sure none of the docs have it in? about ubuntu contains "Ubuntu 6.06 - The Dapper Drake"
<mdke> changing that will break translations and generally make me unhappy
<mdz> mdke: that's not translated on the fly, is it?
<iwj> "Ubuntu 6.06 - The Dapper Drake" != "Ubuntu 6.06, Dapper Drake"
<mdke> right...
<iwj> And, yes, I've done  diff -ruN w x 2>&1 |egrep '^\+\+\+' |sort
<mdke> mdz: no. We can sync the translations up after release, I suppose
<iwj> (w and x being before and after from dpkg -x)
<mdz> mdke: if the change isn't propagated to the translations, that's not fatal
<mdke> i personally think its nice to include the codenames as a secondary reference to identify a version with, especially in a document specifically about Ubuntu
<pitti> mdz: ok to upload dia security update (format string) with this dpatch: http://paste.ubuntu-nl.org/14552
<mdz> changing it shouldn't cause any problem with the translations
<bddebian> Ack, I have a dia desktop fix too.. Hmm
<iwj> mdz, mdke: Let me know when you've decided.  I've got it here ready to go.
<mdke> mdz: no. it will be one more string to translate after release though
<iwj> (I do think it's a bit strange that the resulting new index.html doesn't contain the word `dapper' but I don't want to get involved in branding arguments ...)
<mdke> i think index.html is a moot point and am happy to defer to the top level decisions
<mdke> but in About Ubuntu, the whole point is that it provides information about the background to Ubuntu
<mdke> i think codenames are a part of that
<mdke> anyway, you guys take the decision, and let me know so that I can sync up the changes afterwards and notify the translators of the string change
<iwj> mdke: I promise I haven't edited anything but *index*.html's.
<janimo> Kamion , do I need to generate a new ubuntu-live to pick up the ship-live changes?
<janimo> xubuntu-live I mean
<Kamion> I don't mind not changing About Ubuntu if that seems best
<Kamion> janimo: no
<janimo> ok
<Kamion> janimo: only if you've changed desktop or live
<mdke> iwj, ok. If you're doing an upload, can you include the new ubuntu/desktopguide/sk directory from our repository? some emergency fixes for that language
<Kamion> can anyone give me the smallest bit of shell they can think of to ensure that there is precisely one blank line at the end of a file?
<iwj> Kamion: What's this, shell golf ?
<Kamion> more minimal-change-to-package golf
<iwj> mdke: Err, if it's going to be this hard I could email you the source debdiff.
<Kamion> I don't mean runes, I suppose I mean the cleanest-and-small bit of shell they can think of
<mdke> iwj: if it's hard, don't bother and I'll make a new package after yours
<iwj> (cat file && echo) | tail -1   prints a blank line iff the file had a trailing newline.
<Kamion> I suppose 'tail -n1 | grep . || echo'
<Kamion> context is generating a debconf templates file from several pieces, being unsure if each piece ends with a trailing blank line, and wanting to ensure exactly one blank line between template stanzas because I can't remember if anything will break if that isn't true
<iwj> Kamion: no, that doesn't work.   tail -n1 preserves the trailing newline or lack of it
<Kamion> iwj: expand my statement to 'tail -n1 foo | grep . || echo >> foo', not '(tail -n1 foo | grep . || echo) >> foo'
<iwj> cat file; test "x`(cat file; echo) | tail -n1`" = x || echo
<mdke> iwj: alternatively, if it helps, there is a patch here: https://lists.ubuntu.com/archives/ubuntu-doc-commits/2006-May/002610.html
<mdke> your call as to what is easiest
<iwj> Kamion:    printf yes >foo  ;    tail -n1 foo | grep . || echo >>foo
<iwj> The rune for appending to foo prints `yes' and then foo still has no newline.
<iwj> test "x`(cat foo; echo) | tail -n1`" = x || echo >>foo
<iwj> Or some circumlocution if you want to worry about failing to read foo.
<iwj> mdke: Do you have that patch not in HTML ?
<mdke> iwj: sure, I have the email
<iwj> mdke: Forward it to me, iwj@ubuntu.com.  Thanks.  I'll include it.
<mdke> iwj: will do, thank *you*
<janimo> Kamion, is it a problem if it just add a newline regardless if there's one already at athe end?
<Kamion> iwj: sorry, I meant '... | grep -q . && echo >>foo' then
<Kamion> janimo: I could use 'echo >> foo' if I wanted that :-P
<Kamion> sed '$ { /./ { p; s/.*// } }'
<janimo> I know, that's why I ask if it's a problem :)
<iwj> Kamion: Err, your rune is still wrong.  Try it !  Use mine.
<iwj> echo yes >foo  ;   tail -n1 foo | grep -q . && echo >>foo   ;   cat foo     and notice how your foo has two newlines at the end.
<ogra> 7me wonders if iwj and Kamion really stop at the 18th green :)
<janimo> is it certain the file does not already have more than one newline at the end?
<mdke> iwj: sent
<iwj> mdke: Ta.
<ogra> (or has shell golf special rules?)
<iwj> Kamion: my rune> test "x...  above.
<Kamion> yes, thanks
<bddebian> Hello sabdfl
<dholbach> hey sabdfl!
* ogra just figured its "bzr upgrade" not "bzr update" .... wow, thats significanly faster
<sabdfl> hey guys
<Kamion> iwj: but my rune is correct, I *want* "foo\n\n"
<Kamion> trailing *blank* line not trailing newline
<pitti> hi sabdfl, how are you?
<sabdfl> guuuurd
<sabdfl> well, sick puppy but at least capable of reading and typing today
<sabdfl> some monstrous mexican microbe took me out
<iwj> Kamion: Oh.  I should read more carefully.
<pitti> sabdfl: ouch, not a plague again :/
<iwj> test "x`tail -1 foo`" = x || echo >>foo     if you're guaranteed that the file has a trailing newline.
<sabdfl> i don't blame anyone at debconf in particular
<sabdfl> not that paranoid
<mdke> it's in the water
<sivang> sabdfl: err, drink some herbal tea :)
<sabdfl> sivang: which herbs, in particular?
<Kamion> iwj: yes, I am. I think our two approaches are the same modulo style then, so thanks :)
<fabbione> sabdfl: marjuana :P
<ogra> heh
<sivang> sabdfl: well, what I take is what Kinnison calls pepper mint I think, in Hebrew/Arabic it's call "Na'a Na'a"
<sivang> sabdfl: all camomile can help :)
<sivang> and also what fabbione said :-D
<mdke> iwj: also, if you can send me a debdiff, it would help for synching up the repo. No worries if you can't
<dholbach> sabdfl: everybody expresses it differently, but they all want the best for you :-)
* bddebian posts to /.  "Ubuntu Leader Poisened by Debian" ;-P
<iwj> mdke: Willdo.
<mdke> merci
<iwj> Kamion: Yours has a uuogrep :-).
<Kamion> iwj: yours has a uuotest ;-)
<Kamion> (and a usubshell)
<mdke> iwj: oh... and i suppose adding another translateable locale would be too much. it's in ubuntu-docs already
<Kamion> though I did use roughly yours in the end
<iwj> Subshells are bad, are they ?  I would generally fork a subshell rather than execute another command.  test is a builtin.  If it isn't, use case :-).
<iwj> mdke: Is there an XPI ?  (If `no' the answer is an easy `no'.)
<mdke> iwj: yeah. ka_GE
<mjg59> sabdfl: How's the X60 behaving with the latest kernel?
<iwj> And I think I want to say `no' anyway.  It's quite a faff to rebuild 4 dependent packages.  That's why I said to do them in batches !
<sivang> guys, if someone got his sudoers file 0777 and sudo won't let him anymore, root is disabled, is there another way to undo the horror without a livecd ?
<Kamion> iwj: fair enough
<Kamion> sivang: boot in recovery mode
<pitti> sivang: boot in rescue mode
<mdke> iwj: yeah, totally understand. your call again
<sivang> pitti, Kamion : thanks. it shouldn't require a password right?
<Kamion> no
<mdke> iwj: it would be the last one though *bats eyelids*
<sivang> kool, ta
<iwj> mdke: I mean, if you have time to prat about with null uploads of *-{docs,artwork} then I can do the ubuntu-docs change :-).
<_ion> sivang: How the windows would someone get her sudoers file chmoded 0777 without intentionally doing that?
<mdke> iwj: it's the other way around, I did the ubuntu-docs change and it's in the archive. But i don't have upload rights so I can't do the rest
<sivang> _ion: godo question...nobody knows..
<iwj> mdke: Urgh.
<iwj> You MUST NOT DO THAT.
<iwj> Because the next time m-f-l-all is uploaded, ka_GE users' browsers will mysteriously break.
<sivang> anyway, I Have a machine to wipe, laters and thanks again.
<iwj> Did you read the BIG FAT WARNING next to the locale list saying NOT TO EDIT IT without following the documented procedure, with ref to the doc, and everything ?
<mvo> mdz: I'll leave for dinner now but will read scrollback, please let me know if I should upload the software-properties changes (http://people.ubuntu.com/~mvo/update-manager_0.42.2ubuntu20.debdiff)
* dholbach  bzr rspush
<mdke> iwj: sorry
<iwj> mdke: What's the point of putting warnings like that in if you don't read them ?
<iwj> You say this change is in the archive (by which you mean dapper I take it) and therefore also in SVN ?
<ogra> dholbach, rspush ? 
<Kamion> ogra: bzr help rspush
<Keybuk> dholbach: isn't rspush bad?
<ogra> dholbach, the new bzr is pretty quick via sftp
<Kamion> Keybuk: not on a non-shared archive
<janimo> backwards compatible feature? really slow push?
<dholbach> Keybuk: it works nicely for me
<ogra> Kamion, i know
<Keybuk> Kamion: it's somewhat less efficient than an ordinary knit push isn't it?
<pitti> Kamion: whoa, just read the ubuntu-meta changelog; did I overlook anything when I addded the last langpacks, or was something really big added recently?
<Kamion> pitti: ship-live additions
<ogra> Kamion, i just saw how fast the sftp implementation is now
<mdz> mvo: sorry, am in the middle of several conversations
<Kamion> oh, shrug, haven't compared
<mdke> iwj: yes. i.e. number 1 in "Adding new locales" has been done
<Kamion> mdz: hmm, that ubiquity strace is weird; working on it
<ogra> Kamion, 20min vs 30sec is quite noticeable for me :)
<ogra> (for a seed push)
<mdz> iwj: lots of turmoil in scrollback, what's the situation with the docs update?
<Kamion> ogra: that's weave vs. knit not rspush vs. push
<seb128> I've to run for like half an hour, brb
<Keybuk> ogra: 30s?  A seed push for me is now ~1s
<mdke> iwj: if necessary, roll back number 1
<ogra> Kamion, weave vs knit, both times with push
<Kamion> ogra: that's what I sai
<Kamion> ] d
<Keybuk> I'm sure it'd be interesting to compare push vs. rspush with knit
<iwj> mdke: Yes, I think we should roll it back.  I will do this in ubuntu-docs in dapper.  Are we sure that this will propagate to svn rather than unreverting ?
<Keybuk> but I guess now is not the time ;)
<mdke> iwj: i'll apply any debdiff you send me. Sorry about that
<iwj> mdke: OK, thanks.  I'll clarify the wiki page to make it clear you can't go halfway through this process and leave it.
<mdke> iwj, thanks. 
<mdz> infinity: that chroot tarball is taking as long to unpack as it did to download
<mdz> I think bzip2 was a net loss over gzip in this case
<infinity> mdz: Yeah, I realised that about halfway through tarring it, but wasn't about to start over...
<pitti> arrgh
<Keybuk> pitti: talk like a pirate day?
<pitti> mdz: sorry, I accidentally uploaded the dapper dia security update together with the stable-security ones (autofingers, sorry)
<mdz> infinity: some weird stuff in here
<mdz> pitti: it's not on any CDs, is it?  if not, it's OK
<pitti> mdz: no, it's not
<mdz> buildd@ubuntu:/build/buildd/openoffice.org-2.0.2$ fakeroot debian/rules binary
<mdz> -su: /usr/bin/fakeroot: Permission denied
<mdz> buildd@ubuntu:/build/buildd/openoffice.org-2.0.2$ ls -l /usr/bin/fakeroot
<mdz> ---------- 1 root root 0 May 23 15:49 /usr/bin/fakeroot
<Keybuk> 0 bytes?
<mdz> interesting
<infinity> !
<mdz> that became a symlink when tar finally exited
<mdz> but meanwhile it was a 0-byte, mode 0 regular file
<pitti> Keybuk: you should use that compression algorithm for dpkg 2.0
<dholbach> and save disk space
<infinity> mdz: Oh, so that was just "tar being tar", then...  Is it still weird after tar's done? :)
<mdz> infinity: no
<mdz> but it's not failing either
<infinity> Argh.
<infinity> You mounted proc?
<mdz> so I'm going to upload these binaries if it succeeds
<mdz> yes
<mdz> proc-test on /home/mdz/src/chroot-autobuild/proc type proc (rw)
<infinity> If so, then the only (meaningful) difference here may be the kernel.
<infinity> OTOH, it's both failed and succeeded in manual builds on the same machine.
<mdz> infinity: what kernel are you running?
<infinity> (That was the same machine where I previously had a successful manual build, though the buildd builds always fail)
<mdz> this is 2.6.15-22
<infinity> Linux vernadsky 2.6.12 #1 SMP Mon Jan 2 16:52:14 UTC 2006 i686 GNU/Linux
<mdz> this happens to be an amd64 running i386 dapper
<Kamion> mdz: upload these binaries> how? :)
<infinity> elmo hand-roll, based on breezy sources.
<mdz> Kamion: celso is across the table from me, conveniently
<Kamion> heh
<Kamion> "hey, soyuz, look! a fire engine!"
<infinity> mdz: Can you ask celso to make sure to upload them through the buildd queue, and to twiddle the DB so the build comes up as "successful"?
<infinity> mdz: I can do the latter part in the morning, if he hasn't.
<Kamion> mdz: next round of server CD images will be called *-server-*
<mdz> Kamion: thank you
<mdz> Mithrandir: would you pull down this ooo chroot and try a build locally?  preferably on a breezy kernel
<Kamion> mdz: I think http://people.ubuntu.com/~cjwatson/tmp/ubiquity-autopartition-loop.diff fixes your infinite loop, but I'm constructing a test now
<mdz> Mithrandir: our best guess right now is that the kernel is triggering it
<mdz> infinity: I don't suppose I can get access to the chroot where it actually fails, to debug
<infinity> mdz: Ask elmo/Znarl for access to vernadsky.buildd with full sudo.  The chroot you have a copy of is in ~adconrad/
<infinity> mdz: I don't hand out access to machines in the DC, so that's the best I can do. :)
<mdz> Znarl: ?
<mdz> Znarl: this is the only means available to me to debug this problem
<infinity> mdz: I was going to lay into it with tracers and debuggers tomorrow, so if you have other stuff to attend to anyway (and these binaries work for us for now), you may not need to go there just yet.
<infinity> Okay, Double-U Tee Eff, mate.
<infinity> mdz: The OOo-l10n build I had going on terranova succeeded.  I'll upload those binaries post-haste.
<mdz> Kamion: how did I trigger it?  by trying to click ahead without adjusting the slider first?
<seb128> re
<dholbach> wb seb
<seb128> re dholbach :)
<Kamion> mdz: I'm honestly not sure; somehow partman/choose_partition has ended up set to the empty string
<bddebian> Heya seb128
<bddebian> If one of you archive admins could take mercy on me, could you please look at the sync request for libspiffy-perl?  It's totally my fault :-(  Bug #44207
<Ubugtu> Malone bug 44207 in libspiffy-perl "UVF Exception (now sync) Request: libspiffy-perl" [Normal,Unconfirmed]  http://launchpad.net/bugs/44207
<infinity> bddebian: On it.
<Keybuk> infinity: go to bed :)
<bddebian> infinity: You're my hero :-)
<infinity> Keybuk: I'm scping crap around the DC and doing Very Bad Things.
<infinity> Keybuk: So, I'm up for a bit anyway.
<bddebian> heh
<Keybuk> tsk
<infinity> Keybuk: If you want to do this, though, be my guest.
<Kamion> mdz: the same code is in partman_commit.py, and this doesn't seem to break anything at least ...
<Keybuk> infinity: I am already
<infinity> I see that. :)
<Keybuk> (I had a drescher window just under this one)
* infinity goes to make sweet, sweet love to the soyuz buildd queue.
<bddebian> hehe
<mdz> Kamion: I have reproduced the problem again after applying your patch
<Keybuk> bddebian: done
<bddebian> Keybuk: Rockin', thank you sir
<Kamion> mdz: gar. debugging on this time?
<mdz> Kamion: no, but I bet I can do it again
<Kamion> mdz: that would be great
<Keybuk> (switching machines to do some amd64/i386 testing)
<Keybuk> Kamion: ppc alternate works nicely for me in all the tests I could think of
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-autopartition-loop.diff updated with alternative approach, should be more foolproof
<mdz> Kamion: log emailed (this is with an unpatched ubiquity)
<mdz> will try fresh with that patch next
<mdz> infinity: gar, the build just fails in a different way
<mdz> trying to compress man pages which aren't there
<infinity> mdz: Alright, I'll build it from scratch on terranova, which seems to succeed fine (uploading the -l10n build from terranova right now)
<mdz> for i in calc math draw writer impress base; do \
<mdz>                 find debian/openoffice.org-$i -type f -name "*.1" | xargs gzip -9; \
<mdz>         done
<mdz> gzip: compressed data not written to a terminal. Use -f to force compression.
<mdz> For help, type: gzip -h
<mdz> [etc.] 
<mdz> there are no .1 files installed anywhere under debian/
<mdz> probably an issue with resuming the build
<infinity> mdz: I expect that's just some sort of breakage due to .. yeah.. that.
<mdz> Kamion: oh, debug log mailed
<mdz> never mind, I already told you that
<infinity> mdz: In my pedantic mind, I think it should be an RC Policy violation when debian/rules binary can't roll back properly, but in practice, it affects almost no one (but me, and today you).. :)
<infinity> Keybuk: OOo-l10n landed in NEW, if you're feeling ftpmasterish still.
<Keybuk> infinity: sure
<infinity> mdz: Shall I kick off OOo on terranova, just to get at least the binaries off our plate?
<mdz> infinity: yes
<mdz> Znarl is working on getting me access to the machine so I can continue the investigation
<infinity> Okay, cool.
<infinity> I'm working on getting to bed, which I'll do as soon as terranova's building. :)
<Kamion> ogra: you still have language-support-es in edubuntu live; I have no sympathy with any further size complaints you have :P
<ogra> Kamion, i just dropped french
<infinity> mdz: You know the one thing I haven't tried, which I never think of on i386, since the kernels aren't generally insane like they are on hppa is "reboot the bloody buildds".
<ogra> Kamion, should suffice for a working build
<Kamion> ogra: drop language-support-es please
<ogra> ok
<Kamion> you can keep language-pack-es obviously
<mdz> Kamion: still reproducible even with v2 of your patch
<Kamion> but we only have language-support-en out of language-support-* on any of our CDs, because language-support-* is *HUGE*
<Kamion> openoffice.org-help-es         | openoffice.org-l10n         | language-support-es       | Debian OpenOffice Team <debian-openoffice@lists.debian.org> |        11431894 |           24496
<Kamion> for instance
<ogra> woah
<Kamion>   * language-pack-${Languages} [i386 amd64] 
<Kamion>   * language-pack-gnome-${Languages} [i386 amd64] 
<Kamion>   * language-pack-kde-${Languages} [i386 amd64] 
<Kamion> - * language-support-${Languages} [i386 amd64] 
<Kamion>   * Languages: zh es bn hi ar xh pt ru ja de
<Kamion>   * language-pack-${Languages} [powerpc] 
<Kamion> I'd apply that if I were you
<janimo> ogra, do you think it would make sense asking for xubuntu/ltsp testers on the edubuntu list?
<mdz> Kamion: I click forward without touching anything, and it tells me it couldn't make enough space.  when I then adjust the slider, I find that it's set by default to an absurdly small value (the amount of slack space that Windows didn't partition).  I then increase it to a reasonable value, click Forward, and it loops. every time.
<infinity> ogra: And then re-add language-support-en somewhere.
<janimo> since it's not quite edubuntu
<Kamion> infinity: no need, that's done above
<infinity> Kamion: Oh. :)
<ogra> janimo, at least you will have the most concentrated amount of ltsp users there there 
<infinity> Kamion: Needed more context in the diff. :)
<janimo> ogra, ok
<ogra> infinity, ?? it was never dropped
<Kamion> ogra: ignore the above
<Kamion> (infinity's comment; it's not relevant here)
<infinity> ogra: Ignore me.
<desrt> anyone remember those ubuntu laptop stickers that were at UBZ?
<desrt> is there anywhere to go to order some more of those?
* desrt has a new laptop in the mail
<fabbione> desrt: only for people that donates G5's ;)
<bddebian> heh
<desrt> i still have the G5 for you sitting on my desk :)
<fabbione> ehhe
<desrt> don't suppose you'll be at guadec
<bddebian> Hey, where's mine? :-)
<fabbione> desrt: nope
<ogra> fabbione, wasnt the inflation pushing it to dual G5s already ? 
<desrt> bddebian; fabio is special
<fabbione> ogra: nah..
<fabbione> desrt: define "special" :P
* bddebian refuses to comment
<desrt> uhm... the one person who gets a free g5 from me?
<desrt> that's pretty special, i'd say
<bddebian> :-)
<fabbione> desrt: eheh
<Keybuk> oh, sure, *he* gets a present
<ogra> Keybuk, he makes the better pasta :)
<Kamion> mdz: any idea why gtk might fail to update the slider until a mouseover event happens?
<Kamion> that's why I assumed it was just a display problem
<mdz> dholbach: did your example-content fix the typo in the book page?
<mdz> dholbach: "destop"
<mdz> Kamion: it may be just a display problem after all; it turns out that in my case the default value is absurd
<dholbach> mdz: no, sorry - I got that bug report later :/
<mdz> Kamion: (though nonzero)
<mdz> dholbach: please fix
<Keybuk> Kamion: surely if the slider is moving, the mouse is over it?
<mdz> Keybuk: the default value for it isn't shown until you hover over it
<mdz> it shows as 0 until then
<Keybuk> how is the default value actually set?
* dholbach typed   bzr vommit   - hope that's not a bad sign
* Keybuk recalls GTK+ requiring a little dance to do that right
<desrt> followed by a short step to the right
<mdz> Kamion: where's the code?  maybe one of our pygtk gurus can help
<Kamion> Keybuk: .set_range()
<Kamion> no, hang on
<ogra> Kamion, mdz, sure thats not bug 22930 ?
<Ubugtu> Malone bug 22930 in gtk "Mouse focus doesn't return until mouse is moved off button" [Unknown,Unconfirmed]  http://launchpad.net/bugs/22930
<mdz> ogra: no, different problem
<Kamion> I wonder if it's simply that I only set the range, not the value
<ogra> (which we also face in the logout dialog heavily)
<seb128> mdz: that focus issue just make the click action not working, it doesn't change the value of anything
<Keybuk> g_signal_emit_by_name (G_OBJECT (adjustment), "changed");
<Keybuk> is the C dance you have to do on it
<seb128> ups
<ogra> seb128, yep, my bad ...
<seb128> s/mdz/ogra
<Kamion> you're kidding?
<seb128> mdz: sorry ;)
<Kamion> I think I should try just doing .set_value(), and while I'm at it I can set it to the middle of the range by default rather than the bottom
<infinity> mdz: Building on terranova.  Will upload the resulting binaries when I wake up.
<Riddell> Kamion: could you start a kubuntu live fs build?
<Kamion> Riddell: running
<dholbach> mdz: uploading
<Kamion> .set_value() is supposed to emit value-changed
<fabbione> zakame: ping?
<Keybuk> Kamion: you don't call set_value anywhere
<Kamion> Keybuk: 17:38 < Kamion> I think I should try just doing .set_value(), and while I'm at it I can set it to the middle of the range by default rather than the bottom
<Kamion> I do now ;-)
<Keybuk> Kamion: heh
<Kamion> ogra: bug 22930 bites ubiquity as well, but no, it's not that
<desrt> wow.  manu marked my logout dialog UI flamefest bug as "fixed released"
<desrt> that's an odd choice of words :)
<mdz> Kamion: confirmed
<mdz> Kamion: calling set_value fixes it
<Kamion> self.new_size_scale.set_value(int(min_percent + 100) / 2)
<Kamion> mdz: did you not get an error dialog telling you "Failed to create enough space for installation"?
<mdz> Kamion: before I added the set_value, yes.  after, no.
<mdz> May 23 17:30:15 <mdz>   Kamion: I click forward without touching anything, and it tells me it couldn't make enough space.  when I then adjust the slider, I find that it's set by default to an absurdly small value (the amount of slack space that Windows didn't partition).  I then increase it to a reasonable value, click Forward, and it loops. every time.
* dieman tries another hoary->dapper upgrade
<Kamion> it's a bug that it didn't send you back to autopartitioning properly, but we don't have time to fix that right, I suspect
<Kamion> mdz: ah, I lost that in scrollback
<pitti> dieman: you are aware that this isn't supported?
<dieman> yes
<dieman> it works, its not that bad
<pitti> dieman: good to hear :) one case that definitively breaks is postgresql
<dieman> im having more issues with upgrading from the scim work that i did locally months ago based on some debian packages
<pitti> dieman: but would be interesting to hear about the results of upgrading a standard desktop install
<mdz> Kamion: fixing the set_value thing makes this much less likely to be triggered
<mdz> Kamion: this actually looks very much like the bug Chris encountered
<dieman> pitti: only thing i notice so far is gnomemetting->ekiga doesn't work so well
<mdz> Kamion: it seems sort of odd that the minimum value is set so low, though.  it looks like it's supposed to enforce that Ubuntu will actually fit in the space created, no?
<dieman> pitti: have to force-remove gnomemeeting before a dist-upgrade
<Kamion> it's meant to, yes
<Kamion> we set the range to match whatever parted_server says the allowable resize range is
<AlinuxOS> dieman, ekiga works great for me...
<Kamion> oh
<Kamion> we don't enforce 2GB clearance though
<AlinuxOS> ekiga 2.0.1 works well as actual ekiga-cvs version.
<dieman> AlinuxOS: the upgrade, rather
<dieman> AlinuxOS: some files conflict in the hoary->dapper case
<dieman> (its an unsupported case, but just mentioning)
<AlinuxOS> dieman, ah...understand.
<dieman> after i get the in-place procedure down i'll have to get fai manhandled into working how i want it to.
<mdz> Kamion: we should
* Keybuk starts downloading a dvd image to test
<Keybuk> nobody seems to have done that one yet
<dieman> heh
<Kamion> it's actually a partman-auto bug, and affects the install CD too
<mdz> Keybuk: I tested i386 and amd64 yesterday, but there seem to be new ones now
<Riddell> mdz: can I upload this change to ktorrent?  it just adds our normal patch and line to generate a .pot file http://oculusaquilae.de/kubuntu/fixes-dapper/pot_generation.diff
<mdz> Riddell: sure, why not
<Keybuk> heh, either wget or the http server are busted
<AlinuxOS> mjg59, I've talked with BPG Tech font author about some imperfections of his pack...he decided to collaborate with me(and our community) he is worrking on GNOME/KDE special/suitable font collection... restructurating horizontal and vertical spaces. So I'm verry happy.
<Keybuk> one of them really doesn't like opening a 3GB file
<ogra> likely the server
<ogra> i wget'et a 5G file in dapper already
<iwj> mdke: See mail re ubuntu-docs (uploaded and accepted, it seems).
<Keybuk> yeah it's the server, it just disconnects :)
<mdz> Kamion: so long as we're changing ubiquity, is it trivial to fix the progress messages (for 32gnome_power_manager and mkinitramfs)?
<Keybuk> Znarl: you may want to look into that
<Kamion> mdz: what's broken for 32gnome_power_manager?
<mdz> Kamion: it displays "Running 32gnome_power_manager..."
<Kamion> mdz: it does the same sort of thing for all the target-config hooks
<mdz> but that one takes 10+ seconds to run; I don't even see the others
<Kamion> I could strip numbers from the start, but anything more would take translation changes
<mdz> never mind, it's just ugly
<Kamion> I'll strip digits
<mdz> anything more I can do to try to track this looping problem?  are you unable to reproduce it?
<Znarl> Keybuk : Sorry, what is broken?
<mdz> stripping the digits doesn't really help; don't bother
<Kamion> ok
<Keybuk> Znarl: wget http://cdimage.ubuntu.com/cdimage/dvd/current/dapper-dvd-amd64.iso
<pitti> Mithrandir: what do I have to do again to finish oem customization and trigger the oem user setup wizard?
<Keybuk> Znarl: the server bails and disconnect
<Keybuk> Znarl: rather than serve a 3GB file
<Kamion> mdz: I don't think fixing the looping problem any further is going to be feasible
<mdz> ok
<Kamion> just the set_value
<mdz> and fixing the range to be minimum 2.x gig is non-trivial?
<mdz> that would make this impossible to trigger in the way I've done it
<Znarl> Keybuk : Ah, boron - one of the cdimage machines, is running breezy apache.  
<mdz> Kamion: seems like it should be straightforward if ubiquity already has knowledge of that value
<Kamion> mdz: I'm in progress on that
<Kamion> I'm fixing it in the right place, though, namely partman-auto
<_ion> http://johan.kiviniemi.name/music/ion-schizophrenia-prev1.ogg
<Kamion> mdz: fixing the mkinitramfs progress message should be trivial, though; I'll do that
<Lure> Kamion: I know that LVM is no go for ubiquity, but is it safe to install another install on the system where there is already LVM version (using regular partitions)?
<Kamion> Lure: I'm told it doesn't work right
<Kamion> there's a bug open - it doesn't disable the existing logical volumes so the kernel sees the partitions as busy
<Kamion> if you already have the partitions you need to install on created by some other means, or if you disable LVM by hand, it should work
<Lure> Kamion: ok, but no corruption? Then I will try it now and report back...
<Kamion> Lure: use absolute current ubiquity, >= 1.0.1
<Kamion> Lure: and take backups
<Lure> Kamion: current daily (Ubuntu) is fine?
<Kamion> Lure: check with dpkg -l ubiquity, but should be
<Lure> Kamion: I know - have got that lession...
<Lure> ;-)
<Kamion> I expect you'd want to use manual partitioning
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/partman-auto-resize-bounds.diff
<Lure> Kamion: yes, I always manually partition and this will be my first try of Ubuntu ubiquity (always tested Kubuntu only)
<mdz> Kamion: I'll give it a go
<Kamion> mdz: the extra bit added on over 2GB is to defend against rounding errors
<Kamion> mdz: if you're applying it on the fly, it's in /lib/partman/automatically_partition/10resize_use_free/do_option
<mvo_> mdz: permission to upload http://people.ubuntu.com/~mvo/gconf2_2.14.0-1ubuntu2.debdiff ? It fixes a issue seb128 discovered during the breezy->dapper upgrade
<mdz> Kamion: the install is larger than 2GB anyway
<Kamion> mdz: not here it's not
<mdz> Kamion: at peak, with all langpacks from the CD?
<Tonio_> hi everyone
<Kamion> mdz: I just did a successful install where fdisk reported 1851749 1K-blocks
<Kamion> I imagine langpacks will cause it to vary a bit, but not that much
<mdz> df reported 2.0G for me
<mdz> during the install
<mdz> mvo_: sure
<Kamion> 1.9G here
<Kamion> I will check that it isn't just missing ENOSPC though
<Kamion> but the copying is all done in python, so it would raise an exception
<mdz> Kamion: I'll do a 2.0G install as part of this test to check
<mdz> Kamion: or you're saying that's what you do?
<Kamion> just shove the resize slider up to maximum ...
<Kamion> that's what I'm doing
<dholbach> mdz: ok to upload ubuntu-artwork for another fix?
<mdz> dholbach: what is it?
<dholbach> bug 34521
<Ubugtu> Malone bug 34521 in ubuntu-artwork "network monitor's icon have too much unused space" [Wishlist,Confirmed]  http://launchpad.net/bugs/34521
<dholbach> i can bundle that with the next upload, if you want
<Kamion> mdz: oh, the figure I quoted was df, not fdisk; I think df was leaving out blocks reserved for root
<LaserJock> hmm, is evince going to be replaced by evince-gtk in ubuntu-desktop?
<mdz> dholbach: you'll have to do more icon uploads anyway, so might as well wait
<dholbach> ok
<ogra> LaserJock, evince-gtk is a xubuntu mutation
<Kamion> LaserJock: no
<LaserJock> hmm, my xubuntu-desktop dist-upgrade wants to remove evince and ubuntu-desktop
<Kamion> ubuntu-desktop and xubuntu-desktop are not currently coinstallable then
<LaserJock> ok, :/
<LaserJock> I just wondered if that was intentional
<ogra> hmm, thats indeed not nice
<sladen> could evince-gtk provide evince ?
<mdz> Kamion: hmm, I applied your patch, but the minimum is still 61.0M
<Kamion> sladen: I don't want evince-gtk to be selected by mistake
<ogra> many ltsp users with low end machines want to use xfce on edubuntu for the clients
<Kamion> ogra: so they can uninstall {ed,}ubuntu-desktop. deal.
<dieman> or just use the task names instead
<ogra> Kamion, yes :(
<dieman> with aptitude
<Kamion> mdz: that's the minimum for the partition you're resizing, not for the free space created
<Kamion> the UI is not very clear, I'm afraid
<mdz> Kamion: that partition has about 2G worth of Windows XP on it
<ogra> dieman, the usual edubuntu user is a teacher and happy if he understands synaptic ;)
<mdz> so that isn't right either
<dieman> ie: aptitude install "~t^ubuntu-desktop" "~t^xubuntu-desktop" evince-
<dieman> ogra: yah, i know ;)
<ogra> dieman, not terminals :)
<Kamion> mdz: oh, my patch will do nothing about that; that's weird
* dieman hugs aptitude
<ogra> s/not/no/
<mdz> Kamion: that seems extremely backwards though
<mdz> it says "New partition size"
<mdz> not "existing partition size"
<Kamion> I know
<Kamion> it means new size for the partition being resized
<Kamion> I know it's unclear, but it's so late
<mdz> this disk has only one partition
<Kamion> mdz: what does 'ntfsresize -f -i /dev/hda1' (or whatever) say, specifically the "You might resize at" line?
<Kamion> oh
<mdz> 3232MB
<Kamion> resize_use_free has a devfs assumption
<ogra> infinity, still around ?
<Kamion> get_ntfs_resize_range that is
<ogra> Kamion, can you trigger a livefs build for edubuntu ?
<mdz> indeed
<Kamion> ogra: running
<Kamion> mdz: working on it
<ogra> Kamion, thanks
<mdz> Kamion: not critical if it isn't safe
<Kamion> it should be straightforward, PARTITION_INFO gives the path
<Kamion> oh, there's a comment in the file saying why that won't work ... I'll special-case
<mdz> yay, the kernel built
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/partman-partitioning-ntfs-resize.diff
<Kamion> mdz: can you try that? applies to /lib/partman/resize.sh
<Kamion> I can get an NTFS partition here but it will take another Windows installation
<Kamion> need to go and do something about dinner now
<mdke> iwj: thanks
<lemsx1> i noticed that in ntp you guys fix a bug that prevented the interface to be fully up on reboot
<lemsx1> Ignore errors from ntpdate, otherwise the interface might not come fully up.
<lemsx1> yet 2 of my test dapper installations do just that... and i purged ntp. same thing
<mdz> Kamion: in addition to the other patch, right?
<Kamion> mdz: yes
<Kamion> I've uploaded the other patch now; my tests seemed fine
<lemsx1> doing: ifconfig eth0 up and running dhclient3 by hand does the trick
<lemsx1> but i added pre-up to interfaces and now it always works
<lemsx1> # The primary network interface
<lemsx1> auto eth0
<lemsx1> iface eth0 inet dhcp
<lemsx1>         pre-up ifconfig eth0 up
<lemsx1> these problems didn't happen on Breezy
<Keybuk> lemsx1: please file a bug
<lemsx1> Keybuk: ok. i'll research that now. though i don't know what it should apply to
<Keybuk> lemsx1: "ntp" seems a good guess
<lemsx1> Keybuk: or netbase?
<Keybuk> lemsx1: netbase isn't doing anything here
<mdz> Kamion: at first blush, I get the same behaviour. will check into it.
<Keybuk> lemsx1: dhcp3 perhaps
<lemsx1> Keybuk: netbase: /etc/init.d/networking
<Keybuk> lemsx1: that script does nothing on most people's machines
<Kamion> mdz: set -x in that function to see what we're passing to ntfsresize would be useful
<infinity> ogra: Yes, I'm back, couldn't sleep.  What's up?
<mdz> Kamion: shouldn't matter that I'm running ubiquity for the second time in this session, right?
<lemsx1> Keybuk: are you sure? it seems to be calling ifup -a
<Keybuk> lemsx1: yes, I'm sure
<ogra> infinity, already done, i didnt want to bother busy Kamion with livefs builds
<lemsx1> Keybuk: so, dhcp3 should make sure the interface is fully up before running the client bound to it?
<Keybuk> lemsx1: please, just file a bug and we'll look into it when edgy opens
<lemsx1> Keybuk: understood
<Kamion> mdz: no
<mdz> Kamion: backupdev=/var/lib/partman/backup/
<mdz> is that right?
<mdz> that's causing the entire if block to be skipped
<Kamion> hmm, I may have been barking up the wrong tree then; if there's no backup devices directory then that block doesn't matter
<Kamion> but it should be there, it's created by init.d/backup
<mdz> something weird is happening
<tsume> huh
<Kamion> oh, $dev is empty
<mdz> yes
<mdz> all of the args are
<tsume> is anyone else getting permission denied from anoncvs co on savannah?
<Keybuk> tsume: incredibly off topic for here
<tsume> Keybuk: this is a channel with tons of developers, not users which don't know how to use CVS
<Kamion> oh, partman madness
<mdz> Kamion: I have no idea how this is supposed to work
<mdz> should that be $1 or something?
<Kamion> mdz: I have to sort out dinner for the child here, but I know roughly what to do; will be back soon
<Keybuk> tsume: no, this is a channel for co-ordinating Ubuntu development... which is right now in release preperation; and we don't need savannah anoncvs to do that;  if you've having problems, taking it to their support forum
<tsume> Keybuk: though I should ask in ##freebsd since they(and I) hack on code casually
<jcole> tsume: you're in the wrong room bud
<lemsx1> bug 46190
<Ubugtu> Malone bug 46190 in ntp "network interface not fully up" [Normal,Unconfirmed]  http://launchpad.net/bugs/46190
<tsume> while I'm here though :) What in the worls does debian/or ubuntu do to grub? :P
<mdz> tsume: that's enough
<ogra> fabbione, ^^^
<tsume> mdz: could you please include lilo with the installcd?
<Kamion> tsume: we do, on the alternate install CD.
<mdz> tsume: it is there, and has been since the first release.  please stop making noise in this channel.
<Kamion> mdz: it's a difference between busybox sh and bash in the handling of local variables, triggered by some slightly psychopathic partman code; easy to work around
<fabbione> ogra: ?
<ogra> fabbione, he's calmed now, all fine it seems
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/partman-partitioning-ntfs-resize.diff updated
<dAndy> Kamion: i added the kickstart file i used for the ftp install to the bug, we are not using any proxy, very weird
<mdz> Kamion: testing
<mdz> Kamion: works
<mdz> I get a range of 3-6G
<tsume> mdz: hmm
<tsume> mdz: do you know anyone in the debian or ubuntu community who works on grub?
<fabbione> tsume: zul does sometimes
<mdz> tsume: like the others here, I am very busy preparing the release and do not have time to chat
<tsume> mdz: I don't either :)
<tsume> mdz: I'm just trying to track down a hardware problem with grub + whatever mb is in this laptop.
<Keybuk> tsume: please do so on #ubuntu
<fabbione> tsume: i did answer you. please now move on
<tsume> Keybuk: they are users, not developers
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
<fabbione> tsume: you had an answer. drive trough.
<tsume> Keybuk: and anyway, I've beatten the grub to death 100 million times over. I asked a simple question. And anyway, even if you kick, ban, etc. I can simply evade. so best  to just give me a simple one word answer "yes or no" and I'll be on my way. Its a grub memory loading problem. I'm just trying to find a knowledgable bootloader person.
* tsume was kicked off #ubuntu-devel by Keybuk (Keybuk)
<Keybuk> bored, now
* mode/#ubuntu-devel [+b *!*@zanshin.tsumelabs.com]  by fabbione
* tsume was kicked off #ubuntu-devel by fabbione (fabbione)
<AlinuxOS> :)
<Kamion> mdz: hooray. will upload
<ogra> fabbione, Keybuk, thanks
<mdke> Znarl: around?
* mode/#ubuntu-devel [+b tsume*!*@*]  by fabbione
<mdz> Kamion: alt CD overflow is fixed in the current build, yes?
<mdz> hmm, no, needs a new build
<wasabi> Great. Tor.
<yupi> hey, this is tsume. You're all dumb assholes
<yupi> :)
<tseng> -|- 4 - #mono: ban *!*@*tsumelabs.com [by  migHome!~miguel@c-24-218-111-14.hsd1.ma.comcast.net, 5570995 secs ago] 
<tseng> fyi
<yupi> sstill using ubuntu on my network though :P
* mode/#ubuntu-devel [+b *!*@*tor/session/external/x-1f9b789f3ffbbec9]  by fabbione
* yupi was kicked off #ubuntu-devel by fabbione (fabbione)
<Seveas> fabbione, tor/session/*
<mdz> Kamion: with the slider set to max, the low disk space warning just came up and said 99%
<fabbione> Seveas: can you report it to freenode staff please?
<mdz> er
<fabbione> Seveas: and get a kline please
<iwj> Phew.  Hopefully that'll be the last firefox before the dapper release.
<Seveas> fabbione, they're not so generous with k-lines
<mdz> Kamion: then I got "Installation complete" prematurely, the copy didn't even finish and none of the following steps were run
<Kamion> mdz: bug 46160
* mode/#ubuntu-devel [-b *!*@*tor/session/external/x-1f9b789f3ffbbec9]  by fabbione
<Ubugtu> Malone bug 46160 in ubiquity "base-installer/kernel/linux/link_in_boot missing from templates" [Major,Unconfirmed]  http://launchpad.net/bugs/46160
<Kamion> er, no
<Kamion> (sorry, wrong bug)
* mode/#ubuntu-devel [+b *!*@*tor/session/*]  by fabbione
<Kamion> mdz: that's the install.py crash handling fixed in ubiquity 1.0.3 surely
<fabbione> Seveas: well report him as abuser or whatever
<mdz> Kamion: at any rate, it seems clear that the crash was because it ran out of disk space
<Kamion> mdz: do you want me to add 200MB to those limits then?
<Kamion> seems like it should do
<mdz> Kamion: I think that ought to be suffiicent, yes
<riii> hi this is tsume. Nice try. whatever :)
* mode/#ubuntu-devel [+b *!*@*.sbtnvt.adelphia.net]  by fabbione
* riii was kicked off #ubuntu-devel by fabbione (fabbione)
* Keybuk wonders at which point it becomes easier just to nip round his house and take his computer away
<fabbione> Keybuk: he is at the best a script kiddy with 2/3 sheells around
<tseng> mode +r might help for the time being
<fabbione> Keybuk: and he already burned 3 of them
<Keybuk> tseng: what does that one do?
<wasabi> Hhe.
<gomen> hi this is tsume. :) whatever :)
<infinity> gomen: Please respect the fact that we're trying to release a product (one that you use, apparently) in just over a week.  I can't ask you to stop acting like a child, but please stop wasting OUR time with your games.
<fabbione> Keybuk: now he will remove reverse
<tseng> only registered users can join
<wasabi> scriptkiddies. =(
<tseng> Keybuk: ^
<wasabi> How do I add myself to that ubuntu/member/thing?
<gomen> infinity: okay
<tseng> wasabi: talk to Seveas 
<gomen> infinity: then unban me and I'll sit silent
<fabbione> gomen: specially because you are so busy acting like a child that you did not even notice that i did answer your question
<fabbione> way before you got banned
<gomen> infinity: I'll even help, but I just don't expect to be treated mean. I like simple answers, yes, no, or I don't know.
<fabbione> gomen: YOU GOT THAT ANSWER
<fabbione> gomen: possible you can't even read your scrollback?
<gomen> fabbione: privmsg please and I'll explain :)
<Kamion> gomen: I doubt anyone will waste their time helping you any more anyway.
<_ion> He's just teasing you.
<fabbione> gomen: no
<dieman> grats to whoever banished ld_preload from openoffice on amd64
<gomen> fabbione: I liked your answer, and the others. except Kamion's, who I've ran in to in the past, giving me a bad attitude answer instead of my wanted short answer.
* mode/#ubuntu-devel [+b *!*@69.249.192.246]  by Keybuk
* gomen was kicked off #ubuntu-devel by Keybuk (Keybuk)
* mode/#ubuntu-devel [+r]  by Keybuk
<Kamion> oh I feel such pain
<Keybuk> Kamion: you bad, bad man
* mdke hugs Kamion 
<tseng> thats Keybuk.
<tseng> *thanks
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<tseng> I had enough of this guy on GIMPnet
<tseng> we'll want to drop that in 10-15 minutes
<Keybuk> yup
<Keybuk> just long enough for him to get bored
<fabbione> imho we could just switch to +m for release time
<fabbione> he might be very well registered..
<tseng> not 6 times
<fabbione> tseng: you wish :)
<Seveas> tseng, even the bots are registering nowadays
<wasabi> Seveas: How do I get added to that ubuntu/member/thingy? :)
<Seveas> wasabi, by telling me your real launchpad ID 
<wasabi> ahh! "wasabi"
<wasabi> https://launchpad.net/people/wasabi
<ogra> gah, my livefs build clashed with dia
<Seveas> ok, next time I see lilo I'll have him set your cloak
<wasabi> neato.
<infinity> mdz: I'm hacking on weddell right now, so if you could refrain from doing any livefs builds on ia64 (somehow, I doubt you want any anyway), that would be cool.
* mode/#ubuntu-devel [-r]  by Keybuk
* wasabi installing Ubuntu/ARM.
<LaserJock> iwj: ping?
<janimo> mvo_: hi
<mvo_> hello janimo
<janimo> mvo_: since we now have packages in xubuntu-desktop that conflict with ones in ubuntu-desktop
<janimo> people can have difficulties upgrading
<Riddell> Kamion: important patch for kde ubiquity http://muse.19inch.net/~jr/tmp/ubiquity.diff
<janimo> bug 46191
<Ubugtu> Malone bug 46191 in xubuntu-system-tools "xubuntu-system-tools conflicts with gnome-system-tools" [Normal,Confirmed]  http://launchpad.net/bugs/46191
<janimo> mvo_: can you see a clean nonitrusive solution?
<Kamion> Riddell: is it in your branch?
<Riddell> Kamion: no
<Kamion> Riddell: ok; can you provide a changelog entry?
<Kamion> Riddell: er also surely you should have an else branch there
<Kamion> like return None or something
<Riddell> it works fine as it is
<Riddell>  * fix crash in country selector when nothing is pre-set
<Kamion> I'd like to add else: return None
<Kamion> just for clarity
<Riddell> tesing
<Riddell> testing
<Kamion> (that's what gtkui doe)
<Kamion> s
<mdke> does anyone know what setup the wikis on palmer use? mod_python/cgi/fastcgi?
<janimo> mvo_: sorry, did you write anything after me pasting the bug? I may have hit a ctrl-L too early
<Riddell> Kamion: yes, thatt is fine
<Riddell> -win 35
<Riddell> doh, I knew I shouldn have tested a spanish keyboard
<Kamion> heh
<Kamion> ok, uploading nowish
<janimo> will there be separate announcements for the derivatives for RC?
<mvo_> janimo: no, I have not (was distracted)
<janimo> god
<janimo> good
<mvo_> janimo: hm, a pretty anoying problem :/
<Kamion> WARNING: Loop detected: /lib/modules/2.6.15-23-powerpc/volatile/new_ath_hal.ko which needs new_ath_hal.ko again!
<Kamion> interesting
<mdz> fun
<Kamion> spotted while reading through the syslog attached to bug 46160
<Ubugtu> Malone bug 46160 in ubiquity "base-installer/kernel/linux/link_in_boot missing from templates" [Major,Fix released]  http://launchpad.net/bugs/46160
<Kamion> (my life is so exciting)
<Kamion> mjg59: looks like a madwifi-ng thing?
<Kamion> WARNING: Module /lib/modules/2.6.15-23-powerpc/volatile/new_ath_hal.ko ignored, due to loop
<Kamion> WARNING: Module /lib/modules/2.6.15-23-powerpc/madwifi-ng/new_ath_rate_sample.ko ignored, due to loop
<Kamion> WARNING: Module /lib/modules/2.6.15-23-powerpc/madwifi-ng/new_ath_pci.ko ignored, due to loop
<Kamion> (rest of relevant chunk of log)
<BenC> Kamion: yeah, I show the same thing on my ppc
<BenC> I only have new_ath_hal.ko and ath_hal.ko on my system though
<BenC> nm, I do have the others, but depmod isn't reporting any problems with them
<janimo> mdke, I see that in docteam svn the xubuntu guide while copied in language dirs is not really translated.
<mdke> janimo: it has only been in rosetta for a few days
<janimo> do I upload like this? Is it needed for rosetta?
<Kamion> it happens while doing dpkg-reconfigure -fnoninteractive linux-image-2.6.15-23-powerpc
<janimo> mdke: yes, but does an upload help if it happens now than say in 3 days?
<mdke> janimo: I'm not adding new translations anymore. Only post-release
<janimo> I got the impression that something may block on it
<janimo> mdke, and existing translations remain in current sate?
<janimo> state
<mdke> janimo: I think you should do an upload with what we have so that the structure is in place for post-release updates
<janimo> in that case I can upload whenever
<janimo> ok
<mdke> but it should be soon, because the freeze for them was a week ago
<janimo> yup
<mdke> janimo: I'll continue to email you when I add updated translations to our repository post-release
<janimo> ok, although I assume they will go in via upadated langiage packs not by my uploading ?
<mdke> janimo: no, they'll need -updates of xubuntu-docs
<janimo> ok then
<infinity> 21:57 <doko> and could you pester Riddell and Mithrandir about scim support for OOo on amd64?
<infinity> Mithrandir / Riddell : Do you know what that's about?
<mdke> bbl
<Kamion> mdz: I believe all my installer changes from today are in now, pending builds
<mdz> Kamion: was just reading them
<infinity> Mithrandir / Riddell : I'm about to do an OOo-amd64 upload, but doko pinged me with that after asking me to do the upload.
<mdz> Kamion: can we cross off the preseeding fix or does that need confirmation in a real build?
<Kamion> mdz: oh, needs confirmation after d-i has built, really
<Kamion> easy to test with the gfxboot menus
<mdz> Kamion: just did an alternate build; looks like the sizes are OK now
<Mithrandir> infinity: no idea.
<infinity> Mithrandir: Right then.  I'll just do this upload as-is, then.
<bddebian> infinity: When you get a chance can you please clear the dep-wait on libkwiki-perl now that libspoon-perl has hit?
<infinity> Well, when it's done downloading all the crap...
<infinity> bddebian: It'll auto-clear.
<bddebian> Hmm, OK, thx
<Kamion>    * Replace 6.04 with 60.6 in generic/libs/generic.ent.
<ivoks> :)
<Kamion> iwj: I'm assuming that typo was unique to the changelog?
<bddebian> doh
<Keybuk> it's typos like that where you get a scared shiver to think there may *be* a 60.6 one day
<ogra> Keybuk, scared ?
<Keybuk> ogra: it's like that one day it'll be May 20060
<ogra> that gives me a warm feeling :)
<Kamion> 2060 surely
<ryang> oh please, even small animals are messy. http://img60.imageshack.us/my.php?image=p51002020xi.jpg
<ogra> yeah
<Kamion> I don't think I can do this for another 54 years
<Keybuk> uh, yeah, typo :)
<ogra> lol
<Keybuk> I'll be 80 in 2060
<ogra> i'll be dead
<ogra> but still :)
<ivoks> nice to see you relaxed, guys :)
<mdz> dholbach: around?
<Kamion> infinity: any idea why firefox 1.5.dfsg+1.5.0.3-0ubuntu3 doesn't seem to have started building yet?
<dholbach> mdz: yes
<Kamion> infinity: oh, never mind, it took its sweet time to publish for some reason
<mdz> dholbach: I seem to recall that when I first looked at the book, it had an ubuntu logo in the heading
<mdz> dholbach: now it just has an empty brown band
<dholbach> mdz: i'll look at it
<wasabi> Surely somebody sells plain Ubuntu logo stickers without text.
<Kamion> ... because I didn't take account of daylight savings. go me.
<Keybuk> wasabi: I'm not sure, most people have been put off by Jane's Pantone Facism
<dieman> bwahaha
<dieman> pantone facism
<mdz> wasabi: the pussycat dolls might
<wasabi> Wow. That made pretty much no sense.
<Keybuk> wasabi: they stole our logo
<wasabi> That what who?
<Keybuk> http://www.pcdmusiclounge.com/Home.do
<wasabi> Hahah they totally did.
<ryang> how off-topic
<bddebian> Sue, sue!!! :)
<ogra> ryang, right, that belongs to #ubuntu-art :)
<ryang> OculusAquilae, exactly :)
<ryang> whoops :(
<OculusAquilae> :)
<ryang> OculusAquilae, sorry. meant ogra :)
<ogra> :)
<OculusAquilae> np :)
<mdz> Riddell: how are your CD sizes?
<omeg> It's kind of funny when someone tries to tell you that Windows == Unix because they both have a kernel.
<mdz> Riddell: and any further word on the book chapter?
<dholbach> mdz: want me to upload now?
<mdz> dholbach: you found the trouble?
<dieman> Keybuk: wow, they completely stole th elogo
<dholbach> mdz: I nicked the logo from ubuntu-docs :)
<ryang> I thank whoever fixed ruby :)
<mdz> dholbach: what's the purpose of the 'Other' placeholder?
<dholbach> mdz: the missing kubuntu chapter
<infinity> Kamion: All those python tracebacks in the d-i build log are expected, right?
<Kamion> infinity: ...
<Kamion> not AS SUCH
<infinity> Kamion: help-to-gfxboot barfing on missing files...
<Kamion> buggeration
<Kamion> it's got a set -e in there, why isn't it failing properly damnit?
<Kamion> oh, pipelines
<Kamion> lalala I hate the shell some days
<Keybuk> the thing to remember when doing any programming in shell is ...
<Keybuk> you're using the wrong language
<Keybuk> once you've got that in your mind, it all makes sense
<Keybuk> :p
<mdz> dholbach: anyway, yes, OK to upload if you're happy
<infinity> Kamion: Well, just glad I happened to be watching the log...
<dholbach> mdz: if you want me to strip the Other link and just keep some padding in, that's fine too
<mdz> dholbach: since we may need to release without it, it may be better to remove it for now. it doesn't serve any purpose; if we get the chapter we need to update the package anyway
<dholbach> ok
<dholbach> i'll keep the padding in until we either get the kubuntu chapter or decide to ship without it
<Lure> Kamion: is on_back_clicked crash known (ubiquity 1.0.2) - I got it after clicking Cacnel on confirm partitioning?
<Kamion> Lure: no, don't think so
<Kamion> Lure: but would need to see the trace
<Lure> will report it
<omeg> Hehe, someone is trying to convince me that Windows is "almost indistinguishable from Unix".
<Kamion> thanks
<Lure> gtkui.py,  line 1032, NoneType on attribute stdin
<omeg> I see.
<Kamion> Lure: oh, I need the full /var/log/installer/syslog for that
<Kamion> gparted is probably crashing
<Kamion> though not certain
<Lure> will collect everything and report now
<Kamion> it may just be too late to fix now though
<Lure> Kamion: bug 46211 if you need anything more, let me know
<Ubugtu> Malone bug 46211 in ubiquity "crash on Cancel + Back on partitioning" [Normal,Unconfirmed]  http://launchpad.net/bugs/46211
<Kamion> Lure: hmm, inconclusive. if you can reproduce it by following the exact same steps except by starting the installer with 'UBIQUITY_DEBUG=1 sudo ubiquity', then the syslog might be more helpful
<Lure> Kamion: will do
<Kamion> thanks
<Lure> Kamion: reproduced with debug
<Lure> Kamion: next try when I have selected OK also crashed - bug 46215
<Ubugtu> Malone bug 46215 in ubiquity "crash on manual parititioning on disk with existing LVM partitions" [Normal,Unconfirmed]  http://launchpad.net/bugs/46215
<mdke> Znarl: unping
<dholbach> good night
<bddebian> gnight dholbach
<Kamion> Lure: ok, you'll have to use the alternate install CD on such systems for dapper, I'm afraid; but thanks for testing, I'll try to make it work early edgy
<Lure> Kamion: we should just document that users should deactivate LVM VG before running ubiquity - this works (installer is just copying files)
<Lure> Kamion: like know issue and workaround
<Kamion> Lure: sounds like reasonable release notes fodder
<Kamion> mdke: is the above ^-- something the doc team can incorporate? I'm not sure where release notes are being maintained at the moment, or by whom
<Burgwork> Kamion, nor do we
<mdke> Kamion: a dual job between you guys and mgalvin 
<Kamion> oh
<mdke> (i think)
* Kamion goes to get dinner, then I'll think about it
* mgalvin waves
<mgalvin> DapperReleaseNotes has some stuff on it
<mgalvin> (not done yet but WIP)
<mgalvin> Kamion, Lure: please feel free to add to it, i will not have time to work on it myself again until the weekend anyway
<Lure> mgalvin: ok, I can write something and Kamion will the decide if that makes sense to include or not
<mgalvin> k cool
* bddebian kicks infinity for letting him forget about ivtools :-(
* mgalvin heads home
<Burgwork> Seveas, are you around?
<mdke> yeah, Seveas, ping x 2
<mdke> (unrelated)
<Burgwork> you know, we might need to plan for a "Seveas gets hit by bus"-size event
<Seveas> lol
<Seveas> please take a number 
<Burgwork> Seveas, can you talk with HedgeMage and give the ok for me to take ownership of #ubuntu-ca ? the current contact is awol
<Seveas> who is current contact?
<mdke> Burgwork: you can use #ubuntu-locoteams
<Burgwork> mdke, hmm, didn't even know that channel existed
<Lure> sladen: around?
<kent> Seveas: How come Sweden is not on this list? We have an active community..   http://www.ubuntu.com/support/supportoptions/local
<Seveas> kent, e-mail henrik@ubuntu.com
<mdke> kent: because that list is incomplete. Mail the links to loco-contacts@lists.ubuntu.com and I'll add them
<mdke> no, henrik is a busy guy
<mdke> :)
<kent> mdke: Seveas   loco-contacts@l.u.c then and not henrik?
<Seveas> mdke, ah, I thought henrik was webmaster and only he could edit that :) 
<mdke> kent: yeah. I am going to put some time aside to sync that page from the LoCoTeamList page on the wiki
<kent> mdke: will mail the relevant information in a min then. thanks!
<mdke> Seveas: henrik is webmaster yeah, but it's a wiki. A few people can edit it.
<mdke> kent: thanks
<Kamion> Lure: added to a new "Known Issues" section on DapperReleaseNotes
<Kamion> that page needs a good bit of love though
<Lure> Kamion: great
<Lure> Kamion: should we reference actual bug# from RN for easier tracking?
<Kamion> sure, go ahead
<Lure> Kamion: I think we can mark bug 43828 as duplicate of bug 43453
<Ubugtu> Malone bug 43828 in ubiquity "Kubuntu 6.06 Flight 7 installer crashes while partitioning" [Normal,Unconfirmed]  http://launchpad.net/bugs/43828
<Ubugtu> Malone bug 43453 in ubiquity "live cd partitioner doesn't understand lvm properly" [Normal,Confirmed]  http://launchpad.net/bugs/43453
<jdub> when i was in .za
<jdub> i connected my lappy to the projector
<jdub> restarted X
<jdub> and it automagically started in 1024x768
<jdub> it made me happy
<mjg59> Blind luck
<mjg59> (sadly)
<jdub> yeah
<Burgwork> jdub, you had a far different experience then I did last time
<jdub> i tried not to believe it happened
<jdub> so i would not be disappointed next time
<imbrandon_> heh
<mjg59> Now you've told us
<mjg59> So it won't
<jdub> i'm doing another talk this afternoon
<jdub> so i'll give you an update on the fantasy automagic
<mjg59> But xrandr ought to basically work
<jdub> oh yes, it works very well
<mjg59> Plug in, display resolution it down to the right res, hit the display hotkey
<mjg59> xrandr is a very small part of the future
<mjg59> RH are working on bringing us the rest of it
<jdub> ajax is working on x autoconfig?
<HiddenWolf> mjg59: that's aiglx? 
<mjg59> No
<mjg59> Uh
<mjg59> jdub: Yes
<mjg59> HiddenWolf: No
<Burgwork> daniel stone is working on input hotplug apparently
<mjg59> jdub: That's his job
<jdub> aiglx is just bringing us the past
<mjg59> aiglx brings us to the technological level of Vista and MacOS
<HiddenWolf> jdub: uh, ok. :)
<jdub> mjg59: then why am i seeing him committing to metacity sex foo?
<jdub> he is a bad person
<mjg59> X autoconfig stuff brings us to the technological level of Win 98
<mjg59> jdub: Because X autoconfig with no sex foo makes people sad
* jdub trolls ajax in #xorg
<HiddenWolf> mjg59: well, I installed a windows recently, and had to download a 38mb driver package to get rid of visible redrawing of the screen. I'd say that X/Linux is already ahead in some ways.
<jdub> that illustrates the desperate plight of 'some'
<HiddenWolf> Oh, that driver utility required the .NET stack too. :)
<jdub> ugh, i really need to find something saner than mgp to do my talks with
<jdub> unfortunately, impress is not saner
<Burgwork> jdub, I used pointless last time, but it is not great
<Chipzz> jdub: sex foo? :P
<jdub> Chipzz: metacity/libcm effects
<Kamion> Lure: I think there may be multiple different bugs in LVM support (or lack thereof), so I think I'd prefer to keep them separate until I understand them all a bit better, rather than having one giant "LVM is broken" bug :-)
<Chipzz> libcm?
<jdub> the compositing manager innards that metacity uses (in spiftacity mode)
<Lure> Kamion: makes sense - will be easier for you when it comes to fixing them
<Kamion> right
<jdub> fabbione: ping (unlikely, payload: adaptec scsi in dapper)
<Chipzz> oh, right :)
<Lure> Kamion: should we reference all LVM bugs from RN (as it looks from my tests we solve most if not all of them with workaround)?
<Kamion> Lure: may not be actually terribly helpful to users; I'd reference the clearest one or two
<Lure> Kamion: ok
<jdub> Kamion: has the dapper-desktop-* name change happened?
<Kamion> jdub: yes
<jdub> thanks
<Kamion> jdub: (see ubuntu-devel-announce@)
<jdub> mmm, saw that, wasn't sure it happened yet
<Kamion> I didn't send the mail until I'd made/tested the code change - although I hadn't done all the rebuilds yet then
<Kamion> infinity: BTW, my plan is to let this round of livefs/CD cron jobs happen, then disable the CD cron jobs and start doing stuff manually. You might want to disable the livefs cron jobs after they happen and when you're next awake.
<jdub> Kamion: oh, presence of .OVERSIZED files mean the images are oversize?
<Kamion> jdub: yes; in the case of Ubuntu daily-live that'll go away with the next rebuild, I hope
<Kamion> it only appeared because I did a build with the new improved ship-live but forgot to rebuild ubuntu-meta to get rid of some language packs
<jdub> Kamion: are yesterday's builds ok for testing?
<mdke> my "ssh text in human icons is too small to read" bug has been dramatically fixed by the presence of the new hotness "icons are now half the size of the screen" bug 
<Kamion> jdub: (new improved ship-live> build-essential/linux-headers as extra installable packages in an archive on the live CD)
<jdub> 20060522
<Kamion> jdub: no
<mdke> this is not the final artwork?
<jdub> Kamion: rad :-) openssh-server?
<Kamion> jdub: not at present, because you can install that from the networ
<Kamion> k
<jdub> ok
<Kamion> jdub: we are extremely space-constrained and I only want to include things that way that may be needed to get at the network
<jdub> will oversized images work on 700MB CDs?
<Kamion> nno
<Kamion> no, damn keyboard
<Kamion> the official size across the board is now 700MB
<jdub> oh, we're using 700-- aha
<jdub> right
<Kamion> if you look more closely at the apache directory index it should be pretty clear that they're >700MB ;)
<jdub> yeah ;)
<jdub> wasn't sure if they were outrageously oversized or *just* oversized ;)
<jdub> "where the crap did that 70MB come from?!" ;)
<Kamion> the technical limit (and the one imposed by MediaMotion) is actually marginally greater than 700MB, but there's not much in it
<Kamion> it's 736051200 bytes
<infinity> Kamion: Check. I'm still waiting on the OOo build of doom to complete, so I can unstall the world.
<jdub> Kamion: next rebuild is the nightly, or pushing another today?
<Kamion> jdub: nightly
<jdub> Kamion: heh, explaining to a friend that they'll have to check tomorrow ('where tomorrow means this afternoon - canonical runs on something approximating UTC or London time')
<jdub> i won't confuse him by explaining cron.hourly
<tseng> just tell him that hours fly by really fast when you work for the big C
<Kamion> jdub: "in about ten hours"
<jdub> Kamion: thanks
<Kamion> it's less than that but might as well have an insurance period
<jdub> tseng: 'the big C'... not sure mark would appreciate that
<tseng> haha
<mgalvin> jdub: hey! i will certainly catch up with dholbach about the artwork... would be neat to see all the artwork in edgy
<jdub> mgalvin: yeah! thanks for that, it's really cool :)
<mgalvin> jdub: eh np, i have been wanting to do that for a while too so i just went ahead and did it :)
<jdub> :)
<johanbr> I've managed to fiddle with the video restore options to get my machine to come back successfully from hibernation, which it didn't do before. What's the proper way of reporting these changes? There doesn't seem to be an infrastructure in place for the scripts to do the right thing on a machine-dependent basis, so I was hesitant to file a bug.
<jdub> johanbr: a bug would be good, then perhaps post to laptop-devel
<johanbr> Okay, will do. Thank you.
<Kamion> johanbr: sounds like an acpi-support kind of thing
<Kamion> it has a load of machine-dependent wonkiness
<Riddell> "debconf.DebconfError: (10, "base-installer/kernel/linux/link_in_boot doesn't exist")"  that doesn't seem good
<johanbr> Kamion: Okay. Looking at the launchpad acpi-support page right now.
<sabdfl> https://launchpad.net/distros/ubuntu/dapper/+source/gdm/2.14.6-0ubuntu2
<sabdfl> are the buildd's choked?
<jdub> sabdfl: there was some discussion earlier about OOo choking them
<sabdfl> that seems to have landed - got a load of oo.o2 goodness a second ago
<ajmitch> afternoon
<sabdfl> hey ajmitch
<jsgotangco> good morning
<infinity> sabdfl: I had the publisher disabled for a bit.  It's alive again now, gdm should build in this cycle.
<sabdfl> infinity: ok, thanks
* jdub reclaims 888MB on / by removing old kernels... (!)
<Chipzz> jdub: yea :(
<zul> jdub: wha?
<Chipzz> I complained about that here a while ago too...
<Chipzz> little positive response though
<LaserJock> jdub: kernel source or images?
<jdub> Chipzz: it's not really a problem for release-using users
<jdub> i just haven't thought about it on the laptop
<jdub> (unfortunately, my server has a small /boot, so i'm forced to think about it there)
<Chipzz> jdub: true... but I have my doubts about the ever-growing size of linux-image :S
<Chipzz> but whatever
<bddebian> Heya jsgotangco
<sabdfl> jono bacon around?
<sabdfl> or anyone else from LugRadio?
<bddebian> infinity: Still around?
<bddebian> Any archive types around?
<bigcx2> hey all
<bddebian> Hello bigcx2
<bigcx2> with the new java license is there plans to get a sun java package for dapper?
<crimsun> it's already in multiverse.
<bigcx2> really
<bigcx2> hm
<bigcx2> that was fast
<bddebian> If anyone happens to catch this.  I think libluminate6 binary needs to be removed.  Is it best to ping the mailing list, file a bug, what?
<robertj> will 7.1 hit edge on day 1ish?
<robertj> err edgy
<robertj> (Xorg that is)
<cjb> So, this has probably been asked here already, but Google desperately need to get in touch with Ubuntu SoC admins. 
<Burgundavia> bddebian, thanks for the work on the multiseat package
<bddebian> Burgundavia: Are you being serious? :-)
<robertj> when are the SoC projects going to be announced?
<Burgundavia> robertj, later today or tomorrow
<cjb> robertj: They can't be announced until the dups are cleared up.
<cjb> The dups can't be cleared up unless an Ubuntu SoC admin urgently shows up.
<cjb> That's why I'm here, see.  :)
<robertj> ahh
<shenki> oh, excellent (soc applicat patiently waiting in the wings, thinking he was rejected)
<Burgundavia> cjb, afaik, all the admins are in europe/za and thus asleep
<shenki> wern't the projects supposed to be announced on the 22nd?
<shenki> weren't
<cjb> shenki: No, it was always supposed to be today.
<cjb> The final deadline for *Ubuntu* telling Google which they'd chosen was yesterday.
<shenki> cjb: oh, i see. thanks for clearing that one up.
<cjb> So, heads up:  if we can't get in touch with anyone, one of Ubuntu's projects is going to be replaced with the project that was just below the acceptance line.
<cjb> If that sounds likely to annoy anyone, perhaps it'd be worth waking someone up.  ;-)
<robertj> w00h, that means Ubuntu has at least one project!
<Burgundavia> jdub, you around?
<jsgotangco> he's in za as well i believe
<jdub> no, he's here
<jdub> in .au
<jdub> but i can't help with that
<jdub> hold on
<jsgotangco> ahh
<jdub> jsgotangco: that was last week :)
<ajmitch> travelling the world again?
<robertj> jdub: your reponse time is pretty good, but I think we need to get you a physical terminal bell in the near future just in case for the
<jdub> ajmitch: just .za last week
<cjb> jdub: Do you want to wake someone up, or let Google handle the conflict?
<jdub> robertj: actually, someone posted (somewhere) an irssi script to pop up a notify thingy when your name is mentioned (just like xchat-gnome)
<jsgotangco> whoa
<jdub> cjb: do you know what the projects are? why is there a fall back?
<robertj> jdub: we need something that could wake you up in case you were sleeping
<jdub> oh, dupes in the list?
<jdub> robertj: my mobile phone can sometimes do that
<cjb> jdub: One of ubuntu's accepted proposals was also accepted to osdl.
<robertj> jdub: I think we need a real clapper
<jdub> cjb: ah, right. hmm.
<cjb> And since osdl has fewer projects allocated, he'll go to them unless you argue that you really want him.
<jdub> cjb: are you at google now?
<cjb> jdub: No, I was helping handle GNOME and got roped in to tracking Ubuntu people down.
<jdub> heh
<jsgotangco> much appreciated
<jdub> cjb: BenC and i have put the call out
<jdub> BenC: ;)
<BenC> hehe
<jdub> (if you use your computer in stretched mode for a while, normal mode starts to look anorexic)
<cjb> Thanks.  :)
* ajmitch is seeing plenty of stressed students in the SoC channel waiting for results :)
<ajmitch> it's quite humourous
<jdub> sadist
<jsgotangco> heh
<ajmitch> I've spent too much time around here
<jsgotangco> including yourself?
<Burgundavia> ajmitch, which networok?
<ajmitch> Burgundavia: slashnet
<robertj> are there logs?
<shenki> it's not intresting at all, imo...just 200+ people waiting around for something to happen
<cjb> Poor them.  :)
<robertj> Someone should prepare a humerous list of other projects to announce first ;)
<shenki> now the conspiracy theories are coming out: they believe google are just playing a joke by not releasing the projects :)
<LaserJock> maybe we should have them fix all Dapper bugs while they are waiting
<imbrandon> lol
<cjb> Heh.
<shenki> lol
<cjb> shenki: If they don't already know, you can tell them that the problem is students accepted by more than one org need to be assigned into one, and a replacement project chosen for the other.
<shenki> ok, thanks
<shenki> there's a google person in there, but he's not giving any info
<bddebian> LaserJock: :-)
<Burgundavia> LaserJock, heh
<LaserJock> nothing like a pre-SoC warm up :-)
<Burgundavia> LaserJock, you should suggest it
<bddebian> Gah, why can I never remember where the pre/post/foo scripts are?
<LaserJock> bddebian: /var/lib/dpkg/info ?
<bddebian> Thx LaserJock
<LaserJock> bddebian: I'm just impressed that I could remember that, it must be sticking :-)
<imbrandon> ;)
<bddebian> LaserJock: :-)
<bddebian> See, you are smarter than me :-)
<LaserJock> bddebian: maybe I'm just younger, I doubt smarter
<LaserJock> I've been in school waaaay too long to be smart :-)
<bddebian> heh
<poimen> someone was using  XGL on dapper with this two sources in the sources.list? 
<poimen> [23:55]  <poimen> deb http://xgl.compiz.info/ dapper main 
<poimen> [23:55]  <poimen> deb http://www.beerorkid.com/compiz/ dapper main
<jsgotangco> ?
<shenki> yes, they probably were...those two repo's contain cvs versions of the libraries you need to run xgl. but did you have a question?
<poimen> yea give a sec let me copy my question fro am another channel
<poimen> I followed the Xglhowtoo and got a nice working xgl/ubuntu system but today i did a apt-get update and then a apt-get upgrade and now it does not work 
<poimen> [23:59]  <poimen> I was asking me if adding this 2 sources is really necesary 
<poimen> I folowed the ati howtoo
<poimen> xglati on wiki ubuntu
<shenki> that's not for this channel
<shenki> go to #ubuntu+1
<poimen> I asked there...
<jsgotangco> the last 2 sources are not from ubuntu the chance of breaking is pretty high
<poimen> sorry no one seems to anwser
<poimen> jsgotangco thankx 
<poimen> so there is another XGL in universe right?
<shenki> the best place for info on those sources is the forums on http://compiz.info
<poimen> thankx
<fabbione> morning
<fabbione> jdub: pong
<pitti> Good morning
<fabbione> morning pitti
<Burgundavia> salut fabbione , pitti 
* pitti waves to Burgundavia and fabbione 
<ajmitch> hi pitti, fabbione 
<pitti> hi ajmitch 
<fabbione> yo yo
<Burgundavia> pitti, is a warty to hoary upgrade still supported?
<pitti> Burgundavia: since it didn't really change, it should still work
<Burgundavia> pitti, ok, just wondering for doc purposes
<neuralis> JaneW: ping
<pitti> hi kagou 
<kagou> hey pitti  :)
<dholbach> good morning!
<viviersf> rs
<pitti> mdz, ogra: ok to upload http://paste.ubuntu-nl.org/14584 to make carlos and Rosetta happy again?
<pitti> mdz, ogra: (simple fix in debian/rules to clean duplicates out of the generated pot file)
<carlos> pitti: it's not that they break Rosetta import, they break any .po editor (other than a plain editor that knows nothing about the .po format)
<carlos> ;-)
<OculusAquilae> hi carlos 
<pitti> well, true
<pitti> hi carlos
<carlos> pitti: btw, I think the .po files are also broken... but that's more difficult to fix if they uses different translations... I will try to fix that manually and talk with upstream
<carlos> OculusAquilae: hi
<pitti> carlos: alright, I updated the changelog to not claim that they break rosetta ;) (just break the tools, instead)
<carlos> pitti: thank you ;-)
<pitti> carlos: I just fixed buildd import again, so that we get fewer domains which are in rosetta's, but not in my tarball
<carlos> ok
<OculusAquilae> carlos, pitti: Are the german .po-files exported from Rosetta. They are suddenly not in the languagepack-kde-de-base
<OculusAquilae> of konversation
<carlos> I think the language pack was generated before we imported konversation
<carlos> pitti: are you going to prepare updated langauge packs tomorrow?
<carlos> to follow the schedule
<OculusAquilae> It was translated before, but now it isn't
<pitti> carlos: we uploaded new ones at Monday, but mdz told me we'll need another one
<pitti> carlos: but not sure whether we'll upload at Friday or so (I'm not here anyway, but the soyuz guys can upload the daily ones whenever mdz tells them to)
<carlos> ok
<carlos> OculusAquilae: because we were using other sources to complete Rosetta exports
<carlos> OculusAquilae: and now we are using Rosetta as the only way to generate language packs
<OculusAquilae> ah
<OculusAquilae> was a bit late to change that :)
<carlos> OculusAquilae: we were transfering things every day, and last Monday, we were supposed to have all things migrated. I'm not sure how is that we didn't detect that the Konversation's .pot file was missing
<OculusAquilae> carlos: what about k3b's language-files. they seem not to be in the language-pack too
<carlos> OculusAquilae: that's because the k3b's .pot file was broken
<neuralis> JaneW: around?
<carlos> it's fixed now, but after latest language pack release, so it has the same problem
<carlos> next update should include it
<OculusAquilae> ok
<OculusAquilae> thanks
<carlos> OculusAquilae: please, check the daily snapshots to confirm it
<OculusAquilae> ktorrent's .pot-file should be fixed in 0ubuntu5 
<carlos> OculusAquilae: so we have time to fix anything that is still missing
<carlos> OculusAquilae: I approved it yesterday, yes
<OculusAquilae> daily snapshots of what?
<carlos> OculusAquilae: of language packs
<OculusAquilae> there are daily snapshots?
<carlos> OculusAquilae: yes, Martin announced it a couple of weeks ago
<pitti> OculusAquilae:  https://lists.ubuntu.com/archives/ubuntu-translators/2006-May/000537.html
<OculusAquilae> ok I'll test
<carlos> OculusAquilae: thanks
<JaneW> neuralis: yep
<fabbione> pitti: there is a new ppc live
<sivang> Riddell: do you know if muse wnet down yeasterday? I lost my screen sessions.
<pitti> fabbione: yes, it just finished burning here :)
<fabbione> yeah
<lmanul> neuralis: ping ?
<neuralis> lmanul: pong
<lmanul> Hi :) Just got the great news !
<lmanul> Have 2 mn for a /query ?
<fabbione> pitti: did you notice that usplash on ppc live doesn't go all the way to X?
<fabbione> pitti: or is it just me?
<pitti> fabbione: sometimes it fails, in 70% of the cases it works for me
<pitti> I can't see a pattern
<fabbione> pitti: mine exits around swithing to init 2
<neuralis> lmanul: /join #olpc
<lmanul> neuralis: Ah, great, ok
<OculusAquilae> carlos: konversation seems to be still in englisch with yesterdays german langpack, k3b is ok and for ktorrent I think we must wait for the build today
* carlos checks konversation...
<carlos> OculusAquilae: everything looks ok for konversation
<OculusAquilae> hm
<sfllaw> Mithrandir: Good question.
<OculusAquilae> carlos: perhaps we must wait for the daily build of the langpack
<pitti> funny, dapper-alternate-powerpc.iso is recognized as a font file in nautilus, so you can't burn it
<pitti> seb128: ^ nice gtk bug :-P
<OculusAquilae> carlos: it
<seb128> pitti: lol
<OculusAquilae> carlos: it's definately not in language-pack-kde-de-base
<carlos> OculusAquilae: yeah, I'm checking it atm
<carlos> OculusAquilae: seems like it was imported yesterday
<carlos> so it should appear today
<OculusAquilae> ok I'll test that again tonight
<carlos> OculusAquilae: thanks
<Mithrandir> pitti: it's probably a bug in the mime database from fd.o
<fabbione> crap
<fabbione> ubiquity just crashed on me
<pitti> seb128: oh, on second look, Ctrl+R fixed it; it had a big 'A' with a box around it, and it offered archive manager, so it was not *that* wrong at least :)
<seb128> ctrl-R fixed it!?
<seb128> and when you click on it it's fine now?
<seb128> directory listing is done using the filename
<pitti> affirmative
<seb128> when you select a file it does mimemagic
<seb128> it doesn't change when you select it?
<fabbione> pitti: did you already run ubiquity on ppc live?
<pitti> seb128: now it stays stable (cdrom document with 'iso'), as it should be
<fabbione> pitti: if so go for debugging... mine crashed
<seb128> pitti: weird
<pitti> fabbione: no, currently running alternate CD install
<fabbione> pitti: ok
<pitti> fabbione: will do, but mine will still take a while (slow disk...)
<fabbione> pitti: i am rebooting right now.. but at least i want to make sure i am not the only one
<pitti> fabbione: did you see an exception in /var/log/installer/syslog?
<fabbione> pitti: no, didn't check beacuse i was running without debugging
<pitti> exceptions should still be in it; anyway, I'll try it here, too
<pitti> ETA ~ 45 minutes
<Kinnison> Morning guys
<simira> good morning, Kinnison 
* simira has the first good morning in a week
<Kinnison> Hi simira
* Kinnison hugs simira lots. LTNS
<Treenaks> morning simira 
<ajmitch> morning simira, Kinnison 
<Kinnison> ajm.
<Kinnison> Morning mvo
<mvo> hey Kinnison
<Burgundavia> hey Kinnison 
<simira> morning Treenaks, mvo 
<simira> ajmitch :)
* mvo waves to simira
<Treenaks> Welcome to #greetings
<simira> Treenaks: it's a lovely morning ;)
<sivang> hey all
* sivang hugs everybody
<sivang> simira: it is indeed so
<simira> morning sivang 
* sivang wonders if anyone searched for yeserday. muse sessions were wiped out
<\sh> moins
<\sh> did anybody tried to format a >5TB partition with xfs with an ubuntu-server kernel?
<mdz> pitti: tuxpaint-stamps is fine
<fabbione> pitti: it looks like yaboot still fails
<pitti> mdz: thanks, uploading
<pitti> mdz: good morning :)
<fabbione> Kamion: http://people.ubuntu.com/~fabbione/installer.tar.gz <- ppc ubiquity failure from the last daily
<\sh> I have the problem, that I have a 6.3TB partition and tried to format it with mkfs.xfs -f /dev/sdb1 and it only formats 301G
<pitti> fabbione: darn :/
<fabbione> \sh: probably you need to look at stuff like block size and so on
<fabbione> what if you format it with another FS?
<\sh> fabbione: that I will try now, but I thought, that someone could know ;)
<fabbione> \sh: mostlikely you will need bigger blocks or something
<\sh> fabbione: looks like...let's see
<\sh> oh wow
<\sh> the problem is somewhere else
<\sh> fdisk is the problem
<\sh> it detects the correct size of the partition but doesn't use it when I'm creating a new partition with max size
<\sh> fdisk and cfdisk are creating a partition with the maximum size...I'm writing it back to the partition table, quit fdisk and cfdisk and re-execute fdisk or cfdisk and suddenly my partition table shows me max. 301G and not the correct size
<\sh> dmesg output
<\sh> sdb : very big device. try to use READ CAPACITY(16).
<\sh> SCSI device sdb: 13515615232 512-byte hdwr sectors (6919995 MB)
<\sh> SCSI device sdb: drive cache: write back
<\sh> sdb : very big device. try to use READ CAPACITY(16).
<\sh> SCSI device sdb: 13515615232 512-byte hdwr sectors (6919995 MB)
<\sh> SCSI device sdb: drive cache: write back
<fabbione> \sh: try to dd if=/dev/zero of=/dev/bigfatdevice bs=1024 count=64
<fabbione> that should reset the partition table
<fabbione> and then do a fdisk/cfdisk
<fabbione> IMHO there is a flag you need to set for bigfatdevices
* fabbione checks
<\sh> fabbione: cool thgx
<pitti> fabbione: ppc/install succeeded, starting live now
<fabbione> pitti: ok
<\sh> fabbione: nope...same problem...cfdisk/fdisk is only allocating max. 301G (same applies for ext3)
<fabbione> \sh:         # Use gpt instead of msdos disklabel for disks larger than 2TB
<fabbione> \sh: try using parted
<ivoks> right
<ivoks> that's the only way
<fabbione> libparted supports that forma
<fabbione> +t
<ivoks> \sh: and make it XFS :)
<Amaranth> and make sure you have a good UPS to go along with it :)
<ivoks> and your own power plant
<pitti> fabbione: https://wiki.ubuntu.com/Testing/Current is not the page to be used any more?
<Amaranth> ooh, screw xfs use reiser4!
* Amaranth hides
<fabbione> pitti: dunno.. i was waiting for sfllaw to clean it up
<\sh> fabbione: same problem
<\sh> (parted) mkpart primary 0 6599421.500
<\sh> (parted) p
<\sh> Disk geometry for /dev/sdb: 0.000-6599421.500 megabytes
<\sh> Disk label type: msdos
<\sh> Minor    Start       End     Type      Filesystem  Flags
<\sh> 1          0.031 307964.419  primary
<fabbione> <\sh> Disk label type: msdos <-
<pitti> fabbione: ok, I pinged him
<\sh> shit
<fabbione> you need to make that one gpt
<ivoks> fabbione: dapper supports gpl out of the box?
<fabbione> ivoks: it should
<ivoks> fabbione: great... last time i needed distro for 2+TB disk, i had to compile my own kernel and force instalation to use it :/
<\sh> fabbione: thx :=
<ivoks> fabbione: (debian was that)
<mdz> infinity: around?
<fabbione> \sh: but with a 6TB volume i strongly recommend to use LVM on it
<Kamion> Riddell: the ubiquity failure you reported was fixed in ubiquity 1.0.4 yesterday
<pitti> good morning Kamion 
<Kamion> fabbione: you too, same bug
<Kamion> (bug 46160)
<Ubugtu> Malone bug 46160 in ubiquity "base-installer/kernel/linux/link_in_boot missing from templates" [Major,Fix released]  http://launchpad.net/bugs/46160
<Kamion> oh, huh, you *have* ubiquity 1.0.4
<Kamion> well, damn, let me investigate
<pitti> Kamion: I'm testing current CD (with 1.0.4) right now, with verbose debugging
<mdz> Mithrandir: ping
<Mithrandir> mdz: yes?
<mdz> Mithrandir: o ye of much bandwidth, I need your help to unravel this latest openoffice mess
<Kamion> confirmed that that template is indeed missing
<mdz> Mithrandir: the .desktop file changes written in the most recent changelog entry have not, in fact, taken effect
<mdz> Mithrandir: it looks like he changed a set of .desktop files which are not used in the build
<\sh> fabbione: well, tbh, they are using it without LVM...and they don't want...let's see what I can do here to change that
<mdz> Mithrandir: would you have a look?
<Mithrandir> mdz: humm, I'll take a look.
<pitti> Kamion: ok, so I can as well cancel the current attempt and rather test the alternate CD some more?
<fabbione> \sh: well it was a suggestion.. do what you are asked to
<Kamion> pitti: yes
<Kamion> I'll fix it ASAP
<ivoks> fabbione: why lvm, if i may ask?
<fabbione> Kamion: let me know when you want me to test
<fabbione> ivoks: flexibility
<ivoks> true...
<ivoks> one hardly needs one 6GB partition :)
<Mithrandir> mvo: apt-get source is buggy, it doesn't look for a exact source package match first.
<Mithrandir> mvo: so apt-get source openoffice.org on amd64 gives me ooo-amd64
<Keybuk> HAHAHAHAHAHAHAHAHA
<Keybuk> oh man
<Keybuk>  multiseat (0.9.11) dapper; urgency=low
<Keybuk>  .
<Keybuk>    * Replace hotplug deps with udev and module-init-scripts
<Keybuk> -- 
<fabbione> ivoks: from experience you grow the disks as you need
<Keybuk> sum total of changes: a change to the Depends line
<\sh> fabbione: funny thing...in 2 weeks we have to do a fully automatic installation of sles9sp3 on 600 of those servers 2x dual core opeteron systems, 16GB RAM, 8TB storage raid6 hw
<Keybuk> Barry is so in for a teasing when he wakes up
<sfllaw> pitti: Computer just crashed.
<ivoks> fabbione: i have that situation right now... two sets od 3TB partitions
<pitti> sfllaw: ouch :/
<fabbione> \sh: nice toys.. send me one
<ivoks> fabbione: one empy, other full... i'm planing copy/format/lvm/back/format/add_to_lvm :)
<mdz> mvo: that's what --only-source does
<fabbione> 600 or 599 won't make a diff :)
<HrdwrBoB> ivoks: in my experience one regularly needs large partitions
<mdz> er
<mdz> Mithrandir: that's what --only-source does
<ivoks> \sh: that meens... job? :)
<mdz> Mithrandir: it's weird, but unfortunately that's how it was designed to work
<fabbione> ivoks: you can just make the empty LVM, copy the data, make the first lvm and add it to the same VG and resize the data
<Mithrandir> mdz: ew, ok.
<\sh> ivoks: yes
<ivoks> fabbione: if i recall, there was a reason why that wasn't an option, but can't rember now why exactly...
<Kamion> Keybuk: oh dear me
<Kamion>   * Sing LA LA LA, they can't hear me
<ivoks> HrdwrBoB: over 6TB?
<ivoks> ok, we are getting offtopic :)
* Keybuk pours a vat of custard over mdke
<sfllaw> Keybuk: Mmm.  Custard.
<Kamion> dholbach: I'll try to do the apt-get.org import today
* dholbach hugs Kamion
<dholbach> Kamion: you rock! thanks a lot!
<ivoks> ok, time for work :/
<ivoks> bye, see you later
<infinity> mdz: Am now.
<mdz> infinity: guess what
<infinity> Backscroll leads me to believe I need to do another OOo build.
<infinity> Something about .desktop files.
<infinity> Well, it's either that or "guess what, chicken butt", but I'm not sure if you were an SNL fan in the 80s.
<Mithrandir> mdz: I'm unsure what change doko has actually done.
<mdz> Mithrandir: he seems to have changed the files in ooo-build/desktop
<mdz> Mithrandir: but in debian/rules, different files are used
<Mithrandir> mdz: hmm.  What is the expected result?  I'm unsure what's wrong based on the changelog.
<mdz> Mithrandir: the current menu entries in the .deb are "OpenOffice.org {Base,Calc,Impress,Writer,...}"
<mdz> Mithrandir: they need to be changed to the names listed in the changelog
<Mithrandir> mdz: ah, ok.
<Kamion> did doko edit a generated file by mistake or something?
<Mithrandir>         rm -rf ooo-build/desktop/*.desktop
<Mithrandir> comes from the clean target, so I suspect so.
<Kamion> oh, fucking hell
<Mithrandir> mdz: I'll have you a patch in a little while.  I think I know what's wrong and how to fix it.
<Kamion>         grep-dctrl -XFTemplate base-installer/kernel/linux/link_in_boot \
<Kamion>                 d-i/templates | \
<Kamion>                 >> debian/ubiquity/DEBIAN/templates
<Kamion> spot the mistake
<Mithrandir> | \ >> ?
<Kamion> bingo
<Mithrandir> a bit hard on the C&P when you wrote that code?
<mdz> Kamion: no, there are just two sets of desktop files and he edited the wrong ones, it looks like
<mdz> and didn't test his change
<Kamion> Mithrandir: probably just too tired
<Mithrandir> mdz: you can't just edit the .desktop files, you have to patch them.  I'll do so.
<fabbione> hey sabdfl 
<sabdfl> seb128: i still have that weird video squish effect if I fire up Totem, then open the video file
<sabdfl> what was that magic command that worked?
<sabdfl> hi fabbione, rock stars et al
<pitti> moin sabdfl, does the plague get better?
<fabbione> sabdfl: ehhe :)
<sabdfl> pitti: it doth improve mightily
<mdke> Keybuk: mmmmm
<mdke> a whole vat
<mdke> i can handle it
* Kinnison 's laptop is whinging about wanting to reboot, back in a bit
* Mithrandir urges bzip2 to go faster.
<Treenaks> Mithrandir: rewrite it in asm :)
<Mithrandir> Treenaks: I think it's quicker to wait for it to finish than do that
* simira has just finished the ooo course at work by making an impress presentation of Ubuntu Norway
<seb128> sabdfl: gst-launch-0.10 playbin uri=.... plays it fine, I've pinged upstream about it
<Mithrandir> mdz: I think I have a fix, now I just need to wringe it out of the build system properly.
<mdz> Mithrandir: thanks
<thom> sabdfl: have you seen jonathan schwarz's blog entry today/last night? you've been promoted to "guy behind ubuntu/debian/gnu/linux" :-)
<sabdfl> oh dear
<simira> not a bad promotion, I'd say
<simira> a friend passes here on his way to work, btw: http://ilmari.org/pics/shuttleworth_road.jpg
<sabdfl> the original reports from java-one came out quoting him as saying "SUN would really stand behind the fork that Ubuntu is doing"
<sabdfl> later corrected to "the work that Ubuntu is doing"
<thom> sabdfl: yeah, i saw mention of that. oops :/
<sabdfl> i suspect RMS might be a bit upset at the gnu bit
<sabdfl> thom: url for his blog?
<thom> http://blogs.sun.com/roller/page/jonathan?entry=busy_week1
<thom> (he's going to piss RHAT off with the same post, but i doubt he cares about that)
<iwj> Kamion: Yes, the 60.6 typo was only in the changelog.
<Keybuk> infinity: did OpenOffice build at last?
<mvo> mdz: the CJK people asked me for a sync of the ttf-arphic-uming font package, apparently they discovered that the "i" and "j" dots are missing with latest cairo (ubuntu bug #46297)
<mdz> mvo: sure, why not
<infinity> Keybuk: Yes, and now it's building again. :/
<Keybuk> openoffice.org 2.0.2-2ubuntu8 openoffice.org2-evolution(amd64/all) 2.0.1oob680m5-0ubuntu2 from 2.0.1oob680m5-0ubuntu2
<Keybuk> was that NBS?
<Keybuk> or just a fuckage?
<iwj> LaserJock: pong ?
<infinity> Keybuk: That's "we haven't uploaded OOo-amd64 yet"
<Keybuk> infinity: what's the amd64/all bit mean?
<Keybuk> infinity: it's an _all package isn't it/
<infinity> Keybuk: There's also other OOo fuckage lingering the archive, I'm not sure which that is.
<infinity> Keybuk: That's what the britney output would lead me to believe, yes.
<infinity> Keybuk: Anyhow, we know to go over this all with a fine-toothed comb, AFTER the new OOo and OOo-amd64 are in.  You'll note that testing_probs.html is still goofy too, and it's due to some archive buggery that needs to be sorted yesterday.
<Keybuk> fairy nuff
<fabbione> Keybuk: dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry <= 4' faile.
<fabbione>  ???
<Keybuk> fabbione: ANCIENT DPKG BUG
<Keybuk> it's like Debian bug #4 or something
<fabbione> Keybuk: what can trigger it?
<Keybuk> fabbione: loops in the depedency fields
<fabbione> or corrupted status file
<infinity> Okay, Mithrandir's OOo-i386 test-building right now.
<zakame> hi all
<fabbione> hi zakame 
<Keybuk> fabbione: iirc. it's when you have a virtual package that's depended on by a package that provides a virtual package depended on by the package providing the first virtual package
<Keybuk> there may be other triggers
<fabbione> Keybuk: it's a corrupted status file. i am telling you :))
<fabbione> it would be nice wth is corrupted tho
<Keybuk> fabbione: yes, if that status file produces the above effect
<fabbione> yeps
<fabbione> and the -old is now corrupted too
<Keybuk> can be a corrupted available file too
<Keybuk> or just a broken package
<fabbione> broken package is unlikely
<Keybuk> about once every few months, someone uploads a package that dpkg bails out on
<Keybuk> (with that exception)
<pitti> Mithrandir: hm, ppc/oem install user still has the wrong $PATH
<Keybuk> it's just a safety slip; it means dpkg has caught itself going round the same dependency graph a few times and is clearly in an infinite loop
<Mithrandir> pitti: I'm unable to reproduce it.  You remembered to run the oem-config-prepare before rebooting?
<pitti> Mithrandir: yes, sure (otherwise I wouldn't have gotten that user setup wizard)
<pitti> Mithrandir: oh, maybe that was confusing; the 'oem' user is fine, the new user created by that tool has just /bin and /usr/bin
<Mithrandir> pitti: uh.  
<Mithrandir> pitti: and /etc/environment at the first boot, when you go into the customisation thing is ok or not?
<pitti> Mithrandir: can't tell any more; right now I'm in the session of the wizard created user ('martin'), and /etc/environment does not have $PATH
<pitti> Mithrandir: does the wizard change /etc/environment?
<Mithrandir> pitti: I didn't think so, no.
<pitti> Mithrandir: 'sudo oem-config-prepare' worked, which is in /usr/sbin, so I'm pretty sure that $PATH for 'oem' user was fine
<pitti> Mithrandir: unless there was a /home/oem/.bashrc which set it
<Mithrandir> pitti: that's started from the init script which explicitly sets path, though.
<pitti> Mithrandir: I don't understand - I have to log in as 'oem' through gdm
<Mithrandir> hmm, true
<pitti> Mithrandir: is there anything I can debug in the current state of the system, or can I trash it?
<Mithrandir> pitti: just trash it.  If you can get me the state of etc/environment on first boot, that'd be useful
<Kamion> ok, that's odd, we just use user-setup to create the new user
<pitti> Mithrandir: shall I reattempt it right now (if you want to debug it now)? or does that have some time?
<Mithrandir> pitti: if you could do it right away, that'd be useful.
<Kamion> oh, it does fiddle with /etc/environment
<Kamion> see oem-config/locale
<Kamion> damn, that's broken
<Kamion>         grep -v '^\(LANG\|LANGUAGE\)=' /etc/environment | (
<Kamion>                 echo "LANG=\"$LOCALE\""
<Kamion>                 echo "LANGUAGE=\"$LANGLIST\""
<Kamion>         ) > /etc/environment.new
<Kamion> missing cat in there
<Mithrandir> Kamion: eww.
<Kamion> I'll fix it now
<Mithrandir> thanks.
<pitti> great!
<Mithrandir> where's that from?  User-setup?
<Kamion> localechooser
<Kamion> needs to set the new default system locale, so it's messy
<Mithrandir> yeah. :-/
<Kamion> I'll use sed -i instead
<Kamion>         sed -i "s/^LANG=.*/LANG=\"$LOCALE\"/" /etc/environment
<Kamion>         sed -i "s/^LANGUAGE=.*/LANGUAGE=\"$LANGLIST\"/" /etc/environment
<Kamion> does that look right?
<Kamion> actually I'll use commas rather than slashes
<Kamion>         sed -i "s,^LANG=.*,LANG=\"$LOCALE\"," /etc/environment
<Kamion>         sed -i "s,^LANGUAGE=.*,LANGUAGE=\"$LANGLIST\"," /etc/environment
<Mithrandir> looks correct to me
<pitti> Kamion: maybe sed -i 's...' to further simplify the embedded "
<Kamion> pitti: need variable substitution in there so it'd be messy with ''
<Mithrandir> pitti: nope, that won't work.
<pitti> Kamion: can we guarantee that there will be no spaces before the LANG?
<pitti> Kamion: right, ignore me; sorry
<Mithrandir> Kamion: $LOCALE and $LANGLIST can't ever contain ",", right?
<infinity> They certainly shouldn't.
<Kamion> pitti: yes, I don't think pam_env would understand leading spaces
<Kamion> Mithrandir: not that I can think of; $LANGLIST is :-separated
<Mithrandir> Kamion: also, no "," in /u/s/i18n/SUPPORTED, so I think it's safe.
* infinity runs off to find a snack.
<sfllaw> Wait a second...  jkakar doesn't work on distro, does he?
<Mithrandir> sfllaw: re what you want me to test; I don't have netboot set up here and it'd be kinda hard for me to do.
<infinity> No.
<sabdfl> heno: there's a new plan_m.ogg which rocks
<sabdfl> could you sync up with Jonathan on it?
<Riddell> mdz: can I upload this security fix for koffice? http://kubuntu.org/~jriddell/tmp/koffice.diff
<pitti> sfllaw: why did you revert my Testing/DapperUpgrades -> DapperUpgrades change on Testing/Current?
<Keybuk> mvo: subscribe, not assign
<mdz> Riddell: sure
<Riddell> jono, mdke: do we have the text from jjesse?
<Kamion> Mithrandir,pitti: right, fixed, thanks
<sfllaw> pitti: I thought I made a typo.  Because it said [DapperUpgrades] .
<Riddell> thanks mdz 
<Mithrandir> sfllaw: also, you might want to swap me into doing dvd tests since I have plenty of bandwidth.
<pitti> sfllaw: well, Testing/DU doesn't exist, and DU is apparently the right onw
<pitti> sfllaw: s/w$/e/
<heno> sabdfl: right
<jono> Riddell: just one sec, phone
<sfllaw> pitti: Ah.  I'll change it.  Thanks.
<pitti> sfllaw: I'd like to swap ubuntu-server testing with BenC's ppc/alternate CD testing, since I have very limited BW here
<ploum> hello
<ploum> is there a list of accepted Ubuntu SoC ?
<seb128> hi
<sfllaw> pitti: OK.
<pitti> sfllaw: I'll ask Ben, but woudl that be fine for you?
<Riddell> jono, mdke: ah, found it in e-mail, ch07_Ubuntu.doc
<seb128> ploum: not sure, looks like you are accepted to GLaunchpad though
<sfllaw> pitti: Of course.  I was just optimizing based on HW availability.
<ploum> looks likte yes
<sfllaw> And spreading out the work.
<pitti> sfllaw: it's ppc either way :)
<sfllaw> Mithrandir: OK.  I'll shuffle that around.
<Kamion> server guys: you know to rsync *-server-* rather than *-install-* now, right?
<sfllaw> pitti: When you file bugs, could you put them at the bottom of the page, thanks?
<pitti> sfllaw: yes, I did so for the OEM issue
<pitti> sfllaw: if I find more, I will do that
<sfllaw> pitti: Thanks.
<sfllaw> !!! I've changed Testing/Current to reflect requests !!!
<Keybuk> sfllaw: I don't have a disk to erase on powerpc, I'm afraid
<ogra> pitti, ping 
* pitti hugs ogra 
<ogra> pitti, ppc didnt like your language additions
<Mithrandir> sfllaw: what's the DapperUpgrades thingy?
<pitti> ogra: too big? or another bug?
<ogra> pitti, how exactly do i read http://people.ubuntu.com/~pitti/langpacks/langpacksize.txt 
<ogra> pitti, too big
<pitti> ogra: did you add ship-live yesterday?
<pitti> ogra: we had drastically strip down the ubuntu CDs again due to addition of ship-live yesterday
<ogra> pitti, am i rtight assuming the last column includes the language-support packages ? 
<pitti> ogra: ok, an example:
<pitti> am     G:     127490  K:      23882  G+K:     135106  GSum:   29646734  KSum:   39510732 G+KSum:   54728710
<ogra> yeah
<pitti> ogra: that means base+gnome = 127490, base+kde = 23882, base+gnome+kde = 135106
<Kamion> ogra: language-support is not included there
<pitti> ogra: all in bytes
<ogra> ok
<pitti> ogra: as Kamion says, only l-pack-*
<Kamion> you should never include language-support for anything other than -en, unless you have huge amounts of CD space to randomly burn
<pitti> ogra: the last three colums are the same gnome/kde/both, but cumulatively from the top
<ogra> (i'm trying to keep as much as i can while not dropping ship-live)
<pitti> ogra: the list is sorted by our prefered priority; English, then the top 11, then alphabetically
<dholbach> mdz: ok to upload gnome-power-manager with new icons? or better defer?
<Kamion> dropping build-essential/fakeroot/linux-headers from Edubuntu ship-live would be fairly reasonable, I think
<pitti> ogra: so, for edubuntu you should look at G+KSum until you find the row which matches the available CD space and add packs until this
<Kamion> (if you pulled in that change)
<mdz> dholbach: sure, why not
<Kamion> and even the network access stuff is probably not critical for Edubuntu, given the server focus
<dholbach> mdz: ok, uploading.
<ogra> Kamion, if i drop build-essential/fakeroot/linux-headers, what sense do the other parts of ship-live make ? 
<Kamion> ogra: plenty
<ogra> i assume a user wants to compile some modules, so he should have build essential and the linux headers package
<ogra> s
<Kamion> ogra: if there are people setting up Edubuntu servers behind strange network hardware (e.g. a school connected by some strange USB ADSL business) then they'll need that
<Kamion> ogra: the other pieces of ship-live do not, to my knowledge, require kernel modules other than those in the base install
<ogra> hmm, k but in that case they'll use the default CD anyway, i see
<Kamion> with the exception of avm-fritz-firmware which provides additional precompiled modules
<ogra> i just dont want to differ too much, that will confuse in support
<Kamion> the network access bits come to roughly 2.7MB IIRC
<ogra> ok
<Kamion> but it's up to you
<ogra> yep, i know ... i always have to make the evil decisions ...
<Kamion> and it's only really super-important for Ubuntu and Kubuntu because we're sending live CDs out in shipit
<Kamion> for Edubuntu it does not seem so critical
* ogra whishes for a worldwide stadarization on 800MB media
<jono> Riddell: sorry, on the phone with Sun, Jonathan is having trouble submitting
<jono> Riddell: how much time is there before Kubuntu fully freezes
<ogra> Kamion, i'll drop linux-headers and friends for now, will also make room for langs on i386 and amd64
<mvo_> mdz: I have a icon update for update-notifier pending as well, is it ok to upload today? or better defer?
<infinity> mvo_: We're redoing OOo builds AGAIN, so I suspect something as harmless as an icon update would be fine.
<infinity> mdz: ^^^
<mvo_> infinity: cool, I'll be on it right after lunch
<sfllaw> Mithrandir: That's using update-manager, which mvo (?) wrote.
<sfllaw> Gah!  Internet has gone down.
<sfllaw> Stealing wireless now.
<sfllaw> It's bad when pppd says "Remote message: No valid RADIUS server found.", right?
<ogra> Kamion, that was a pointless discussion :P i didnt merge the seeds yet :/
<Kamion> heh
<Kamion> well, you know in case you do ;)
* ogra should wake up before starting such things
<ogra> 7me goes back to langpack fiddling
<pitti> ogra: sorry if I messed that up, I wasn't aware of the ship-live addition when I updated the ubuntu and edubuntu seeds
<ogra> pitti, ship-live is empty in edubuntu 
<pitti> hm
<ogra> and dont feel sorry :)
<pitti> ogra: ok, so it was just a little too big then? miscalculation?
<ogra> (for some value of empty ... it still had the isdn stuff and ndiswrapper etc)
<ogra> pitti, you calculated on top of yesterdays isos i guess, the livefs wasnt up to date 
<pitti> ogra: weird then; I'm pretty sure that the calculation was correct against yesterday morning's image, but with so many changes in example-content and so on it was a moving target
<pitti> ogra: right
<Riddell> jono: I have the .doc file here, how hard can it be to save as HTML?
<ogra> and the livefs builds failed for different reasons (packages being build etc)
<jono> Riddell: well, I personally dumped it to plain text, stuck it in NVU and marked it up. Take a look at the files I submitted to dholbach to see how they work
<jono> Riddell: you could also try htmltidy
<dholbach> Riddell: I'll send them to you in a sec
<jono> Riddell: I would do it for you, but I am up against a schedule today
<Riddell> dholbach: I've got it
<dholbach> ah ok
<Riddell> jono: I'll do it, should be fine
<heno> Riddell: if you can send me the book images I can crunch the file size a bit
<ogra> Kamion, i have one user in #edubuntu who did an ubiquity install, his grub menu now shows "ubuntu kernel 2.6.15" and "ubuntu 6.06 LTS", he had breezy and XP on the machine (and was not running 2.6.15 on this breezy)
<dholbach> doko, infinity, Mithrandir: I took some of your tasks on Testing/Current
<infinity> dholbach: Thanks. :)
<Kamion> ogra: well, that would be correct given that that's what he just installed ...?
<ogra> Kamion, two entries ?
<ogra> i usually only have one for the new system 
<Kamion> ogra: oh, if the complaint is that breezy and XP aren't on the grub menu, perhaps he should check fdisk to make sure their partitions are in fact still there ... I hope he was using a current daily?
<ogra> nomed, the complaint is that he has two entries for the new system
<Riddell> heno: e-mail bounced to you
<Kamion> ogra: please get the user to file a coherent bug report, attaching /boot/grub/menu.lst
<Kamion> I don't want to deal at second hand if I can deal at first hand instead :)
<jono> Riddell: ok :)
<pitti> mvo_: btw, is the update-manager dist-upgrade tool launched when I insert a CD?
<ogra> Kamion, forwarded ... but apparently he's already doing a new install already ... :7
<mvo_> pitti: no, just the "do you want to add this cd" thingie
<pitti> mvo_: ok, so as long as I can use the CD as an apt source for the upgrade, that's fine
<mvo_> pitti: yes, if it is added, the packages from there will be used
* pitti does the upgrade test on ppc now
<Kamion> mdz: reproduced bug 43820; I believe it's a one-line syntax error fix in lilo-installer (remove a stray ";;"). OK to upload once I've confirmed?
<Ubugtu> Malone bug 43820 in debian-installer "Missing bootloader for XFS installs " [Normal,Confirmed]  http://launchpad.net/bugs/43820
* mvo_ hugs pitti
<Mithrandir> mvo_: the auto-upgrade thingy says "CD" even though I have a DVD. :-P
<Mithrandir> anyway, rebooting to live session and such now.
<mdz> Kamion: yep
<mvo_> Mithrandir: hal-integration will be done for edgy :P
<pitti> mvo_: similarly to the behaviour in hoary?
<mvo_> pitti: you mean with respect to doing cd-based upgrade? I would like to have a spec for this, yes
* mvo_ adds this to his "ThingsToDoInParis" list
<mdz> Kamion: what's the simplest way for someone doing CD testing to confirm that they've got the correct build?
<Kamion> mdz: check the .disk/info file on the CD
<mdz> Kamion: that's not very simple to write instructions for :-/
<mdz> it's not in the help screens or anything?
<Kamion> give me a minute
<Kamion> mdz: yes, the cdimage build id should be on the first help screen too
<mdz> perfect, thanks
<Kamion> and for powerpc it appears in the yaboot boot message
<mdz> updated Testing/Current
<mdz> mvo: what do we need to change for the final release so that breezy update-manager starts notifying users?
<mvo> mdz: edit the file http://changelogs.ubuntu.com/meta-release to include dapper (use http://changelogs.ubuntu.com/meta-release-development) 
<dholbach> sfllaw: still editing Testing/Current?
<sfllaw> Nope.
<sfllaw> I keep on forgetting that MoinMoin is a locking wiki.  :/
<mvo> mdz: if we want a different name (no dapper but 6.06) we need another upload to breezy-updates :/ but that wouldn't be too bad, I could fix translations + a proxy issue this way
<mdz> mvo: I've updated https://wiki.ubuntu.com/ReleaseChecklist , please check for accuracy and completeness
<mdz> mvo: eek
<mdz> mvo: yes, please do change it to "6.06 LTS"
<mvo> mdz: ok
<pitti> mvo: I opened the 'terminal' in update-manager while dist-upgrading to dapper; is the 'cannot open display:  at .../Debcfon/Frontend/Gnome.pm' warning something to worry about?
<Kinnison> pitti: Does it say Debcfon or Debconf ?
<pitti> mvo: (followed by "debconf: kann Frontend nicht initialisieren: Gnome (DISPLAY problem?), falling back to Dialog)
<pitti> Kinnison: bah, Debconf of course
<Kamion> woo, successful boot with lilo/xfs
<Kamion> I thought lilo didn't work with initramfs at the moment, but evidently it does
<dholbach> I have a machine with a usb disk only - it seems that installing when that disk is mounted (which is the default with the desktop CD), makes trouble (as it doesn't get automatically unmounted) - is that known already?
<infinity> Kamion: No, it doesn't work with update-initramfs.
<Kamion> ah
<infinity> Kamion: ie: We don't re-run LILO, cause duplicating the 4MB of Perl from the linux-image postinst was a bit much.
<infinity> Kamion: For edgy, I hope to split that out into a helper binary or something, so the logic lives in only one place.
<Kamion> oh, if people have to run lilo by hand, big deal
<Kamion> I can cope with that
<infinity> Meh.  rsyncs still going.  So much for my copious bandwidth.
* infinity is going to run to the grocery store to get "all night hacking snacks".
<mjg59> infinity: When did you last sleep?
<infinity> mjg59: Relatively recently, actually.
<Kinnison> Where relatively recently == "march"
* jdub pours fresh custard on mdke 
<Kamion> mdz: lilo-installer fix a little more complicated than expected because apparently we haven't tested it since whatever it was that caused /dev/[hs] d[a-z]  to appear in d-i. Anyway, fix tested and confirmed working now ...
<Mithrandir> sfllaw: there's no "current dvd" info on testing/current.
<mdz> Kamion: I'm happy to eyeball it
<Kamion> oops, I just tagged it in baz. oh well, I can untag if need be I suppose
<mdz> Mithrandir: he's sleeping; just add it
<Mithrandir> sleep?  what's that?
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/lilo-installer-fixes.diff; may not make a lot of sense without context though (lilo-installer is a foetid steaming mess)
<Kamion> ghastly device name parsing all over the place
<Robot101> mjg59: lilo and grub installers neuter themselves on i386 apples even when you boot under bootcamp :-/
<Robot101> mjg59: we had to install lilo manually, flagrant violation of the social contract. :)
<mjg59> Robot101: grub makes crap bios calls, lilo should work if beaten with sticks
<Kamion> sucks to be bootcamp
<Robot101> yeah lilo works, we got it working
<mjg59> And fglrx?
<Kamion> if somebody fancies telling me how to *tell* that I'm running under bootcamp, I'm happy to adjust the installers
<Robot101> worked out of the box
<Kamion> well, lilo-installer anyway
<mjg59> Kamion: dmi says you're on an apple and /sys/firmware/efi doesn't exist
<Mithrandir> Kamion: is the "resizing partition" dialog supposed to give useful feedback?  It's been stuck on 0% for ten minutes now.
<Kamion> Mithrandir: known bug I'm afraid
<Mithrandir> Kamion: 'k.  Appears to do something though, since the disk is chewing.
<mjg59> (I'm almost out of battery, so may vanish at any point)
<Robot101> we tweaked lilo-installer.isinstallable, but it probably failed to work probably because we didn't do something magic at partitioning phase
<mjg59> You did skip the partitioning, right?
<Robot101> yes
<mjg59> Cool
<mjg59> I've got an experimental patch for parted that ought to avoid the need to do that
<mjg59> Robot101: So how much beer do I win?
<Robot101> total's somewhere at 5 pints I think :)
<mjg59> Hurrah
<mjg59> Also, summer of crack
<dholbach> Mithrandir: you're still editing the wiki? if so, can you set "ubuntu, desktop cd, erase disk, i386" to PASS
<Kamion> mjg59: that's easy, then. fix checked in upstream
<dholbach> Mithrandir: if not, I'll just do it myself
<Kamion> but not for dapper now I feel
<mjg59> Kamion: Fix for?
<Robot101> mjg59: crack approved? :)
<Mithrandir> dholbach: just finished.
<mjg59> Robot101: Fully crack-compliant summer
<dholbach> Mithrandir: ok, do it myself
<Kamion> mjg59: lilo-installer.isinstallable to make it allow lilo-installer under boot camp
<jdub> Robot101: there's a nice telepathy one in there
<mjg59> Ah, ok
<Robot101> jdub: yes :)
<Kamion> mjg59: also elilo-installer got fixed, if you didn't see
<Kamion> it turned out that the bug bit ia64 as well and somebody helpfully supplied a fix
<mjg59> Hurrah battery at 0
<HiddenWolf> mjg59: cool SoC project! :)
<mdz> Kamion: I'm satisfied with lilo-installer-fixes.diff to the extent that I can understand it without context
<mdz> mvo: I added update-manager in -updates to https://wiki.ubuntu.com/CodeNamesToVersionNumbers
<mdz> mvo: please get that change in soonest, to increase the chances of users having upgraded to it before they get the notification of dapper
<HiddenWolf> mdz: will breezy-users get the notification on june 1st directly?
<mdz> HiddenWolf: the next time that their system checks for updates
<mvo> mdz: thanks, I work on it now (my network went down again, I had to call the internet compnay)
<HiddenWolf> mdz: wheew, That's going to bring a few servers to it's knees, along with all the people wanting the latest and greatest asap. :)
<imbrandon> ahh so lots of upgrades today
<mdz> HiddenWolf: no more so than usual, I expect
<HiddenWolf> mdz: you're going to promote the upgrade-option in front of users that might not follow the community closely, I'll bet you that'll cause extra upgrades. :)
<HiddenWolf> </end noise>
<zul> heylo
<Kamion> mdz: thanks - uploaded
<mdke> jdub: I'm still hungry
<Riddell> Kamion: I'm still getting "RuntimeError: Install failed with exit code 1" on todays kubuntu desktop CD
<dholbach> seb128: still editing Testing/Current?
<seb128> dholbach: I clicked like 4 seconds ago so yes
<dholbach> ok
<seb128> a min
<dholbach> sure
<seb128> dholbach: done
<dholbach> ok
<dholbach> hum, still says you are editing
<dholbach> ah now it'S happy
<dholbach> i'll test the dvd i386 live session now and then go out for something to eat
* Kinnison is currently testing the i386 desktop live and install(vape drive)
<janimo> dholbach: hi, do you know what package provides the human cursor theme? I cannot find it anymore and I think it was just working a while ago
<dholbach> ubuntu-artwork
<janimo> ah, so not a separate package.... thanks
<Riddell_> Kamion: I'm still getting "RuntimeError: Install failed with exit code 1" on todays kubuntu desktop CD
<jdub> seb128: http://www.theage.com.au/news/world/tintin-creators-anniversary/2006/05/24/1148150265203.html
<zul> ooo...tintin
<Kamion> Riddell: the real error will be in /var/log/installer/syslog
<Kamion> Riddell: is that with ubiquity 1.0.5?
<Riddell> Kamion: nope, still on 1.0.4
<Kamion> well then :)
<Kamion> can I see the syslog?
<Riddell> Kamion: it's the same as on the bug report I made last night
<Riddell> "The link /vmlinux is a damaged link"
<Riddell> I'll update to 1.0.5 and try again
<Kamion> Riddell: I closed that bug :-)
<Kamion> (with a fix in 1.0.5)
<Riddell> right, I must have misread I though it said 1.0.4
<Kamion> I'd tried to fix a similar bug in 1.0.4 but got it wrong. Should be really fixed this time.
<Kamion> s/a similar/the same/
<Kamion> mdz: bug 46065 - what do you think? alien's in ship
<Ubugtu> Malone bug 46065 in alien "Please sync Alien from Debian/Unstable" [Normal,Unconfirmed]  http://launchpad.net/bugs/46065
<mdz> Kamion: I'm indifferent
<Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352810
<Ubugtu> Debian bug 352810 in alien "Subject: unpacking RPM changes permissions of working directory" [Normal,Closed]  
<mdz> so long as it builds
<mdz> I don't think it should be in ship
<Kamion> it's a dep of lsb
<mdz> yes, it is
<Kamion> lsb-core even
<mdz> but for pretty silly reasons
<Kamion> we could kick all of lsb out of ship; but perhaps in edgy? :)
<mdz> I don't think we can claim to be able to usefull install LSB packages that way, just by having lsb installed
<Kamion> mm
<pitti> mvo: ping
<mdz> Kamion: yes, I'm saying I don't think it's important for it to be there in the long term, not that we should rip it out right this second ;-)
<Kamion> (we don't even have all of lsb there any more; lsb-desktop pulled in qt4)
<mdz> mdz != sabdfl
<Kamion> haha
<jdub> Kamion: qt4? wow, it's not even properly LSB yet (let alone sensibly optional)
<Kamion> sorry, qt3
<jdub> ahr
<mvo> pitti: hello
<pitti> mvo: u-m finished :)
<pitti> mvo: however, as last thing it gave me a dialog box 'these packages are not supported any more...'
<pitti> mvo: and said that these were going to be removed in the next step
<pitti> mvo: however, there was no 'next step'
<mvo> pitti: wasn't there something like "will be removed if you don't have universe"?
<pitti> mvo: it might have mentioned universe, yes
<pitti> mvo: what will remove it?
<pitti> i. e. what is this 'next step'?
<mvo> pitti: finding obsolete packages and removing them - this usually works
<pitti> mvo: when is that done? it wasn't done in that u-m session
<pitti> and I don't have universe
<mvo> oh 
<pitti> mvo: btw, do you want bug reports for the issues we discussed at the phone? or are you fine without?
<seb128> pitti: when is next language pack update due? we still have no translation for the panel help submenu :/
<mvo> pitti: can you send me the log please? and a bugreport would b nice
<pitti> seb128: not yet decided; whenever we have a reasonable amount of translations, I guess
<pitti> seb128: daily packs are generated at least, for people to test
<ivoks> um... there's one bug i todays dailybuild
<seb128> pitti: your next daily build should have them though?
<seb128> pitti: ok, fair enough
<ivoks> i think it's solved now, but would like to check, anyway...
<pitti> seb128: well, that depends on the translators :)
<ivoks> infinity: here?
<seb128> pitti: I did the french translation just after the package got published monday
<infinity> ivoks: Doing installation tests, but yeah.  I'm around.
<infinity> ivoks: 'Sup?
<pitti> seb128: ok, can you please check today's langpacks then?
<ivoks> infinity: i noticed one ugly bug today in today's daily build
<ivoks> infinity: grub not being installed in mbr
<ivoks> infinity: i saw new version has something about that in changelog
<seb128> pitti: I've just tried a daily desktop CD install, I'll try with your daily build now
<infinity> ivoks: Which CD, and how did you install?
<ivoks> infinity: -daily
<ivoks> 20060524
<pitti> mvo: which log?
<mvo> pitti: /var/log/dist-upgrade*.log
<pitti> seb128: today's packs are not yet finished
<ivoks> infinity: normal install from -desktop
<ivoks> infinity: i needed to chroot and do update-grub
<pitti> mvo: you want a bug about not removing obsolete packages?
<infinity> ivoks: So, a ubiquity install?
<ivoks> infinity: yes
<infinity> ivoks: You want Kamion, then. :)
<infinity> Kamion: <poke>
<pitti> mvo: I'm afraid there's little more I can tell you about this initial dialog issue
<ivoks> oh :)
<ivoks> infinity: i allways mix you two :)
<infinity> I do too.
<ivoks> :)
* ogra twiddles thumbs ... waiting for edubuntu-meta to finish ...
<Kamion> ivoks: /var/log/installer/syslog
<ivoks> Kamion: i can't get it now :(
<Riddell> Kamion: 1.0.5 installs without problems
<Kamion> ivoks: how come?
<Kamion> Riddell: great, thanks
<ivoks> Kamion: but i will as soon as I get my hands on that machine (maybe later this evening)
<ivoks> Kamion: long story...
<mvo> pitti: a bugreport about the whole experience is ok too, I'll sort it out then 
<Kamion> ivoks: OK, I'll be unable to fix most problems then though
<pitti> mvo: alright
<Kamion> ivoks: the changelog in today's upload is not relevant to you
<ivoks> Kamion: ok
<ivoks> Kamion: sorry, 'm not much of a help :/
<Kamion> it should have popped up an install crash dialog if it didn't get as far as installing grub
<ivoks> nothing poped up
<Kamion> or did it display some other kind of error message?
<ivoks> no, nothing
<Kamion> that's very odd
<ivoks> Kamion: um...
<mvo> pitti: thanks
<ivoks> Kamion: where does grub get installed anyway?
<Kamion> ivoks: MBR of first hard disk
<ivoks> Kamion: ok, that explains it...
<ivoks> Kamion: sorry to bother you :)
<Kamion> well, sometimes, it depends
* seb128 slaps jdub for that tintin article :p
<seb128> s#article#url
<Kamion> actually it might have installed it to the MBR of the second hard disk, if you have two and are installing on the second
<jdub> seb128: :-)
<Kamion> which would mean you'd have to teach your BIOS to boot it
<ivoks> Kamion: i had two first disks
<ivoks> Kamion: sda and hda
<ivoks> Kamion: it installed it on hda
<Kamion> ah, that can cause confusion, yes
<ivoks> Kamion: and my system was on sda
<Kamion> the alternate install CD has similar badness sometimes
<ivoks> Kamion: ok, something to think about for edgy? :)
<Kamion> it's on the list, yes ...
<ivoks> ok
<pitti> mvo: in your dist-upgrade tests, can you please check if language-support-en (and dependencies) are still installed after it? I don'thave OO.o help aany more, and l-s-en isn't isntalled
<pitti> mvo: I'll file a bug about that as well
<ogra> infinity, can you trigger a livefs build for edubuntu please (hoping there isnt *again* a package breaking it today)
<infinity> ogra: Sure.
<ogra> thanks 
<infinity> Can someone explain to me how dpkg can think I have a package installed twice?
* ogra guesses iwj should be able :)
<infinity> Oh, nevermind.  My bad.  Broken regex on my part.
<infinity> Phew.
<ogra> :)
* infinity goes to put a checkmark next to LAMP install.
<infinity> ogra: livefses building.
<ogra> thanks :)
<ogra> i hope totem wont break it 
<ogra> yesterdays was killed off by a dia build 
<ogra> doko !!
<ogra> alive !!!
<pitti> mvo: three bugs filed and added to Testing/Current
<pitti> hi doko 
<doko> hi. not very alive
<ogra> montezumas revenge ? 
<mvo> pitti: thanks
<ogra> doko, or only jetlagged ? 
<doko> no, some "souvenirs" I didn't want to bring back
<ogra> ouch
<pitti> doko: the same plague as sabdfl has? :)
<Riddell> dholbach: kubuntu book chapter ready, where do I put it in the package?
<Riddell> heno: did you get anywhere with reducing the image sizes?
<Riddell> mdke, jono: FYI ^^
<heno> yep, can I email you the files again?
<jono> oh cool :)
<Riddell> heno: sure
<heno> Riddell: done. From 2.7MB to 1MB
<Riddell> heno, dholbach: I take it the Screenshot.png files are the space taking placeholder ones that I can get rid of?
<Riddell> heno: nifty, how did you manage that?
<heno> Riddell: yes you can remove those
<heno> Riddell: used Gimp to index them to 256 colours
<heno> some I had to leave alone, or they would look crap
<Riddell> so that's a space saving of about 3MB, nice
<heno> but most are fine
<heno> in total on the whole book, yes
<mdke> Riddell, heno: nice one
<mdz> Mithrandir: any joy with oo.o?
<fabbione> who remember the ppc/OF sintax to boot from the net on the fly??? something like: boot net:<ip_of_the_server>,<file> ?
<Mithrandir> mdz: I handed it off to infinity a couple of hours ago so he can build it on a buildd.  Unsure what the progress is
<Mithrandir> infinity: ^^?
<iwj> What's the official minimum disk space for Dapper ?
<Keybuk> 2GB
<iwj> Excellent.
<ogra> infinity, my livefs logs look a bit weird (like they were copied while still being written)
<ogra> infinity, http://people.ubuntu.com/~cjwatson/livefs-build-logs/dapper/edubuntu/20060524.1/
<Kamion> that can happen, yes.
<lemsx1> is there any new kernel coming? -23 just gave me a ugly crash in an IBM R51 laptop. the system boots fine but one of the modules doesn't load
<lemsx1> i'll copy dmesg to a remote box in a second
* Kinnison goes to lunch before trying the next type of install test
<ogra> ok, so i'll wait until someone notifies me they are done before starting an iso
<ogra> lemsx1, kernel freeze was on 18th
<lemsx1> ogra: ouch. well, i don't really understand this error. let me post for you guys to see it
<lemsx1> ogra: no kernel panic though
<ogra> and if a module doesnt get loded its more likely udev's fault
<mjg59> lemsx1: "One of the modules doesn't load" isn't a helpful report
<Keybuk> ogra: no, it's more likely the kernel's fault
<Keybuk> or whatever package provides that module
<mjg59> lemsx1: Best thing to do is file a bug against linux-source-2.6.15 with the failure
<ogra> Keybuk, ok
<lemsx1> mjg59: thanks. almost there
<jdub> dear mjg59, DMA works correctly on my machine, thank you, love jdub
<lemsx1> mjg59: i'm getting the system to boot normally now. i'll do a proper report
<Keybuk> jdub: is it SATA? :)
<jdub> haha, no
<carlos> pitti: I need to leave now, but I guess the language packs are completely ready, right?
<carlos> pitti: did you see the report?
<pitti> carlos: building is still in progress, but report should be there, yes
<OdyX> fabbione or BenC: on kubuntu-devel, we went to ask ourselves why SysRQ is enabled per default. Isn't it a security issue ?
<carlos> pitti: no missing domains from Rosetta and I think all domains you told me to remove are now removed
<pitti> carlos: RRRRRRROCK
<Riddell> carlos: is konversation being exported?
<carlos> Riddell: it should be there now, yes
<mjg59> OdyX: If someone has physical access to the console, then in general they can own the system
<fabbione> OdyX: no
<Riddell> cool
<BenC> OdyX: the only reason I know of is "it's always been on"
<pitti> carlos: kdgantt-disabled looks a bit fishy, but the hell with it...
<carlos> oh, am I exporting it??
<carlos> pitti: it should not be there
<OdyX> OK. Thanks
<BenC> and SysRQ is not more of a security issue than the power button
<carlos> there are two kdgantt and I choose to disable the less translated
<fabbione> OdyX: nothing stops you to remove the power from the machine and starts it in init 1 once you are so close to the keyboard
<OdyX> fabbione: what about "serial distant keyboards" ? (Or I miss something ? )
<mjg59> I don't think sysrq is anything other than a (very) local DoS
<mjg59> OdyX: If they've got access to a remote serial console, then (again) they can probably 0wn you
<fabbione> OdyX: the what????
<mjg59> OdyX: What's the security risk?
<OdyX> fabbione: nothing then
<mjg59> OdyX: The worst sysrq can do is reboot the machine or kill the tasks on the current tty
<OdyX> mjg59: Sure
<mjg59> OdyX: So, why is it potentially a security risk?
<OdyX> Thanks for convincing answers
<carlos> pitti: it should not be with next export
<mjg59> OdyX: What was the original concern?
<OdyX> mjg59: more wondering than real issue
<Keybuk> is there any particular reason the edubuntu CDs are still called "install" and "live" ?
<OdyX> mjg59: some think that it's security issue, some don't
<ogra> Keybuk, yep
<Kamion> Keybuk: ogra asked for them to be
<mjg59> OdyX: Why do they think it's a security issue?
<mjg59> OdyX: It's possible that we're wrong - it would be nice to know what the actual concern is
<Kamion> Keybuk: desktop isn't the primary installation method for Edubuntu, so "alternate" doesn't make sense there
<ogra> Keybuk, we'll only ship i386 install and thats our default CD 
<OdyX> mjg59: [16:24:18]  <seaLne> unless its physically secured and the software is secured
<mjg59> OdyX: I'm afraid I don't understand?
<OdyX> mjg59: well. Idea would be to have a server without access to power, just a keyboard and a monitor. Server is in secure place, but cables go out for keyboard & screen
<OdyX> I dunno, just imagine.
<OdyX> :D
<mjg59> OdyX: You can disable sysrq at boot time
<OdyX> mjg59: ?
<OdyX> mjg59: on boot line ?
<jordi> MDZ
<mjg59> OdyX: Put kernel/sysrq=0 in /etc/sysctl.conf
<OdyX> mjg59: OK. Thanks
<fabbione> OdyX: if a server is on the network is not secure. if a server has power is not secure. if there are cables coming out is not secure. if the disks are replaced the data are not secured. if you don't slam it in a 2x2x2mt cube of concrete is not secure (a nuclear blast might cause DoS)... if
<OdyX> fabbione: OK OK OK. I agree.
<OdyX> :D
<nomed> janimo, around ?
<janimo> nomed: yes
<nomed> i'm going to test now a patch i would sent for libxfcegui4
<nomed> do u think it's a good idea ?
<nomed> i mean ... do u know what it means ? :P
<nomed> there are many xfce pkges that depends on it ...
<janimo> nomed, no problem, since it does not change APIs
<janimo> it just fixes icon names right?
<nomed> yes
<janimo> anyway please post it to bugs.xfce.org
<nomed> yep ..
<janimo> so they take it and we make sure they agree with the namings
<nomed> i'd like if you could take a look before i post it ..
<nomed> to get something really good i'll need to patch xfdesktop4 too
<janimo> nomed, ok send it to me I'll have a look tonight
<janimo> do you need to send a patch to tango for the mixer icon?
<nomed> i test it and then i'll send it to by mail 
<janimo> or just xfce?
<nomed> xfce
<nomed> to tango for some other stuff
<nomed> ready that too ..
<mdz> jordi: you are dead to me
<mdz> especially right now
<nomed> upgrading the system .. and then i'll test it too
<Kinnison> iwj: Shall I take a couple of the kubuntu desktop cd tests from you?
<jordi> mdz: uh!
<jordi> Ok, I'll keep the adsl secrets to myself.
<nomed> btw: xfce4-dev-tools should have better dependencies ...
<iwj> Kinnison: Up to you.  Unfortunately my rsync seems to be taking longer than I'd hoped.
<iwj> Kinnison: if you want to take some, take the `alternate CD' ones.
<Kinnison> okay, I'll do alternate
* Kinnison doesn't have a spare vmware with windows in it, so I can't do the auto-resize test
<iwj> I had to dig a disk out of the junkpile.
<iwj> This download is _too slow_.
<Keybuk> *giggles*
<Keybuk> "A new medium has been detected.  What do you want to do?"
<Keybuk> why is "Ask her to tell me my fortune" in the list?
<Treenaks> Keybuk: There should be buttons with text-entry widgets in them for stuff like that
<Keybuk> holy cow
<Keybuk> how did KDE escape launchpad integration
<lemsx1> mjg59: perhaps this oops is related to ipw2200 ... bug 46372
<Ubugtu> Malone bug 46372 in linux-source-2.6.15 "module loading crashing" [Normal,Unconfirmed]  http://launchpad.net/bugs/46372
<danimo> BenC: ping?
<BenC> danimo: pong
<Riddell> Keybuk: lack of time
<danimo> BenC: still having issues with recording with intel hda chipset. https://launchpad.net/distros/ubuntu/+ticket/800 isn't quite it, but arecord won't record anything. any idea how to hunt that one down?
<Ubugtu> Malone bug 800 in malone "Security-related bugs should not have to always be private" [Normal,Rejected]  
<Gloubiboulga> janimo: hi, just finished an install with the install iso
<danimo> huh? wrong bug
<BenC> danimo: likely talk to crimsun, he is the one who handles most of the sound stuff
<danimo> ok
<BenC> he may even know about it already
<danimo> crimsun: so hi there, any idea?
<mjg59> lemsx1: No, it's nothing to do with ipw2200
<mjg59> That's the infra-red system exploding
<Keybuk> Riddell: how do I uncomment universe in adept?
<Riddell> Keybuk: right click
<Keybuk> Riddell: bzzzt
<Keybuk> PowerBook
<Keybuk> Riddell: how do I uncomment universe in adept on a PowerBook :p
<Kinnison> right click using the bizarre chording?
<Keybuk> I've tried every bucky bit I can think of, and can't get a right-click-menu
<danimo> BenC: away since 9 hours, bad luck :)
<Kinnison> it's somewhere in the top right isn't it?
<Keybuk> Kinnison: that's just F11, F12, etc.
<Keybuk> F12 is Eject
<Keybuk> which seems a bad thing to push on a Live CD :)
<mdz> Riddell: are you making progress on your CD tests?
<Riddell> mdz: I am, but looking at Testing/Current I'm down for DVD testing, should I be doing that instead?
<rpedro> hello
<infinity> ogra: Yeah, looks like the log mirror did happen when the logs were still in progress.  The images built fine, though (and the logd on the buildds are fine)
<infinity> ogra: s/logd/logs/
<ogra> oh, already done :)
<rpedro> is it a known bug that opening and closing nested 'drawers' wll hang the gnome-panel?
<ogra> i didnt have the terminal focused, thanks !
<rpedro> can't seem to find anything on launchpad.net
<lmanul> sfllaw: Hi ! Do you know when the next Hug day is planned (I want to mention it in the next "Ubuntu Desktop News") ?
<ogra> WOAH, i even have space for more languages on the liveCDs
* ogra ponders which to add
<mdz> Riddell: Kubuntu is higher priority
<Kinnison> ogra: You have room? On an edubuntu cd?
<mdz> Riddell: I don't see many results on https://wiki.ubuntu.com/Testing/CurrentKubuntu yet though
<pitti> ogra: please stick to the list mentioned in langpacksize.txt
<ogra> Kinnison, only live
<mdz> Riddell: oh, I see, Simon created a separate table down below
<mdz> Riddell: so we should get rid of CurrentKubuntu
<ogra> pitti, my audience is a pretty different one, i'd like to use the langs the users use
<Kinnison> ogra: aah
<pitti> ogra: hm, true; well, do as you wish
<mdz> Riddell: you should be recording your test results in the table, for whichever cases you've tested
<ogra> pitti, but indeed i'll use your list top down 
<infinity> dholbach: <poke>
<ogra> s/top down/top to bottom/
<Riddell> mdz: doing
<dholbach> infinity: pong
<dholbach> infinity: thanks
<infinity> dholbach: I see you and I interspersed for desktop CD stuff on amd64, which means I get to burn two CDs instead of 1... Want to trade all of one for all of the other? :)
<hunt0r> hi all I try to install ubuntu dapper drake for a while now but it hangs on the boot process with this message everytime: cs: IO port probe 0x100-0x3af
<dholbach> infinity: however you like it
<dholbach> infinity: which one do you like?
<mjg59> hunt0r: The boot process of the installed system or the boot process of the installer?
<hunt0r> I want to install ubuntu on an laptop but it hangs up wehen it tries to load the pcmcia drivers on any linux distro but i don't know to turn off pcmcia
<infinity> dholbach: Well, I've been using d-i for the last few hours with server CD testing, so how about I switch to do some desktop stuff?
<hunt0r> mjg59: on the boot process
<infinity> dholbach: And you can take amd64/alternate stuff.
<dholbach> infinity: fine
<sfllaw> lmanul: Hug Day has sort of been dropped.  dholbach and I were too busy to "organize" anything this week.  And by next week, it will be sort of late.  :)
<pygi> dholbach, congrats on mentoring :)
<hunt0r> mjg59: on the boot prcess of the installer sry
* sfllaw hugs dholbach.
* dholbach hugs sfllaw back :)
<mjg59> hunt0r: Ok, thanks
<dholbach> pygi: i didn't have a chance yet to look at the result.
<infinity> dholbach: (I also have a bug that I wanted to see if it got fixed on Zofia's machine, so this'll work well)
<mjg59> Kamion: ^ - any ideas?
<pygi> dholbach, doesn't matter :) You are that "Safety boat" :)
<dholbach> cool
<hunt0r> mjg59: do you know what I could do?
<mjg59> Does pcmciautils have the same io-port exclusions as pcmcia-cs did?
<mjg59> hunt0r: Right now, probably nothing I'm afraid
<Keybuk> mjg59: should have
<Kamion> Keybuk: we set F11 to middle-click and F12 to right-click
<hunt0r> mjg59: is there no whay to tell linux so it does not try to probe these IO ports with a boot paramter?
<Kamion> mjg59: we have all your exclusions; upstream took them
<mjg59> hunt0r: Not that I know of right now
<Keybuk> Kamion: I argue the F12 is a bug, because that's the Eject key on a PowerBook
<mjg59> Kamion: Ok
<hunt0r> mjg59: ok thy anyway :(
<hunt0r> *thx
<Kamion> Keybuk: there was no other choice that was any better; we went through pretty much every available option
<Kamion> Keybuk: and not on every powerbook
<Kamion> hunt0r: you could try adding the 'hw-detect/start_pcmcia=false' boot argument to the installer
<Keybuk> Kamion: why not use the same that Mac OS X does?
<Kamion> hunt0r: though it depends exactly where it's hanging
<Keybuk> Apple-Click or whatever it is
<nomed> janimo, have u seen bug #46375 ?
<Ubugtu> Malone bug 46375 in xfce4-session "Firefox doesn't autostart in saved session" [Normal,Unconfirmed]  http://launchpad.net/bugs/46375
<mjg59> Keybuk: Collides with things that use meta-left-click
<Kamion> Keybuk: IIRC the kernel doesn't give us that option
<nomed> it does make sense ..
<Kamion> Keybuk: you can change it in /etc/sysctl.conf if you don't like it
<Keybuk> mjg59: isn't Meta Alt?
<Kamion> Keybuk: sometimes
<Kamion> depends on your keymap
<mjg59> Keybuk: If it's not meta, it's alt
<Keybuk> mjg59: wouldn't Alt be Alt? :)
<Keybuk> (nb: isn't X fun?)
<dholbach> Kamion: thanks
<Kamion> Keybuk: again, depends on your keymap
<mjg59> nomed: I don't believe firefox has proper session support
<hunt0r> Kamion: tried that alrady well it hangs directly after "Uncompressing Linux.... Ok, booting the kernel. If I leave the quiet option in the boot loader
<mjg59> Keybuk: On pc102, alt is meta because more unix applications use meta-foo than alt-foo (IIRC)
<Mithrandir> mjg59: it has some if you install sessionsaver, though it's still not very good.
<Keybuk> I must admit that I'm buying this "Apples are the most user friendly computers in the world"
<mjg59> I'm not
<mjg59> MacOS made me start throwing things last night
<Keybuk> all of the menus in MacOS X use symbols in the shortcuts that don't appear on any key on the keyboard
<jsgotangco> lol
<Keybuk> then there's this "hold down C and turn widdershins within 2 seconds of the bong" type crap
<Mithrandir> : tfheen@xoog ../z/usr/share/applications > grep ^Name ooo-calc.desktop
<Mithrandir> Name=OpenOffice.org Spreadsheet
<mjg59> Last night I discovered that a (non-Apple) terminal app asks me if I'm sure I want to close the terminal
<Mithrandir> mdz: ^^
<Mithrandir> mjg59: pterm does it, iirc.
<OculusAquilae> pitti: ping
<mjg59> After I've clicked "Restart" in the system menu, then confirmed that by clicking "restart" in the popup
<pitti> OculusAquilae: here, but 100% busy
<Mithrandir> mdz: in other words, my patch worked.
<mjg59> If I didn't want to close the terminal, why would I have asked to restart the computer *twice*?
<mdz> Mithrandir: excellent, thanks
<mdz> Mithrandir: is an uploadable build in progress?
<OculusAquilae> pitti: ok, I'll ask you later
<seb128> Mithrandir: patch for what?
<infinity> mdz: Is that a go-ahead for me tp upload Mithrandir's signed source?
<Mithrandir> seb128: .desktop files in ooo
<seb128> Mithrandir: is there a place where we can translate them?
<infinity> mdz: And the i386 binaries will follow within ~30 mins.
<Mithrandir> mdz: infinity has the signed source and now matching binaries.
<Mithrandir> seb128: no idea.
<lmanul> sfllaw: All right, no Hug day then (sob) :-p
<pitti> Kamion: hm, I created a single large vfat partition on my iBook, and I still don't get autoresize offered
<Mithrandir> seb128: if you can get me patches, I can integrate them.
<mdz> infinity: yes
<mdz> Mithrandir: those binaries were built in a clean chroot?
<Riddell> dholbach: are you uploading example-content?
<seb128> Mithrandir: will do that now, do you have the english strings somewhere? Or are they the currently used ones?
<infinity> mdz: They were build on terranova.
<mdz> Riddell: he already did
<infinity> mdz: Clean LP-buildd chroot.
<mdz> infinity: excellent
<Riddell> right
* infinity uploads the source now.
<dholbach> Riddell: just built it locally
<dholbach> one sec and i'll upload
<Keybuk> holy crap, why does this thing have 10 partitions on it?
<mdz> BenC: how are your CD tests going?
<dholbach> Riddell: uploading
<Keybuk> Kamion: ok, I'm stuck in the partitioner
<Keybuk> I've resized the existing /dev/hda9 hfs+ partition
<Keybuk> but I can't seem to use the free space, what do I need to click?
<Kamion> pitti,Keybuk: can I get back to you both after I've finished with this apt-get.org crap please?
<Keybuk> ah, s'ok, apparently I needed to delete the odd hda1 thru hda8
<pitti> Kamion: yes, I'll play with it on my own; cfdisk and fdisk tell different things, I'll sort that out first
<Keybuk> oh, wow, I crashed the installer
<Riddell> Keybuk: which?
<Keybuk> Riddell: yours
<Riddell> Keybuk: 1.0.4? at the end of a ppc install?
<Keybuk> no, during partitioning
<Riddell> hmm
<Riddell> Keybuk: anything I can recreate?
<Keybuk> Riddell: I don't think I did anything unusual, deleted a couple of partitions, clicked "Create" and the entire partman bit vanished
<Keybuk> bug 46387
<Ubugtu> Malone bug 46387 in ubiquity "partman crashed" [Normal,Unconfirmed]  http://launchpad.net/bugs/46387
<Riddell> Keybuk: partman or qtparted?
<Keybuk> whatever ubiquity on today's kubuntu live cd uses
<Keybuk> it said something about partman in the crash dialog
<BenC> mdz: Downloading still
<Keybuk> it also seems to say qtparted in the traceback
<Riddell> yeah, looks like it's trying to talk to a qtparted that's not there
<Keybuk> right
<Keybuk> it vanished
<Keybuk> then I clicked "Go Back" hopefully
<Riddell> qtparted has issues with ppc, although I've not seen it crash
<Keybuk> cfdisk appears to have issues too
<Keybuk> it just seems 10GB of free space
<Mithrandir> seb128: I don't have the .diff.gz any more, ask infinity for it.
<Mithrandir> seb128: sorry.
<seb128> Mithrandir: np
<seb128> infinity: around?
<Keybuk> ya know, I'm going to back away from testing anything involving partitioning here I think <g>
<mdz> BenC: are you not using rsync?
<Keybuk> I don't really want a "honey, you'll never guess what happened to your PowerBook" moment ;)
<Kinnison> Keybuk: you're messing with D's powerbook?
<infinity> seb128: Yeah..
<Keybuk> Kinnison: well, it's _mine_ in that I bought it ... but he's been using it
* Kinnison grins
<Keybuk> I have a spare laptop hard drive around somewhere, I think I'll use that
<infinity> seb128: chinstrap:~adconrad/
<Keybuk> I'd quite like some sex next month
<seb128> infinity: you are going to do an openoffice upload? any way to push some .desktop translations to it?
* Kinnison grins keybuk again
<infinity> seb128: I uploaded 20 minutes ago...
<iwj> This test machine's slow boot process is very annoying.  I have a 30s window or so to catch the boot menu after several minutes of faff.
<bddebian> Howdy
* Keybuk wonders whether the working drive is in the Dell, or the ruins of the Tosh
<infinity> Kamion: Is there any plan to either A) compile "start.exe" with an Ubuntu logo, or B) include an ubuntu.ico and point autorun.inf to that?
<infinity> Kamion: So that the CD has an Ubuntu icon when mounted in Windows...
<BenC> mdz: no, I haven't kept things synced because of my b/w limits
<BenC> so much per hour and such, and keeping all 6 of these machines at latest dapper already consumes a lot of that without some sort of syncronized updateing process
<neuralis> BenC: we might get one through SoC.
<infinity> seb128: If we're going to try to squeeze more translations in, they might have to come after RC... I'm kinda hoping the i386 build I'm doing right now will be the last for RC.
<mdz> infinity: that'd be a heno question
<mdz> infinity: we're doing langpack uploads post-RC, I suppose we can do oo.o too...
<infinity> mdz: Right, I'll poke heno about it.  The current icon looks pretty underwhelming, and may be most Win32 users' very first introduction to us..
<infinity> Oh, he's not idle.  Cool.
<infinity> heno: *poke, poke, poke*
<mdz> heno: has the WinFOSS been updated for "Ubuntu 6.06 LTS"?
<heno> infinity: good point. an Ubuntu logo on start.exe would be better
<heno> mdz: yes, last upload was a few days ago
<infinity> heno: If recompiling start.exe with a new logo is too much of a pain, shipping the icon beside it and telling autorun.inf to use that is just as simple.  Your pick.
<heno> it'sall quite fresh
<infinity> heno: The advantage of my way is that we can use the same start.exe on all the CDs, but include a different icon for each derivative, if we want to get fancy.
<heno> infinity: no, I can fix start.exe
<heno> infinity: that's true
<mdz> heno: great, thanks
<heno> I guess we don't have a win32 icon file of the logo
<infinity> heno: And for derivatives that don't ship start.exe, they should probably still have an autorun.ico for prettiness anyway.
<heno> but I can make one
<heno> infinity: yep
<mdz> heno: could you add the relevant bits to https://wiki.ubuntu.com/CodeNamesToVersionNumbers so that it's on the checklist for next time?
<giftnudel> heno: 24x24 bitmap named .ico?
<infinity> 32x32
<giftnudel> even better ;)
<infinity> Top left pixel is "transparent".
<heno> giftnudel: yeah, bigger than 24
<infinity> (whatever colour you place there)
<Keybuk> doesn't it also have to be in .ICO format?
<ogra> likely
<infinity> Keybuk: .ico is a .bmp, with certain contraints.  Most of which are meaningless to anyone not running Win3.1, IIRC.
<infinity> Anyhow, I can dig up a real .ico editor if someone sends me some suitable .bmps.
<infinity> And I'll make sure they conform.
<bddebian> Keybuk: Have a second for a quick question or too busy?
<Keybuk> bddebian: sure
<infinity> heno: ^^^
<Mithrandir> infinity: or just use icoutils?
<Mithrandir> which, hey, happens to be maintained by Colin
<bddebian> Keybuk: Should binary libilluminate6 still be in the archive?  illuminator source now provides libilluminate7?
<Keybuk> bddebian: no
<nomed> janimo, ping me when available 
<bddebian> Keybuk: Can you remove it?
<Keybuk> I think someone just did under me
<heno> mdz: sorry I don't follow about the code names page. are you talking about the icon on the winfoss CD or example content?
<Keybuk> hmm, no, I can't see it in the archive
<bddebian> Keybuk: OK, thx.  Sorry to bother you.
<Keybuk> bddebian: apt-cache policy libilluminate6
<mdz> heno: I'm talking about any references to the version of Ubuntu in the WinFOSS
<infinity> Woo, I broke ubiquity!  Do I get a prize?
<bddebian> Keybuk: Sorry, typo...
<ogra> infinity, a tear from Kamion probably
<heno> mdz: OH, I see. pretty sure is says '6.06' everywhere but not 'LTS', I'll trawl through it
<bddebian> bdefreese@bdubuntu1:~$ apt-cache policy libluminate6
<bddebian> libluminate6:
<bddebian>   Installed: (none)
<bddebian>   Candidate: 0.9.0-1
<bddebian>   Version table:
<bddebian>      0.9.0-1 0
<bddebian>         500 http://archive.ubuntu.com dapper/universe Packages
<Keybuk> bddebian: 
<Keybuk> -- dapper/universe hppa deps on libluminate6:
<Keybuk> illuminator-demo
<Keybuk> libluminate-dev
<mdz> heno: thanks, and as you do, add them to the wiki so we have a list for next time
<heno> ok, got it
<bddebian> Keybuk: But the source for those provides libluminate7 now?
<Keybuk> bddebian: then I'd start by investigating why those haven't built on hppa yet
<infinity> bddebian: Which means illuminator was FTBFS on hppa. Looking now.
<bddebian> Keybuk: Just shut me up if this is a pointless conversation
<dholbach> can somebody take the "Alternate CD, OEM" amd64 installation from me? I never did an OEM install and would prefer to look at some of the icon bugs instead of learning how to do it
<Keybuk> infinity: "Currently building"
<infinity> Keybuk: I know, I just kicked it back from failed.
<Keybuk> Status:  	Currently building
<Keybuk> Date requested: 	2006-05-03 10:40:39 BST
<infinity> Keybuk: You're TOO SLOW.
<jono> dholbach: did you say you have converted Ch7 to HTML?
<Keybuk> infinity: heh, chroot fuckage?
<dholbach> jono: I think Riddell did that
<infinity> Keybuk: No, transient build-dep fuckage, I think.
<jono> ahhhh, so its done?
<dholbach> jono: yeah
<jono> nice
<infinity> Keybuk: There's no such thing as chroot fuckage in the new world order.
<Keybuk> infinity: I keep forgetting that
<Riddell> jono: I did, and I sent it to dholbach who says he's uploaded it
<dholbach> yeah
<jono> oh cool
<jono> just letting the publisher know :)
<jono> thanks chaps
<infinity> Oh, the build-dep breakage wasn't so transient, though..
<Riddell> jono: although I see an e-mail from Nancy Hendryx which says that's not the final version
<bddebian> infinity: Something else broken?
<Riddell> I'm not to bothered about getting the exact final version though, especially for RC
<jono> Riddell: wise
<Keybuk> infinity: if that had built, I'm assuming libluminate6 would have shown up in outdate.txt?
<infinity> Keybuk: No, outdate.txt is from britney, and we only run britney on main. :/
<infinity> Keybuk: universe has no such luxury.
<infinity> Keybuk: (We really need a daily universe britney run)
* bddebian hugs poor Universe ;-)
<Keybuk> ah, we don't have any girls that check for binaries not built by any source?
<infinity> archive-cruft-check.py may do something interesting.
<elmo> possibly not
<elmo> in dak, that check isn't enabled by default
<elmo> because Binaries in Sources lies
<ogra> infinity, bddebian, we had a dholbach instead of a britney back in older releases ;)
<elmo> so it's part of --mode=full, and not --mode=daily.  I'm not sure if I bothered porting --mode=full checks
<bddebian> ogra: :-)
<infinity> It's best done with a combination of tools and manual parsing anyway.
<infinity> Hence why the britney outdate.txt is helpful as a nudge.
<Keybuk> is this a bug?  I chose "Erase Entire Disk" and it decided to just make /dev/hda3 and /dev/hda4 -- not 1 or 2
<Keybuk> well "partition #3" and "partition #4"
<nomed> dholbach, around ?
<dholbach> nomed: yes
<nomed> i see the mixer icon is not in Tango anymore ..
<nomed> but it is still on icon-naming
<nomed> volume-control if i'm not wrong
<infinity> bddebian: petsc is FTBFS on hppa (for real reasons, it would appear), hence illuminator can't build.  You lose.
<nomed> do u think it could be included in tango-icon-common ?
<nomed> i'll tell this to dobey too ..
<nomed> i guess he forgot to remove it from the xml file
<giftnudel> Keybuk: was it 1 and 2 before?
<infinity> Keybuk: Probably best in this case to just remove illuminator (all binaries from source) on hppa, then remove the obsolete libs on the other arches.
<bddebian> infinity: I lose?
<infinity> Keybuk: Having it failed and not built from current source isn't all that helpful.
<heno> infinity: I emailed you some logo files
<Keybuk> giftnudel: the disk is empty
<infinity> heno: Yay.
<giftnudel> Keybuk: I'm indirectly asking about hidden things
<Keybuk> giftnudel: hidden things?
<giftnudel> hidden partitions
<Keybuk> you can hide partitions?
<bddebian> infinity: It's uninstallible because of unmet deps anyway isn't it?
<heno> infinity: do you have an icon making program lined up, or should I look into it?
<giftnudel> Keybuk: yes, the bios can at least on my notebook
<Keybuk> where do they hide?  behind the battery?
<giftnudel> Keybuk: below the harddrive
<Keybuk> giftnudel: well, this drive was in a Toshiba until a few minutes ago
<Keybuk> now it's in a PowerBook
<infinity> heno: I have a WinXP box over there <points> where I'll be testing he icons, so I could edit them there too.
<infinity> heno: If you want to play, though, Mithrandir suggested icoutils.
<heno> infinity: ok, thanks
<iwj> I still get that weirdness where some text-mode thing writes to the video memory during boot and strange pixels appear at the top of the CD boot screen.
<iwj> I presume this is known about.
<infinity> Kamion: Do you prefer I file ubiquity bugs blind, perhaps creating dupes, or give you a 20-second summary to see if you know about it already?
<dholbach> nomed: please talk to andreasn and lapo, I'm very busy
<nomed> ok
<dholbach> nomed: if they update their bzr branches, I can do a release - I'm busy enough chasing other icons -- sorry
<nomed> np
<dholbach> thanks
<infinity> Kamion: Essentially, deleted all the partitions on a disk, hit "next", crashed with "KeyError: 'hdc1'" (one of the partitions I'd just deleted)
<Kamion> bddebian: we have a report for packages that aren't built any more
<infinity> iwj: Is the system where you can reproduce this a desktop or a laptop?
<infinity> iwj: It's somewhat known, and not a dapper target, but I'd like to fix it in edgy, if I could get my hands on hardware where it happens.
<iwj> infinity: Desktop.
<Kamion> infinity: archive-cruft-check.py was broken in mainline lp last I checked; but in any case be careful to run it with -n
<iwj> If you have a bug number I'll subscribe to it and we can pick it up after dapper.
<infinity> iwj: Don't suppose you'd want to lend me the video card?
<Kamion> infinity: I'd rather possibly have dupes
<iwj> It's onboard I'm afraid.
<infinity> iwj: Or bring the box to Paris? :)
<iwj> Box to Paris> not impossible.  I'm going by train.
<infinity> Kamion: Alright.  I'll just file away, then.
<infinity> Kamion: Also, I assume you're not likely to fix the "partition selector loops forever if you have removable rewriteable media installed" bug?
<Kamion> infinity: ooh, if that happens when deleting partitions it might need to be sorted urgently
<infinity> Kamion: I just tripped on that one, and it's already reported by someone else.
<Kamion> infinity: bug#/
<Kamion> ?
<infinity> Kamion: #46389 is the looping thing.  I'll file the crash right now.
<iwj> infinity: But if there's an easier way to do this than lugging a beige box around as part of my luggage I think I'd prefer it :-).
<Kamion> infinity: if the "select disk" page is broken, it would be nice to fix that
<Kamion> but we're rapidly running out of time
* robertj I saw that Gnome released their SOC projects, are Ubuntus out yet?
<infinity> Kamion: #46395 is the crasher.
<iwj> These tests don't seem to suggest doing installs in other languages besides English.  Can we assume that's being taken care of or should I try some tests in Dutch ?
<infinity> iwj: yeah, I can try bouncing binaries off you to test sometime in June.
<infinity> iwj: I just like being able to do a quicker compile/feedback loop.
<iwj> infinity: Sure.
<infinity> iwj: More languages = good.
<infinity> iwj: mvo regularly installs in Greek (despite not speaking a word of Greek)... I often do Japanese..
<Kamion> iwj: please do try other languages, particularly for ubiquity; tests in languages that aren't entirely ASCII are good
<bddebian> Kamion: Sorry, I was afk.  What where you saying?
<infinity> Kamion: Also, ubiquity didn't appear to DTRT WRT the system clock on Zofia's WinXP machine, but I'm pretty sure we're too late to fiddle much with that one.
<mdz> iwj: yes, please do try a random language
* infinity is not overly fond if the new GNOME splash...
<ogra> infinity, use edubuntu :P
<bddebian> infinity: What are you fond of? ;-)
<infinity> Pillow bevels are so... So... Geocities, circa 1997.
* _ion would have prefered the previous "Ubuntu Dapper Beta" one without the Beta.
<pygi> ogra, you again :P
<_ion> But the new one definitely isn't bad.
<infinity> _ion: As would I.
<mdz> infinity: sab
<infinity> mdz: I'll let him get over me accusing him of wanting to shoot puppies before I approach him about the splash change.
<ogra> infinity, edubuntu dapper will give you a beautifully win95 colored look and feel :)
<mdz> infinity: do not use the word 'change' in conversation with the sab
<ogra> haha
<mdz> not until after the release
<ogra> hey, he promised to keep out of egdy, didnt he ... so be carefule after release as well ;)
<Kamion> bddebian: we have a report that tells us about binaries that aren't built any more, so in general there's no need to prod about them
<Keybuk> woohooo!
<Keybuk> "RuntimeError; Install failed with exit code 1"
<bddebian> Kamion: OK, sorry.  I was just trying to clean up unmet deps. :'-(
<Kamion> Keybuk: /var/log/installer/syslog has a more detailed trace
<infinity> Kamion: Argh, okay, maybe mine's not a dupe of that one.  I literally CAN'T select a disk.  I just loop forever.  Even after having removed my CF card and rebooted.
<Keybuk> Kamion: yeah, I like that you made the URL clicky
<_ion> Here's a cool, new splash for Gnome! http://johan.kiviniemi.name/pictures/usplash/ubuntu98
<Kamion> it's from a subprocess so I didn't have time to figure out how to get it through to the crash dialog
<Kamion> Keybuk: that was Riddell's doing
<Kamion> Keybuk: is this on powerpc, with ubiquity 1.0.4?
<Keybuk> Kamion: dunno how to tell the version, but yes, powerpc today
<Kamion> Keybuk: if the traceback complains about base-installer/kernel/linux/link_on_boot being missing, it's fixed in ubiquity 1.0.5
<Keybuk> yes 1.0.5
<Keybuk> uh. 1.0.4
<Kamion> Keybuk: I wouldn't object if you upgraded to that and tried again, if you have time; powerpc obviously hasn't seen much testing because that bug has been around for a while
<Keybuk> Kamion: yeah, it's that bug
<Kamion> careful to upgrade ubiquity-frontend-kde and ubiquity-ubuntu-artwork too
<bddebian> So give me a PPC ;-P
* bddebian shuts up now
<Kamion> I'd like to get my own working properly first ...
<infinity> Kamion: I guess I'll report the loop now. :/
<Kamion> infinity: yes please, and if you can reproduce with UBIQUITY_DEBUG=1, that would be even better
<Keybuk> Kamion: apparently, the problem is that the CD drive sits directly under where your right wrist rests
<infinity> Kamion: I'm sure I can, it seems to hate my system.
<Keybuk> and eventually you push down so much there that you physically bend the CD drive
<Keybuk> it's a "common problem"
<Kamion> mdz: are there still going to be artwork updates post-RC?
<Kamion> R"C"
<mdz> Kamion: unfortunately yes
<mdz> it is beyond my control
<Keybuk> aren't we getting new icons on release day, or something?
<Kamion> mdz: perhaps I should start maintaining a list of ubiquity bug fixes I would like to get in while we're rebuilding livefses anyway, then
<Kamion> because I doubt I have much more time before RC
<jdub> Keybuk: yeah, the new green set is being delivered on the 31st
<mdz> Kamion: well, by my count, we can't even build a plausible candidate until about 8pm
<mdz> given publisher delays
<Kamion> mdz: any ubiquity bug fixes now would push that back, unless by some miracle I can get them done in the next 20 minutes
<infinity> Kamion: installer/syslog and... Anything else for the loop?
<mdz> Kamion: I think at the end of this hour we ought to lock down uploads
<iwj> Hey!  Someone ignored my lock on Testing/Current !"
<mdz> iwj: moin rats them out
<mdz> (when your lock is stolen it tells you who, iirc)
<Keybuk> was probably me
<Kamion> infinity: /var/log/partman
<mdz> infinity: how did you trigger it?
<infinity> Kamion: Done.
<infinity> mdz: "Ran ubiquity".
<iwj> mdz: It didn't seem to tell me who.  It just said `someone'.
<Kamion> mdz: do we have the technical ability to do that in soyuz?
<bddebian> mdz: All uploads or main?
<mvo> mdz: would it be ok for another update-manager upload? breezy-updates and dapper?  [fixes a non-transltable string and the "codename" -> "version"] 
<mdz> infinity: it looped *at startup*?
<Keybuk> Kamion: ah, so hda1 and hda2 are "Apple Partition Map" things?
<mdz> bddebian: we don't have the ability to be more specific
<bddebian> mdz: OK
<mdz> Kamion: yes
<infinity> mdz: No, it loops over and over when I select the disk I want to install to.  Which I mentioned in the bug.
<infinity> mdz: But I did nothing special before that.
<mdz> Kamion: Kinnison gave me some instructions a while back
<iwj> Keybuk: It looks like it was you.  Please be more careful.
<Kamion> Keybuk: hda1 is the partition table itself
<Keybuk> iwj: I don't see the locks, I'm afraid
<Kamion> Keybuk: dunno about hda2, don't want to look now
<mdz> mvo: before the next cron.daily, yes
<Kamion> mdz: oh are you just shutting down the queue processor?
<mdz> Kamion: yes
<infinity> mdz: Oh, crap, can I sync ssl-cert from Debian?  Nothing but updated translations and a dependency fix (needed to depend on adduser, since it uses it in the postinst)
<infinity> mdz: Just realised I'd forgotten until now.
<mdz> infinity: debdiff
<iwj> Keybuk: WDYM you `don't see the locks' ?
<mdz> iwj: it's easy to overlook the warning when you're in a hurry
<infinity> mdz: Literally, "+Depends: adduser", if you don't count the debconf translations.  Let me gra a real debdiff.
<mdz> it really should be an intermediate page, not just a note at the top
<Keybuk> iwj: the moin editor thingy doesn't actually show them
<mdz> infinity: I'm not inclined to trust changelogs at this point
<infinity> mdz: It's my package. :)
<iwj> mdz: hurry> That's true but in the case of Testing/Current I think extra care is warranted because we all should expect everyone to be editing it right now.
<iwj> So I did a Kubuntu test but there is no Kubuntu test plan.
<iwj> I made it up as best I could.
<infinity> mdz: http://cerberus.0c3.net/~adconrad/ssl-cert.diff
<iwj> Is that the right answer ?
<iwj> Should I document what I did ?
<mdz> infinity: oh, I didn't realize
<mdz> infinity: fine
<infinity> mdz: Danke.
<iwj> What issues are known and known not to be release-critical ?  There are 3 things I know of so far where the `corresponding' thing fails a test.
<mdz> iwj: yes, please
<iwj> mdz: Right.
<bddebian> mdz: Will this mean uploads are shutdown for good until Release?
<mdz> iwj: send Simon a mail about it so he can review when he wakes
<sfllaw> mdz: I'm awake.
<mdz> bddebian: well, no
<iwj> mdz: Willdo.
<mdz> sfllaw: good morning
<sfllaw> I've been up for a while now.
<Keybuk> infinity: manual processing of uploads -- process-upload.py ?
<iwj> Also I notice that Riddell put a `Y' in the box which I assume means `pass' but I thought it was `fail'.
<mdz> iwj: Y/N was an older scheme; we switched to pass/fail to make it easier to spot failures
<infinity> Keybuk: Yes, or just drop them in incoming and wait.
<Keybuk> iwj: riddell appears to have used different CDs.  He's PASS/Y'd something which is a guaranteed FAIL without upgrading
<infinity> Keybuk: process-upload takes some pretty viscious arguments and underlying filesystem assumptions.
<Keybuk> infinity: ah, so just stopping the upload queue processor, not the incoming processor?
<infinity> Keybuk: Oh!  We're talking about for manual approval of uploads?
<Keybuk> infinity: right
<infinity> Keybuk: I thought you meant manually feeding something back into the queue.
<Keybuk> no, I know how to do *that* properly now
<infinity> Keybuk: For manual approval, I assume we have a real approval queue, like we do for -updates...
<infinity> But I'm not sure of that..
<Keybuk> given you're talking about stopping uploads, I figured I should probably know how to manually approve them given people ask :)
<Kamion> infinity: if you have time to test http://people.ubuntu.com/~cjwatson/tmp/ubiquity-delete-partitions.diff (just apply it to /usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py), that would be great - though it won't fix your loop
<infinity> When a queue is set for manual approval, it should be manipulated with the queue tool, just like you'd do NEW...
<Kamion> but deleting partitions will be pretty common and I think I need to fix that
<infinity> Kamion: Kay, I guess I'll need to recreate my partitions and delete them again. :)
<mdz> iwj: please only list major issues in the table itself; otherwise it's hard to see the reason for the FAIL
<mdz> iwj: (e.g., #46397 isn't a showstopper by any means)
<bddebian> Since it sounds like I should stop uploading.  Anything I can do to help anyone?
<Kinnison> Kamion: The kubuntu text mode install cd just asked me if my clock is in UTC or not, under what circumstances do we ask that question?
<Kamion> mdz: could you eyeball http://people.ubuntu.com/~cjwatson/tmp/ubiquity-delete-partitions.diff ?
<mdz> iwj: likewise, Kubuntu has never had launchpad-integration
<mjg59> Kinnison: If there's another OS on the drive
<ogra> bddebian, what makes you think you should stop uploading ? 
<Kamion> mdz: I've just verified that it doesn't break normal mountpoint preselection
<bddebian> ogra: They just said they were going to stop uploads
<Kinnison> mjg59: then it asked wrongly because I told it to erase the entire drive
<Riddell> iwj, Keybuk: my Y should be a "PASS with upgrade to ubiquity 1.0.5"
<iwj> mdz: Err, so I should decide for myself whether something is release critical and pass if it isn't ?
<Kinnison> Kamion: is this a known bug, or should I file it?
<Kamion> Kinnison: it'll ask in the event that you don't have Windows installed.
<Kamion> notabug
<Kinnison> okay
<ogra> bddebian, so then upload until you get "rjected" messages from LP ;)
<Kinnison> Kamion: I'll carry on then :-)
<iwj> mdz: Perhaps it would be better to write the test plan so that expected and known behaviours, which are not RC, are not tripped by the tester.
<Kamion> Kinnison: it doesn't know whether you're UTC or not; you might have had Windows on there at some point in the past
<mdz> iwj: I trust you to judge the difference between a missing feature and a release-relevant bug
<iwj> iwj: Right, that's fine.
<bddebian> ogra: Heh
* mvo goes to do sports, bb in 2h
<mdz> iwj: apart from the 3 bug numbers in the table, your Kubuntu installation was successful?  if so, that should be a PASS; I looked at each of the bugs and they're cosmetic or missing features
<mdz> iwj: one of  them is listed twice,though, so maybe you found another issue?
<Kamion> mdz: verified that that diff fixes the claimed bug too
<iwj> mdz: I'll check.
<mdz> Kamion: going as fast as I can
<siretart> err, did anyone else notice bug #46285? I'm seeing it as well on my machine...
<Ubugtu> Malone bug 46285 in ia32-libs "pre-installation of the package is trying overwrite '/usr/bin/ldd' with  `/usr/bin/ldd.amd64'" [Normal,Unconfirmed]  http://launchpad.net/bugs/46285
<Kamion> I managed to reproduce it locally
<mdz> Kamion: self.size is a hash of 'hda1' : int?
<Keybuk> siretart: I have a later version than that installed
<Keybuk> siretart: 2006-05-22 10:38:50 upgrade ia32-libs 1.4ubuntu17 1.4ubuntu18
<Keybuk> siretart: and did the same upgrade
<Keybuk> (successfully)
<mdz> yep
<siretart> Keybuk: I'm seeing it with 1.4ubuntu18
<mdz> Kamion: go ahead
<Kamion> mdz: bug 46398 needs to be fixed pre-release, but there's no way I have time to do it now
<Ubugtu> Malone bug 46398 in ubiquity ""Select a disk" loops forever..." [Normal,Unconfirmed]  http://launchpad.net/bugs/46398
<mdz> Kamion: add to DRR
<Kamion> will do
<Keybuk> what does auto-resize mean?
<Keybuk> I've always wondered that
<mdz> Keybuk: "resize partition <foo> and use freed space"
<Keybuk> isn't that custom partitioning?
<Kamion> mdz: self.size> correct
<Kamion> Keybuk: no
<sfllaw> mdz: jbailey thought he found two RC bugs on amd64.  But I don't think he's filed them yet.
<mdz> no
<Kamion> custom => "Manual partitioning"
<Keybuk> what's custom partitioning?
<Keybuk> you have to do manual partitioning to resize partitions though?
<mdz> Keybuk: "partition manually" or whatever
<Kamion> no you don't
<mdz> Keybuk: gparted
<Keybuk> you don't?
* Keybuk is confused
<Kamion> sometimes partman offers you the opportunity to resize the biggest resizable partition on your disk and autopartition the free space created by doing that
<Keybuk> under what conditions does it offer that?
<Kamion> it's a bit complicated and there are several constraints so it cannot always offer it
<Keybuk> ah, right
<Keybuk> what should I put for that?  "Unable to test" or something?
<infinity> Kamion: That patch appears to fix my crash-on-partition-deletion bug, yes.
<Kamion> if there is already >=2.2GB unpartitioned space it won't offer it; there needs to be a resizable partition with >=3GB free (and HFS doesn't count as resizable here, which is probably an error)
<Kamion> on x86, there needs to be room to create a primary partition
<Keybuk> ah, so it can't be offered for powerpc anyway?
<Kamion> which means that there must be <4 primary partitions in existence already, and if there are no logical partitions then there must be <3 primary partitions so that it can also create an extended partition
<Keybuk> there appears to be 9 primary partitions in existance
<iwj> I told the installer Dutch, in London, and it offers me Belgian as the default choice for keyboard ...
<Kamion> and if there's already an extended partition then logical partitions in the middle of it don't count
<Keybuk> do macs have primary and extended partitions still then?
<Kamion> Keybuk: the Mac partition table does not, no
<Kamion> it only has one partition type; much saner
<Keybuk> I assumed they'd just have some randomly different table
<Kamion> Keybuk: yeah, powerpc probably won't see it very often at present
<Keybuk> any easy way to trigger it for testing purposes?
<pitti> I'm glad to report that with an updated ubiquity, and today's fixes, all ppc scenarios (except my untested 'expert' variant) succeed
<iwj> Under what circumstances is auto-resize supposed to work ?
<Kamion> iwj: known bug; we have trouble dealing with language/country combinations that don't match up to a locale in /usr/share/i18n/SUPPORTED
<Kamion> iwj: I just spent several lines outlining the exact circumstances where it's offered above
<infinity> Kamion: FWIW, the loop is definitely a regression, since the last time I used espresso/ubiquity on this machine, it was able to "take over /dev/hdc" just fine.
<Kamion> pitti: great
<Kamion> Keybuk: not really :-/
<pitti> ouch @ ubuntu-meta 0.116
<Kamion> oh I suppose you could create a large vfat partition
<pitti> oh, that was from yesterday
<Keybuk> Kamion: hmm. 1.0.6 could explain my earlier crash ... I might retry that drive with 1.0.6 in a bit
<Kamion> might still not quite work though; it should log why it isn't offering it
<iwj> Kamion: Oh, so you did, thanks.
<Kamion> Keybuk: I'll go through later and play hunt-the-duplicate
<iwj> Unfortunately I don't think I can create those conditions without going and buying a disk ...
<pitti> Kamion: btw, all my attempts to create a large vfat partition on ppc failed; for some reason, gparted only sees unknwon partitions then
<Kamion> Keybuk: no, your crash is different
<iwj> And now I've managed to lock up the partitioner.
<pitti> Kamion: however, this feature isn't so interesting on ppc anyway, I'll test it on amd64 again on Sunday
<Keybuk> Kamion: oh, ok
<Kamion> Keybuk: there are a lot of instances of things like your crash though; I'll add an item to the radar to defend against those
<Keybuk> Riddell: how did you get auto-resize to be offered on powerpc?  You've put "Y" for that
<infinity> Kamion: I like how d-i uses the reverse DNS for my IP as my suggested hostname.  Is it too late to sneak that feature into ubiquity?
<infinity> (or too much code)
<Kamion> infinity: discussed at length at UI sprint, explicitly decided not to
<infinity> Of course, others may hate that.  I like it, cause my reverse DNS here is correct, so I get to type less.
<Kamion> -> sabdfl
<infinity> Kamion: Ahh, damn.
<Kamion> infinity: I like it too on my network, but I have to admit that for many users in ubiquity's target audience, the reverse DNS is useless
<iwj> Kamion: I've still got the system in the stuck state I report in bug 46404.  Do you want me to do any investigation right now ?
<Ubugtu> Malone bug 46404 in ubiquity "partitioner locked up" [Normal,Unconfirmed]  http://launchpad.net/bugs/46404
<infinity> Kamion: Quite probably true.  And I'll admit that I'd never use ubuquity except in testing, so there we go. :)
<iwj> (Let's all pile on Kamion until he's completely squashed.)
<infinity> ubuquity?  Wow.  FINGERS, GO.
<mdz> Riddell: please use PASS/FAIL rather than Y/N, as documented on the page
<Keybuk> infinity: infiquity
<Kamion> iwj: can you attach /var/log/installer/syslog and /var/log/partman to that bug please? I'd also like to know what processes are running as root
<iwj> Kamion: Willdo.
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Release preparation in progress: https://wiki.ubuntu.com/DapperReleaseRadar | Uploads are disabled
<Kamion> I think the large blank window is known but it's Kubuntu-specific; Riddell would know better
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Release preparation in progress: https://wiki.ubuntu.com/DapperReleaseRadar | Uploads are queued while a candidate is prepared
<ogra> phew, luky me :)
<Kamion> I haven't kept track of the Kubuntu-specific bugs in all cases
<ogra> *lucky even
<infinity> mdz: Do we have the means to just lock off main, or did we kill the queue completely?
<Kamion> mdz: you'll need to manually process binary uploads of stuff that got uploaded just before the cut-off
<Kamion> or I can do that, but I need dinner now
<mdz> Kamion: I'm told that is not the case
<Kamion> iwj: /nick ______
<Kamion> mdz: fair enough, I stand corrected
<mdz> infinity: everything
<Kamion> we should make sure ubiquity 1.0.6 binaries definitely get in though
<mdz> Kamion: I confirmed with celso that the source was processed
<Keybuk> Kamion: pass with 1.0.5, fixed the link_on_boot bug
<mdz> and its binaries should make their way in along with everything else
<ogra> edubuntu-{meta,artwork} would also be nice
<infinity> Well, at least grub-install worked right.  Woo.
* infinity goes to lock the wiki.
<mdz> ogra: you already uploaded them less than an hour ago; they had better be final
<ogra> mdz, its only language additions to amd64 and dropping the dapper from the ff homepage 
<mdz> ogra: *you already uploaded that*
<ogra> yes
<Kamion> Keybuk: hooray
<mdz> so what do we have to talk about?
<iwj> Kamion: done.
<mgalvin> just a heads up... i got DapperRC all set in case anyone has time to review/proof it (its not to long, this is all i have time for ATM)
<Kamion> he's asking to check that they're in
<ogra> mdz, nothing then i guess, i misunderstood it seems
<mdz> everything accepted before I announced the change was processed, of course
<infinity> Kamion: How and when would I see "auto-resize" in ubiquity?
* Keybuk watches Kamion destroy infinity
<infinity> Kamion: Or will that not appear for me, thanks to the infinite loop bug?
<iwj> infinity: Stop wittering on IRC and save Testing/Current :-).
<ogra> mdz, ok, the "binary stuff might need manual love" was confusing me
<Kamion> infinity: same reasons as above
<Kamion> infinity: it's passed straight through from partman
<mdz> ogra: I just installed Edubuntu, and it shows the CD with a DVD icon. is this normal?
<Kamion> you probably won't get it due to the infinite loop at select disk
<infinity> iwj: Saving...
<infinity> Kamion: Kay.
<ogra> mdz, meh, cant tell, i only have DVDs to test the isos here 
<mdz> ogra: as I said to Kamion at the time, no special care is needed for binary uploads
<ogra> yep
<infinity> Kamion: Sorry to irritate; Bouncing between IRC and installers is making me lose coherence.
* ogra looks for a CD to test the icon stuff with
<infinity> Also, WIKI, SAVE FASTER.
<Keybuk> I need to get some writable DVDs at some point
<Keybuk> I've had a DVD writer for ages, and never actually used it
<Kinnison> iwj: has firefox lost the ability to remember where I put it and with what toolbars I want it to appear?
<iwj> Kinnison: Err, I know of no reason why it should ...
<ogra> mdz, works fine with a windows driver CD i have lying around here, it can only be the ubuntu/edubuntu CD doesnt get recognized right i think
<iwj> Perhaps your profile has been evaporated somehow.
<Kinnison> iwj: I think my profile must be way bugggered then
* Kinnison tries moving it out of the way
<crimsun> danimo: pong, please tell me the output from ``tail -2 /proc/asound/oss/sndstat'' in #ubuntu+1
<iwj> That profile system is truly one of the worst inventions ever.  Less transparent and reliable than the 'doze registry, less structured than /etc+~/.*, less well documented than IRC client settings, ...
<mdz> ogra: it's a hal problem
<Kinnison> iwj: aye
<Keybuk> Kamion: minor bug; Kubuntu ppc alternate still calls itself "Kubuntu installation CDROM"
<mdz> volume.disc_type = 'dvd_rom'
<iwj> infinity: Yay, I got the lock.  Ta.
<Keybuk> mdz: could you do a udevinfo -ap on the device too?
<mdz> I wonder why this doesn't happen with Ubuntu
<Keybuk> and nopaste it somewhere
<crimsun> pitti: looks like g-s-t (and asoundconf's convenience setter) should set all those values from /usr/share/alsa/alsa.conf  (cf. #43146)
<Kinnison> iwj: I think it was something in my profile
<Kinnison> iwj: Now I need to feed it bit by bit the stuff I care about (E.g. bookmarks)
* Kinnison sighs
<ogra> mdz, ok
<infinity> mdz: We'll want to manually push the OOo-amd64 source upload through in a bit, I think.
<infinity> mdz: Doing the i386 upload right now.
<mdz> infinity: *groan*
<crimsun> pitti: err, not g-s-t but g-c-c rather (fumblefingers)
<mdz> infinity: I think it may need to wait until after RC then
<mdz> i can't stay here all night
<infinity> mdz: Kay, well i386 will be in at least.
<Keybuk> mdz: actually, I mean can you do "udevinfo -q all -n /dev/hdX" :p
<mdz> infinity: depending on how long from now 'a bit' is
<mdz> Keybuk: it's a pain to copy the data off; any particular field you're interested in?
<mdz> ID_TYPE=cd
<Keybuk> mdz: IDE_CDROM_DVD
<mdz> Keybuk: not present
<Keybuk> mdz: does it have "S: dvd"
<mdz> Keybuk: no, S: cdrom
<Keybuk> fair enough
<Keybuk> iz hal bug
<Keybuk> (occasionally what look like hal bugs turn out to be ata driver bugs)
<infinity> mdz: Well, it'll take a publisher run to get the i386 binaries in, then the -amd64 source package can be rolled and shoved in.
<jdub> Keybuk: so long as it supports dma...
* Keybuk tips a siege tower of custard over jdub
<ogra> why custard ... ?
<ogra> mustard smells more funny :)
<mdz> infinity: a publisher run should have started on the hour, no?
<infinity> mdz: I'm not overly fussed if it doesn't make RC... i386 is the most tested arch anyway, so having the most recent binaries there is more useful.
<infinity> mdz: Yeah, but I'm uploading the i386 binaries /now/.
<mdz> infinity: oh :-/
<infinity> mdz: I can hand-drive another publisher run, though.
<mdz> I thought they were already in
<mdz> ogra: happens in ubuntu, too
<mdz> must be something with vmware
<ogra> mdz, ok, thats calmig fro edubuntu, but not nice ...
* ogra looks at the hal ML i think there was a patch flying around
<mdz> probably vmware just doesn't report the media type correctly
<infinity> mdz: We don't have a hope of seeing binaries on powerpc for ages anyway, so unless we want specific testing of the -amd64 stuff, it's not like they'll all be in sync anyway.
<ogra> mdz, sad, the patch i remembered was only for burn capabilities ...
<ogra> so lets blame vmware ...
<ogra> (for now, i'll test it later tonight here)
<mdz> infinity: huhwhat powerpc?
<infinity> mdz: OOo powerpc... Only been building for an hour...
<mdz> oh, right, the new one
<mdz> at least it has ubuntu8 though
<infinity> Yeah, true dat.
<Riddell> Keybuk: auto-resize is offered if partman recons it can do it
<Keybuk> Riddell: what did you do to make partman offer it?
<Riddell> doing a erase all install then a second install will offer it
<Keybuk> cool, will try that
<Riddell> assuming your hard disk is big enough
<dholbach> do I assume correctly, that I can upload ubuntu-artwork now and it will be queued and everything's fine?
<mdz> dholbach: yes
<janimo> nomed: ping
<janimo> I just tested and see the firefox bug as well
<dholbach> because it fixes two issues we got a bunch of duplicates for, I'd be happy if it was in.
<Keybuk> Riddell: ah, this is only a 4GB
<janimo> Gloubiboulga: did the install finish well?
<Gloubiboulga> janimo, yes
<Keybuk> that would explain why it also wasn't offered by the alternate CD
<nomed> janimo, plese read the log of xubuntu :)
<janimo> Gloubiboulga: hmm still ltsp? I tought I took that out
<janimo> nomed, ok :)
<nomed> i listed some issues that should be fixed
<janimo> Gloubiboulga: did it take a lot of time again building ltsp chroot?
<Gloubiboulga> janimo, it's the same error than the first time I got it
<Gloubiboulga> janimo, yes
<nomed> janimo, have u seen the new xfdesktop patch ?
<janimo> nomed, not yet
<janimo> was away the past 2 hours
<nomed> check xfce-devel
<Keybuk> *blink*
<Keybuk> "The installation CD does not contain full support for your language"
<Keybuk> are we not shipping English anymore?
<janimo> Gloubiboulga: very strange since there is no ltsp in the desktop or install seed
<Kamion> Keybuk: true - can you file that on /products/ubuntu-cdimage? May not get fixed now though.
<Kamion> ("Kubuntu installation cdrom"
<Kamion> )
<Kamion> Keybuk: language-support-en should definitely be there
<Kamion> Keybuk: what CD is that?
<Keybuk> it had to download it
<Keybuk> Kubuntu PPC Alternate
<Kamion> it's seeded
<Gloubiboulga> janimo, yes, that's strange...
<Keybuk> it's also in /cdrom/pool
<Keybuk> weird
<Keybuk> so why did it ask me?
<ogra> oversized ? is it missing partially or a dependency ? 
<Kamion> Keybuk: could you complete the installation and put /var/log/installer/syslog somewhere please?
<janimo> Gloubiboulga: can you do a dist-upgrade and see if today's changes are ok?
<Kamion> ogra: pkgsel wouldn't notice if it were
<ogra> hmm
<Kamion>                 if ! [ "$(chroot /target apt-cache -n search "^language-support-$l\$")" ] ; then
<iwj> Kamion: do you want anything else from this wedged box or can I reboot it ?
<Kamion> that's the test
<Keybuk> Kamion: sure, what should I file the bug on?
<Kamion> Keybuk: pkgsel
<janimo> Gloubiboulga: aboiut page linking to the desktop guide, and the cursor theme is human (strtup notification icon )
<Kinnison> Keybuk: I just did a kubuntu-alternative install of english and it worked (i386)
<Gloubiboulga> janimo, ok, I need to reboot
<Keybuk> Kamion: I can greb the log for something, any text I should look for?
<lamont> remind me what the cdbs target is for applying patches?
<Kamion> Riddell: I think iwj's problem (bug 46404) is ubiquity waiting for qtparted to exit; can you have a look and see if you need any more info?
<Ubugtu> Malone bug 46404 in ubiquity "partitioner locked up" [Normal,Unconfirmed]  http://launchpad.net/bugs/46404
<janimo> nomed: weird the firefox bug, should it not be the same in gnome?
<ogra> Kamion, Keybuk, well http://cdimage.ubuntu.com/kubuntu/daily/current/report.html
<Kamion> iwj: stracing the qtparted process there (7324) for a bit might not do any harm
<Kamion> ogra: certainly won't help
<nomed> janimo, i guess it 's the same in gnome
<janimo> nomed: apparently #xubuntu is not logged? was the discussion in u-meeting by any chance?
<Kinnison> Riddell: kubuntu didn't usplash_down from kdm, is this a known bug?
<ogra> Kamion, looks horrible ... and if Keybuk got that one i think its likely that something is missing
<Kamion> Keybuk: actually can you do 'debconf-get localechooser/supported-locales' please?
<Keybuk> Kamion: there's a message -- "pkgsel: language-support packages not available on CD"
<nomed> janimo mainly ..
<janimo> nomed: I wonder why we get the bug? I doubt people wouldn't not notice it so far if it happened in gnome too
<Kamion> Keybuk: does /cdrom/.disk/base_installable exist?
<Kamion> (sanity check)
<Kamion> ogra: yes but let me debug this as well please
<Keybuk> Kamion: yes
<nomed> 1) usplash has an issue
<ogra> Kamion, sorry
<nomed> if you do not use 640x400 you'll see two lines ..
<Keybuk> Kamion: en_GB.UTF-8, en_US.UTF-8
<nomed> as if the image is 2px smaller
<Kamion> Keybuk: chroot /target apt-cache -n search "^language-support-en"
<Kamion> Keybuk: chroot /target apt-cache -n search "^language-support-en$"
<Keybuk> Kamion: zilch
<Kamion> (sorry, first was wrong)
<Riddell> Kinnison: it does fail sometimes yes
<janimo> nomed, seems like I was too optimistic when I taught it would be the last usplash upload :(
<Riddell> Kinnison: how did you logout?
<nomed> janimo, then gdm theme should use tango style icons ..
<Kinnison> Riddell: logout from the K menu, chose "turn off computer"
<Keybuk> Kamion: not in /cdrom/pool
<janimo> nomed: I think it is too late for the gdm theme to be redone
<nomed> the ones used are not really nice with the wholo xubuntu-look
<nomed> janimo, just change the icons
<Kamion> Keybuk: I thought you said language-support-en was in /cdrom/pool
<Kamion> 18:45 < Keybuk> it's also in /cdrom/pool
<janimo> nomed: especially if it happens in the same style as before with me ping-ponging mails with the art guy
<Keybuk> Kamion: sorry I confused language-support-en with language-BASE-en
<Kamion> ym pack?
<Keybuk> yes, I mean pack
<Keybuk> see :)
<iwj> Kamion: It's looping:  select, returns immediately because 0 is readable; fstat64(0,); _llseek(0,)->ESPIPE; read(0)->EOF; ioctl(3,FIONREAD,[0] )
<Kamion> ah, then it is just the oversizing and ogra is correct. sorry ogra
<Riddell> Kamion: looking
<janimo> nomed: it would be best if there was a discussion on the list (not just PM to me) and if people pick 3-4 icons which are better I will include them in an upcoming upload
* lamont grumbles at the lack of seb128
<Keybuk> right-o; no point filing this as a bug then?
* fabbione points lamont to dholbach 
<nomed> janimo, ok
<ogra> Kamion, no need to feel sorry, youre usually right, was just a matter of my belly and luck ;)
<Gloubiboulga> janimo: xubuntu-desktop depends on ubuntu-artwork now ?
<Kamion> iwj: right, dumped that into the bug and reassigned to qtparted then
<janimo> nomed: thanks. indeed it does not seem much work, but only for someone who knows what he's doing. So I just upload do not decide :)
<Kamion> oh bugger, wrong bug
* lamont pokes dholbach 
<dholbach> lamont: how can I help you?
<Keybuk> clearly I need to step away from the computer for a little bit, I'm unable to even read the screen properly anymore
<janimo> Gloubiboulga: yes, for the Human cursos theme
<Gloubiboulga> ok
<janimo> Gloubiboulga: I hope it does not break anything 
<lamont> dholbach: somewhere in metacity it makes a decision that if the newly created/rendered window doesn't get focus, then it should render under.  or maybe it just forces the focused window to the front, dunno...)  can you point me at where?
<Kamion> Keybuk: no, but we do need to sort out that oversizing before release
<Gloubiboulga> janimo: I'm dist upgrading, I'll remove my config and log in again
<Kamion> before RC even
<janimo> glthanks
<nomed> i think is a good idea to have ubuntu-artwork anyway ..
<iwj> Kamion: OK.  I'll gdb it and paste in the stack trace, too, I think, and then reboot.
<nomed> janimo, those icons of the quit dialog are from ?
<dholbach> lamont: I'll have to have a look. I know that we have a patch in there, just for you :)
<janimo> nomed: I took them from the Human icon theme which gnome uses for logout
<janimo> I don';t really want to chaneg them again
<nomed> no no ..
<janimo> are they not pretty :) ?
<lamont> dholbach: further investigation shows that it's the auto-raise deciding to yank the (still-)focused window to the top
<nomed> so we may use them too within gdm theme
* lamont wants to tweak his personal metacity patch, you see...
<Keybuk> dholbach: now is not the time to bitch that after I patiently spent ages making sure the "Reboot Required" dialog icon and panel icon matched, someone appears to have made them different? :)
<janimo> nomed: ah yes
<janimo> nomed: I agree
<Gloubiboulga> janimo: I have a nice white mouse cursor :)
<janimo> Gloubiboulga: nice :)
<astronut> doko: ping
<dholbach> Keybuk: which ones?!
<dholbach> Keybuk: which ubuntu-artwork version?
<Gloubiboulga> janimo: what should I look about the documentation?
<Keybuk> dholbach: the applet panel icon is supposed to be a mini version of the icon in the dialog which is supposed to be the same as the icon in the shutdown dialog
<Keybuk> none of these three things is true anymore
<janimo> Gloubiboulga: it was there while gdm was depending on ubunut-artwork and disappeared when that went away
<Keybuk> whatever's on the candidates we're testing
<janimo> Gloubiboulga: see if the start page links to the desktop guide in the help section
<nomed> janimo, so you could just do that (?)
<dholbach> Keybuk: reboot required should have the same as in the logout dialog
<dholbach> Keybuk: i sent the icon to mvo to change it
<Gloubiboulga> janimo: yes, it's correctly linked
<dholbach> Keybuk: there was a bug report and it's fixed
<dholbach> Keybuk: can you show me a screenshot?
<janimo> Gloubiboulga: ok, too bad there are no translations at all for the about page
<Keybuk> yup, one moment
<janimo> Gloubiboulga: thanks I think those are the only changes made since yesterday
<dholbach> lamont: I'm sorry, I never plunged into the depths of metacity.  :(
<janimo> now I have to figure out what is wrong with the ltsp
<Keybuk> dholbach: ah, there appears to be a new version _TODAY_
<dholbach> Keybuk: it's been fixed since some days
<lamont> dholbach: no worries
<Keybuk> dholbach: I haven't updated in a few days
<lamont> do we expect seb128 back in the next day or 2?
<Keybuk> I just keep forgetting to mention it
<dholbach> Keybuk: ... guy! :)
* lamont expects he just went to dinner/bed/whatever
<janimo> nomed: if they are separate files I'll do that
<dholbach> lamont: testing edubuntu cds
<lamont> ah, ok
* lamont tries updating his patch.
<ogra> dholbach, oh, wow !
<dholbach> Keybuk: i think that's bug 45137
<Ubugtu> Malone bug 45137 in update-notifier "Three different images for restart" [Minor,Fix released]  http://launchpad.net/bugs/45137
<Keybuk> dholbach: yeah, when I wrote it I made damned sure all the icons matched
<Gloubiboulga> janimo: do you know which file I should edit to change the gdm theme?
<Keybuk> I even made a little icon to match <g>
* dholbach hugs Keybuk :)
<Keybuk> was ironically amusing to discover someone had broken that
<nomed> janimo, /usr/share/gdm/themes/xubuntu/
<janimo> Gloubiboulga: /etc/gdm/gdm-cdd.conf
<janimo> heh :)
<lamont> dholbach: looks like someone may have fixed a race condition that creates my current annoyance.
<janimo> Gloubiboulga: ah the theme itself, then nomed is right
* lamont will ponder
<tepsipakki> could the leak fix in bug #46417 still make it for dapper?
<Ubugtu> Malone bug 46417 in krb5 "a memory leak in rel_cred.c" [Normal,Unconfirmed]  http://launchpad.net/bugs/46417
<Gloubiboulga> nomed, janimo, I don't want to edit the theme, I just want to use an other one, and change the gdm config for that :)
<Keybuk> mdz: do we really have cron.daily enabled on the Live CD ? :)
<lamont> Keybuk: I don't recall ever disabling it.
<ogra> Gloubiboulga, use sudo gdmsetup 
<nomed> Gloubiboulga, i guess you could do that using gdmsetup
<nomed> yep
<Keybuk> wouldn't anacron automatically assume that it's been "more than a day" since it was last booted, on the basis of the CD image creation time
<Keybuk> so always run cron.daily when ever some poor bugger boots the Live CD ?
<Gloubiboulga> ogra: someone on #xubuntu says that gdmsetup segfaults
<ogra> Gloubiboulga, not on ubuntu/edubuntu ... must be xubuntu specific
<Gloubiboulga> it works fine here, but *he* wants to change the theme
<mdz> Keybuk: we disabled it in Breezy
<mdz> iirc
<Keybuk> you're the one that suggested updatedb ran in my Live session :)
<janimo> Gloubiboulga: then the file I said under /etc/gdm
<mdz> Keybuk: you're the one who invented this crazy story about /rofs in locate's database
<Gloubiboulga> janimo: yep
<janimo> Gloubiboulga: can you ask him to file a bug if he can reproduce it?
<Keybuk> mdz: it's not a story, it's TRUE!
<mdz> Keybuk: you confirmed the db had been updated?
<nomed> Gloubiboulga, he could run gdmsetup from shell 
<Keybuk> in a few hours, once this alternate test has finished, I'll boot Live again and prove it to you
<janimo> althiugh gdmsetup is the exact same as in ubuntu, that we did not need to modify
<Keybuk> janimo: gdmsetup sometimes segfaults if gdm has gone away since the session started
<Gloubiboulga> janimo: I asked him to file the bug already, and he's gone now...
<mdz> Keybuk: if you confirm, get together with Mithrandir and see that it's corrected
<nomed> it works here ..
<janimo> Keybuk: oh so it's known
<mdz> Keybuk: you reckon we should just disable cron?
<mdz> seems a bit heavy-handed
<janimo> Gloubiboulga: ok it is not such a big issue imho
<Keybuk> mdz: at least the built-in cron
<Gloubiboulga> janimo: nop
<Keybuk> ie. not do /etc/crontab or /etc/cron.*  (maybe unless there's a cow)
<ogra> Keybuk, how can gdm go away without killing my session ? 
<Keybuk> ogra: upgrade
<janimo> as in gdm restart?
<lamont> mdz: or at least tell it that cron.daily ran already
<ogra> hmm, so out of sync between the running gdm and gdmsetup ...
<ogra> right ...
<mdz> lamont: I don't think cron keeps state
<Keybuk> anacron does though
<infinity> yeah, it's probably saner to get casper to tell anacron/cron that .daily just ran...
<mdz> but anacron only runs from cron
<Keybuk> mdz: and on boot
<mdz> and we  don't want the other cron jobs to run either
<mdz> Keybuk: it's disabled on boot
<infinity> If you have a livecd up for 24 hours, maybe you want .daily to run... (Say, when I decide to start rolling ubuntu-server livecds in edgy)
<Keybuk> mdz: really?  I thought I saw it in the boot sequence though I MAY HAVE BEEN HALLUCINATING ;)
<lamont> infinity: true
<mdz> Keybuk: by casper
<kmr-away> could someone confirm I'm using launchpad correctly? I reported a serious bug 2 weeks along with a simple patch along with links to a test case, but launchpad still shows the bug as unconfirmed. I wonder if I should be doing something more: https://launchpad.net/distros/ubuntu/+source/imagemagick/+bug/44307
<Ubugtu> Malone bug 44307 in imagemagick "Assertion failure processing ICC profiles with perlmagick" [Major,Unconfirmed]  
<mdz> Keybuk: ./casper-bottom/25configure_init:rm -f /root/etc/rc?.d/S??anacron
<mdz> kmr: see /topic
<Keybuk> mdz: well, that would certainly do it
<ogra> kmr, please ask on #launchpad
<mdz> kmr: we're in the middle of a release
<kmr> okay, thanks for the tips!
<janimo> nomed, xfdesktop patch looks interesting, and would be nice but I think it's too late for it
<Keybuk> mdz: what puts that back for the real install?
<janimo> have you tried it?
<mdz> Keybuk: nothing; ubiquity copies /rofs
<nomed> not yet ..
<kmr> /#launchpad
<Keybuk> mdz: cunning
<mdz> Keybuk: hence it having to remove langpacks, etc.
<Keybuk> oh, wow, this goes so much faster if I fiddle with hdparm in the installer
<ogra> Keybuk, what ? udev didnt set DMA right for your CDrom ? *g*
<Keybuk> heh @ "The drive appears confused"
<Keybuk> ogra: udev doesn't set DMA ... the kernel does
<ogra> :)
<nomed> janimo, may u take a look on xfce4-mixer?
<nomed>  xfce4-mixer-4.3.90.1svn+r21697/settings/sound.c
<Keybuk> THERE ARE NO UDEV BUGS
<bddebian> heh
<bddebian> Heya LaserJock
<janimo> Kamion, any idea how ltsp can be on yestardays xubuntu CD if it's not in the desktop or installer seed?It is in ship though
<janimo> Kamion: I mean not how can it be on the CD but why does it try to get installed
<ogra> Keybuk, as there are only ltsp whishlist bugs (for edgy) :P
<janimo> nomed: what to look at? I have played with icon names yesterday
<nomed> if we want the correct icon we need to patch that file
<nomed> it looked really simple ..
<janimo> nomed, did it fix it?
<Keybuk> ooh, wow, it's finally finished configuring stuff
<nomed> but i do not get the icon on xfce-settings-show
<nomed> just on 
<janimo> I changed the icon name as well, but am not sure what to use to be ok across themes
<nomed> xfce-settings-show sound header
* bddebian has no idea what to do at them moment :-(
<nomed> xfce4-sound
<janimo> xfce4-sound does not look like what benny had in his screenshot
<janimo> did that icon go away entirely?
<nomed> janimo, it the correct icon for that dialog
<nomed> preferencies-sound
<nomed> xfce4-mixer is a link to
<mdz> Kamion: I added a post-RC section to DRR; do you have anything to add?
<mdz> (to it)
<nomed> volume-control that's gone in tango because of gpl .. and not cc
<nomed> is the xfce4-mixer icon
<nomed> but for that dialog xfce4-sound is the best choice 
<nomed> that's how i patched legacy.xml
<nomed> and what upstreamer should use
<Keybuk> Riddell: what's /etc/rcS.d/S37displayconfig-hwprobe.py ?
<nomed> xfce4-mixer is the app icon
<Lure> Keybuk: afair, DPI setting for fonts in KDE
<Keybuk> because it might be useful if that's moved to *after* /usr is mounted
<Keybuk> being written in Python, and all
<Keybuk> just a thought
<Riddell> Keybuk: isn't that S35mountall.sh?
<Keybuk> Riddell: no, /usr isn't available until ~ S50
<Keybuk> Riddell: that should be S50...  like hwclock, etc.
<Keybuk> I put /usr on a usb stick, just to make things interesting with custom partitioning
<Riddell> ok, I can change that after RC
<Keybuk> mountall only mounts local stuff on the same bus from /etc/fstab, etc.
<Keybuk> and dude, dpkg-reconfigure in boot?!
<Keybuk> sick, sick puppy
<sabdfl> special kind of twisted, that
<ogra> Keybuk, casper and ltsp-client do that too ;)
<Keybuk> ogra: damning praise
<ogra> heh
<Keybuk> https://wiki.ubuntu.com/StreamlinedBoot  <--  look, I _actually_ documented what you can do at each point in rcS.d :p
<Riddell> are there any plans to build the CDs to pick up ubiquity and other changes?
<ogra> Keybuk, isnt it written in rcS README anyway ?
<ogra> or init.d/README, cant remeber
<Keybuk> ogra: heh, amusingly, rcS README is wrong
<ogra> infinity, BUG ! :)
<Keybuk> I'll fix that in edgy, by removing /etc/rcS.d
<mdz> infinity: hmm, no oo.o in the latest publisher run?
<ogra> haha
<Keybuk> (note: lie)
<fabbione> ogra: you do what???????? dpkg-reconfigure at boot???
* fabbione sighs
<Keybuk> Riddell: actually, thinking about it, put that at S60 -- that's the "right" place for it
<ogra> fabbione, how else should the X server autoconfig work 
* fabbione will start asking all X config question at pri critical
<Keybuk> fabbione: DO IT!
<fabbione> Keybuk: that would fix your bug too :)
<ogra> fabbione, both, the liveCD and ltsp rely on it
<mdz> fabbione: dude, it's a stateless thin client
<Keybuk> mdz: actually, this is just Kubuntu install
<fabbione> mdz -> vesa driver and a fast xresprobe to catch DDC or fall back.. no need to reconfigure
<fabbione> call dexconf to write the config for you
<fabbione> 3 times as fast
<ogra> fabbione, what about lts.conf and all the preseeded Xorg values ? should we sed it ?
<fabbione> better results
<mdz> fabbione: it's been this way for a year
<ogra> and its the *right* way if you need to preseed
<fabbione> ogra: you can still preseed some stuff...
<fabbione> mdz: i didn't write it or being asked on how to do it
<ogra> fabbione, like mouse device or keymap ?
<mdz> we shouldn't forego acceleration to gain a few seconds at boot time
<fabbione> ogra: dexconf uses the values in debconf
<ogra> fabbione, and dexconf is called by -reconfigure, no ?
<fabbione> ogra: yes, but reconfigure has hell of a bloat of code compared to dexconf
<fabbione> mdz: well it's quite a bunch of seconds
<fabbione> anyway
<fabbione> it's kind of late for dapper
<ogra> yes, i know, its my slowest bootstep still
<mdz> I think it's about 3 here
<ogra> fabbione, lets talk in paris ...
<ogra> argh
<ogra> youre not in paris
<fabbione> ogra: nope.. i won't be there
<Keybuk> "mount: Function not implemented" ... wonder what that's about
<fabbione> mdz: unlikely if you don't have the debconf db cached in memory
<ogra> damned ... so lets talk it through after release
<infinity> mdz: That's cause the last publisher run crashed.
<mdz> infinity: does cprov know that?
<infinity> mdz: It's a bug we've seen before, but we can poke him to look at the log.
<infinity> mdz: For now, I'm going to disable the cronjob and re-run by hand.
<mdz> infinity: ok
<Keybuk> mdz: ok, this is odd; a fresh boot doesn't have /rofs on the front
<Keybuk> something must have done updatedb
<mdz> Keybuk: ->Mithrandir then
<Keybuk> why do we run updatedb twice in cron.daily?
<infinity> mdz: Oh, FFS.  Now the thing's stuck.
<bddebian> w00t
<Keybuk> dholbach: why does gdm stop _not_ in the live cd?
<dholbach> Keybuk: mh?
<dholbach> Keybuk: what do you mean?
<Keybuk> dholbach: if you boot live, C-A-F1 then do sudo /etc/init.d/gdm stop ... it doesn't
* dholbach tries
<Keybuk> kdm does :)  except it throws up usplash
<Keybuk> Riddell: known?
<Riddell> Keybuk: yes
<dholbach> Keybuk: hum, dunno if the funny messages in .xsession-errors say something
<dholbach> Keybuk: do you have some gdkpixbuf-critical gnome-panel messages too?
<Keybuk> meh, I've turned it off now
<Keybuk> I'll look in a bit again
<dholbach> ok
<Keybuk> right now, I'm hungry and going slightly insane, so am going to leave the computer alone for an hour ;)
<infinity> mdz: Oh wow.  A couple days after NVIDIA decided to fix their most ugly bugs, ATI went and did the same.  New fglrx just got released, fixing the "crash when switching consoles" and "doesn't effin' work with 512MB video adapters" bugs, among others.
<infinity> mdz: Will we be pushing new binary love in -updates?
<dholbach> Keybuk: my /var/log/Xorg.0.log says somethin about "Ok, leaving now..."
<fabbione> i suggest to do it now
<mdz> infinity: sure, why not
<fabbione> they are binary blobs
<mdz> infinity: add it to the relevant section on DRR
<fabbione> and they will be on CD
<Keybuk> mdz: oh, is there any particular hardware you'd like me to bring to London?
<mdz> Keybuk: amd64 and powerpc
<Keybuk> ok, I'll see if I can bribe my boyfriend to giving me a lift to London
<mdz> the amd64 laptop I used for beta has been...."repurposed"
<Keybuk> the amd64 is a *tad* heavy
<Keybuk> will you be in the office on monday?
<mdz> actually this huge server might be an amd64
* bddebian may have to buy and amd64 and PPC for Dapper+1
<mdz> Keybuk: I may be in the office *until* monday at this rate
<infinity> mdz: FWIW, I'm inclined to agree with fabbione that one blob is the same as the next, and we should just push 'em on the CD before release.  But the question was also "will we keep updating them?"
<mdz> Keybuk: ah, it is an amd64
<Keybuk> mdz: I trust you know all the nearby 24hr eating places?
<mdz> Keybuk: there are like 3 in London
<mdz> none that I would classify as 'nearby'
<Keybuk> ah, I suppose you do have dietary constraints
<mdz> like "I'm hungry at 3am"?
<garba> good evening anybody knows if and when emblems in nautilus will be fixed?
<Keybuk> garba: July
<garba> with gnome 2.14.2?
<tseng> garba: #ubuntu
<mdz> with Windows Vista
<ogra> haha
<bddebian> hehe
<garba> :) funny
<Keybuk> mdz: http://www.wcities.com/en/cat/121/1/category.html
<garba> well i was just wondering if there's some cvs patch somewhere that's why im asking here in the dev channel
<Kamion> janimo: dunno why it'd be trying to get installed; if you put the syslog somewhere I can figure it out
<mdz> Keybuk: "Late/24-Hour"
<Kamion> mdz: I had a post-rc section under bugs already; you can move stuff down from that if you like
<ogra> garba, see topic, we prepare a release candidate atm ...
<Keybuk> mdz: several of those are 24hr
<mdz> Vingt Quatre is legitimately 24-hour, i've been htere
<Keybuk> a few down the fulham road are
<Kamion> Riddell: yes, we'll be rebuilding once all the stuff is through the publisher
<Kamion> mdz: we so should have had a BreezyReleaseRadar, and then we'd have been talking about BRR
<Kamion> o/~ I got chills, they're multiplying o/~
<ogra> heh
<bddebian> uhm
<Keybuk> Kamion: I'm looking forwards to the EdgyReleaseRadar
<infinity> Kamion: You're losing your mind again.
<ogra> haha
<Kamion> Keybuk: will be very appropriate, considering the release mandate
<Kamion> "err, yeah, whatever"
<infinity> Kamion: There's another week of this to go, you can't go completely nuts yet.
<ogra> stop making me spill my coffe over the whie ibook
<Keybuk> Kamion: I'm still seriously considering suggesting we don't have a UVF for edgy, and just stick everything in until the last minute <g>
<Kamion> instead of "rigid and boring", I propose "flaccid and eyebrow-raising"
<bddebian> Keybuk: I like it! :-)
<ogra> yeah
<Kamion> Riddell: have you sorted out the Kubuntu alternate CD overflow?
<janimo> Gloubiboulga: saw what Kamion said wrt ltsp?can you get the log?thanks
<Riddell> Kamion: I don't see an overflow
<mdz> infinity: I eyeballed the pending builds and I don't see anything there which goes on the CD
<Kamion> Riddell: check report.html, it's unfortunately kinda hidden
<Keybuk> Riddell: ppc kubuntu is kinda missing language-support-en :)
<Kamion> I imagine it just needs a language-pack-ectomy
<Kamion> (in ship)
<infinity> mdz: So, after this publisher run (which is getting us ubiquity and some -meta stuff), you want to just call it gold, and start rolling new candidates?
<Kamion> which fortunately does not require a new upload
<infinity> mdz: We'll miss OOo, due to... Whatever's going on with rosetta, but otherwise looking good.
<Gloubiboulga> Kamion, I've not seen what you wrote about ltsp, which log file do you need, all?
<Riddell> Kamion: has the build process changed to block overflows then?
<Kamion> Riddell: I'll explain later, but it's been like this for quite a long time
<Riddell> Kamion: any way to find out how much it's overflowed?
<Kamion> certain types of overflows don't show up properly; I consider it a cdimage bug
<Kamion> Riddell: yes, check the CD build log on http://people.ubuntu.com/~cjwatson/cd-build-logs/ and look for "CD 2"
<Kamion> Riddell: (ignore the "CD 2" that shows up while building source CDs; that one doesn't matter)
<ogra> better for "CD 2 will only"
<ogra> else you jump through all the source stuff
<Kamion> thanks ogra, yes
* ogra does it thrice a day currently ...
* highvoltage just read that completely out of context
<LaserJock> :)
<Riddell> CD 2 will only be filled with 68259614 bytes  so I'm 68 megs over?
<ogra> looks like
<Kamion> yes
<ogra> Riddell, http://people.ubuntu.com/~pitti/langpacks/langpacksize.txt kind of helpful
<Kamion> although that may be slightly off due to however far CD 1 was from the actual limit
<Kamion> 68259614 - (736051200 - size-of-CD-1)
<Riddell> I guess all language packs up to sv is quit optimistic
<Riddell> quite
<Kamion> yeah :)
<ogra> heh, yes
<Kamion> although it's not all up to sv, you have all up to ms (I think) and then sv
<Kamion> my god that's a lot of binaries to new
* Kamion will deal with the apt-get.org-induced ones
* ogra looks for another towel to pick up all the coffee from the ibook ... i'll never buy a white laptop again 
<mdke> ogra: coffee is generally bad for even coffee coloured laptops :)
<infinity> Don't discourage the boy.  And excuse to not buy Apple products is a good one, no matter how flimsy the logic.
<ogra> mdke, yeah, i'll get an outdoor lappie next time ...
<infinity> s/And/Any/
<mdke> infinity: good point
<ogra> infinity, i have it only for ppc testing and its the handy small one i have 
<ogra> its easier to carry around ... if i had the choice back then i'd have bought an ibm
<infinity> Well, I still want a quad-core G5, but I think that's just some sort of penis size thing.
<ogra> heh
<ogra> get a porsche ;) heals everything
<mdke> i have a question about release numbers. We're making a website for documentation, and we have a tab for each release (5.10, 6.06 etc). We'd like to leave out the "LTS" from the 6.06 tab, is there some kind of official logic that means we should do one or the other?
<infinity> mdke: mdz may override this, but from how we're using numbers elsewhere, I think "6.06" when it's JUST a number, and "Ubuntu 6.06 LTS" when it's a product name.
<mdke> infinity: it's basically just a number - a test page is http://help.ubuntu.com/5.10/
<infinity> That seems to make sense and be consistent with how other things (like launchpad and LSB) display the info.
<mdke> infinity: so scrapping the LTS from the top right tabs would be reasonable?
<infinity> Well, it also allows for more tabs, so I can see the design argument for it. :)
<mdke> yeah, it will help for 60.06
<ogra> heh
<infinity> I'm hardly the final word on it, but I like "LTS" when used as a product name for marketing purposes.
<mdke> ok, thanks
<infinity> For pure versioning, "5.04, 5.10, 6.06, 6.10" is much easier to parse without throwing a random LTS in the mix.
<mdke> yeah, it looks rather odd
* ogra doesnt ... but thats kind of based on the fact he buiulds a product containing ltsp ... lts seems kind of incomplete
<mdke> haha
<mdz> infinity: in that context, I'd keep the LTS
<mdz> mdke: ^^
<infinity> mdz: Kay.  Your call.
<mdke> ah.
<mdz> especially when listing a sequence of versions, since then it's clear which are long-term releases
<infinity> Okay, that argument makes some sense.
<Kamion> in directory names I think bare 6.06 is OK
<mdke> mdz: do you think the reader will get a bit confused by the random letters?
<mdke> probly not, I guess it's on his install cd
<mdz> when we're looking back over 10 releases it'll be handy to see at a glance which ones are still relevant;-)
<infinity> mdke: Not if each LTS page explains what LTS means. :)
<Kamion> use <abbr>
<infinity> mdke: Or even just the mouseover on the tab itself could say "Long Term Support"
<mdke> infinity: I'm not that keen to get into mouseovers... but I'm sure we'll figure something out
<mdke> thanks mdz
<Kamion> <abbr title="Long-Term Support">LTS</abbr>
<infinity> mdz: So, does that mean we're pretty convinced that we'll stick with this nomenclature for the forseeable future?  (ie: at least long enough to get one more LTS release out)
<Kamion> if moin supports that
<mdz> Kamion: I can reproduce infinity's loop with two disks in vmware
<Kamion> mdz: right, that'll give me something to look at
<mdke> Kamion: it's not only moin, lots are static pages, and pages built from docbook. But I will investigate that. it should work
<Kamion> mdz: want me to start looking at it straight away, in the event that we have to re-roll for something else?
<infinity> mdz: Ahh, great.  Nice to know I don't have such completely insane hardware that I'd have to "just cope". :)
<mdz> infinity: you're asking me to predict something which is farther in the future than Ubuntu goes into the past ;-)
<bddebian> heh
<infinity> Kamion: I can handle the rolling of images and such, if that'll free you up to keep attacking ubiquity.
<mdz> Kamion: worth a look to see how invasive the fix will be
<infinity> mdz: Be a visionary, man!
<Kamion> mdz,sfllaw: applying a dose of realism, I don't think I'm going to get my testing/current stuff done - it was only netboot and upgrades anyway
<ogra> mdz, he just wants to test your confidence :)
<Kamion> I haven't even got as far down as the "merely very urgent and extremely important" work today
<bddebian> ogra: :-)
<infinity> mdz: Publisher's all done.  Shall we start on new livefses for everyone and all that?
<ogra> infinity, yes (for edubuntu at least)
<mdz> infinity: yes please
<mdz> infinity: confirmed that oo.o and ubiquity made it?
<infinity> mdz: No OOo.  That's what was hanging the publisher.  malcc and cprov investigating.
<infinity> mdz: Do we want to wait for it, or just leave it behind?
<infinity> mdz: ubiquity's definitely in, though.
<sfllaw> Kamion: :(
<sfllaw> Kamion: Thanks for telling me.
<_ion> If i recorded a version of http://johan.kiviniemi.name/music/ion-schizophrenia-prev1.ogg with a band (singer, piano, drums, bass, guitar) during this week, would it be considered for inclusion to the example-content package?
<ploum> is there a list of accepted Ubuntu SoC somewhere ? (I'm just curious)
<mdz> infinity: argh
<mdz> infinity: ok
<mdz> infinity: go ahead with it
<sfllaw> Kamion: Could you try to find someone else with a PPC machine?
<Riddell> Kamion: is it possible to do kubuntu installs with netboot now?
<Kamion> Riddell: if you know the runes, it always has been
<Kamion> let me dig them up
<Riddell> _ion: I'm afraid not
<infinity> mdz: Hrm.  The soyuz guys claim it "might work" now...
<_ion> riddell: Ok.
<ogra> sfllaw, i can do some ubuntu ppc testing tomorrow, but tonight i'm completely demoted to edubuntu and i have no ubuntu isos here yet 
<Kamion> Riddell: actually, just preseed/url=http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/data/dapper/preseed/kubuntu/kubuntu.seed should do it
<Kamion> (yay bzr side-effects)
<Riddell> Kamion: I'll give it a shot
<Riddell> rsyncing these full ISO images is going slow
<Kamion> Riddell: thanks, that would cover the netboot case pretty well
<sfllaw> ogra: Thanks!
<Kamion> if it works
<Kamion> sfllaw: I can do some between RC and release, I just seem snowed under until RC
<sfllaw> Kamion: Thanks.
<infinity> mdz: Looks like this fresh publisher run didn't hiccup in that spot.  So, OOo will be ready for i386 in ~20 mins.
<mdz> infinity: sweet!
<infinity> mdz: I started livefs builds on all other arches, we can hold off on i386 until it's ready.
<infinity> Does kubuntu ship openoffice?
<infinity> If not, I can build that one now.
<Kamion> infinity: it does
<infinity> Oh, dang.
<infinity> edubuntu?
<ogra> yep
<infinity> Bah.  Screw you all. :)
<mdz> I don't think xubuntu does
<mdz> well, not in the livefs
<Kamion> xubuntu has it in ship, not desktop
<infinity> Yeah, but are we building/testing xubuntu images right now?
<mdz> only if janimo is around ;-)
<infinity> Right, I'll just twiddle my i386 thumbs then.
<Riddell> infinity: yes
<infinity> Kamion: Hrm.  Is it intentional that you haven't disabled lithium's crontab?
<Kamion> infinity: hadn't quite seemed necessary yet - but I've disabled it now
<infinity> Heh.  Kay. :)
<omeg> Huh.
<omeg> I made a wikipage earlier and now it's gone.
<infinity> wiki gremlins.
<omeg> I guess it was deleted for not being structured in the way wikipages usually are. I want to restructure the art team's page.
<bddebian> infinity is in rare form today :-)
<omeg> He's probably all fired up for release.
<omeg> Committed to working non-stop until June 1st.
<bddebian> heh
<bddebian> Heya zul
<infinity> mdz: The more I look at the release announcements for both nvidia-glx and fglrx, the more I think we should do them post-RC, not post-final... They claim to fix some of the more hideous outstanding bugs we have, and if they still work on a few machines, that's really all we can ever hope for anyway.
<infinity> mdz: ATI even claims to now "officially support Xorg 7.0", whatever that's meant to mean.
<Kamion> infinity: http://librarian.launchpad.net/2906199/buildlog_ubuntu-dapper-hppa.wormux_0.7-1_FAILEDTOBUILD.txt.gz <-- what's that segfault?
<zul> hey bddebian 
<infinity> Kamion: hppa kernel b0rkage, probably.  <looking>
<infinity> Kamion: Yup.  Giving back.  Thanks.
<Kamion> infinity: want me to keep flagging those, or will you mass-process them?
<infinity> Kamion: If you have a list, sure.  Elsewise, I'll just mass-give-back on hppa as soon as RC is out the door.
<Kamion> I don't, I'm just going through NEW and checking in cases where there aren't ready-made batches of 6
<infinity> If you have more, feel free to point 'em out.
<infinity> I go through hppa's failed list from time to time to try to avoid mass-give-backs, but I miss some here and there.
<bddebian> Hmm, what can I throw up just to keep you guys busy? ;-P
<mdz> infinity: happy to consider it; let's review when the dust settles
<infinity> mdz: Kay.  I'll prepare them tomorrow and test locally on the nvidia and ati hardware I have here, and if that looks good, tap your shoulder for consideration.
<Riddell> Kamion: I updated the ship seed for language pack size
<Kamion> Riddell: thanks
<Kamion> infinity: I'm good to build alternate images, right?
<Kamion> if so, I'll kick off Kubuntu so that we can check the size fix
<infinity> Kamion: Only if we don't want OOo on them....
<ogra> Kamion, ooo
<infinity> Kamion: I was waiting for the publisher to finish.
<Kamion> right; one more publisher run then?
<Kamion> let me know when
<infinity> Kamion: Just built fresh -server images, since those are the only ones with OOo. :)
<infinity> s/with/without/
<Kamion> heh
<janimo> mdz, I am around
<infinity> Go, apt-ftparchive, go!
<janimo> there's a ltsp problem with the xubuntu install iso thiugh
<mdz> mvo: is it known that update-notifier pops up during an update-manager dist-upgrade?
<mdz> janimo: what's the problem?
<janimo> mdz, ltsp packages are not in the install or deskto seed, but it tries to get installed nonetheless
<janimo> ltsp packagea are in ship though
<ogra> janimo, i thought you mande a special seed file for it
<ogra> janimo, if you still run ltsp-client-builder it will try to 
<janimo> ogra, nope, it is to be done (if done for dapper) by a special cd image parameter since there are only 5 packages which I understood are not worth making a new seed for
<janimo> ogra, client builder is in ship so it should not run
<janimo> I moved it over when I got the errors last time
<ogra> drop client builder... its only usefule in the installer 
<janimo> so no idea what it is really.And I updated the xubuntu-desktop too since
<ogra> there is no value for having it in ship ...
<ogra> (its three commands to set up ltsp post install ...)
<janimo> ogra, ok did not know that.The rest of lstp packages are to be in ship or in that special seed if it existed?
<Loevborg> (I hope you don't find this inapropriate) Does anyone know if there's a Ubuntu developer located in Munich or not far away?
<janimo> if the latter I'll just remove them from the seeds allgether
<ogra> s/them/ltsp-client-builder.udeb/
<ogra> keep ltsp-server, ltsp-server-standalone, ltsp-client and ldm in ship
<mdz> only 7 pending builds, all sparc
<Loevborg> I'm asking because a journalist friend of mind is looking to have an interview because of the upcoming release.
<infinity> mdz: Publisher run done, firing up i386 builds.
<infinity> Kamion: If you want to do alternate builds, go nuts.
<Kamion> kubuntu alternate building
<janimo> Kamion, bug 46426
<Ubugtu> Malone bug 46426 in debian-installer "Xubuntu install CD install ltsp" [Normal,Unconfirmed]  http://launchpad.net/bugs/46426
<mdz> infinity: woo
<janimo> it has the xubuntu syslog which has ltsp package mentioned in it
<ogra> janimo, not helpful ... for ltsp debugging the messages file is needed
<Kamion> ogra: rubbish
<ogra> (i should rename it to ltsp.log or something in eft)
<janimo> ogra, not ltsp needs to be debugged, but why it is to be installed in the first place :)
<mdz> Kamion: is there an update-manager upload waiting in the queue for breezy-updates? if so, please process it
<Kamion> you don't need to debug ltsp itself, only why it's being installed
<ogra> Kamion, oh, right
<ogra> sorry
<janimo> infinity: nothing is holding up xubuntu desktop CD, whenever you get around it is ok
<infinity> janimo: I'll sping your livefses after the others complete.
<infinity> s/sping/spin/
<infinity> Why do my fingers always add a "g" to the end of that?
<infinity> Bizarre.
<dholbach> infinity: because of "ping"?
<mdz> infinity: from typing 'ping' 80 times per day for your entire life
<infinity> dholbach: That may be it.
<dholbach> mdz: I'd love to see update-manager tarball download stats for the last days - your idea of writing a blog entry was a good one.
<mdz> the same reason I can't type the word 'launched' anymore
<Kamion> oh, damn, ltsp-client-builder is still Priority: standard
<Kamion> I noticed that after breezy and obviously totally forgot to fix it
<infinity> mdz: You should have seen the trouble I had typing "apt-key".. It always came out as "apt-get^H^H^Hkey"...
<infinity> Kamion: Was that "the thing that we couldn't fix in the archive without breaking somehting for someone somehow"?
<ogra> Kamion, should that be optional ? 
<Kamion> infinity: we couldn't fix it in breezy, but it would just take a cdimage tweak to fix it in dapper
<Kamion> ogra: needs a cdimage tweak and a bit of testing
<infinity> Kamion: Right, "couldn't fix for breezy", I meant.
<ogra> Kamion, ok, i thought i could change it quickly since my install isos are RC ready an additional ltsp upload wouldnt do any harm to me ...
<mdz> Kamion: how did it end up priority: standard in the first place?
<infinity> ogra: Uploads aren't required to change priorities.
<infinity> ogra: That's why the archive has overrides.
<Kamion> mdz: it needs to be in order to work in edubuntu at preset
<mdz> infinity: and the .deb itself is priority: optional anyway
<Kamion> present
<Kamion> it won't be sucked into the installer otherwise
<ogra> infinity, oh i thought thats about the debian/control entry
<Kamion> what IIRC we need to do is to use anna/choose-modules in the edubuntu preseed file
<Kamion> but I need to check that
<Kamion> mdz: update-manager/breezy accepted
<mdz> Kamion: thanks
<mdz> I'll confirm the version number fix shortly
<mdz> that is, once it's published...doh
<Kamion> ogra: which edubuntu boot options are meant to run ltsp-client-builder?
<Kamion> ogra: I suspect that at present they all do
<ogra> only the default
<ogra> workstation definately doesnt
<ogra> so you solved it already somehow :)
<Kamion> oh, we preseed ltsp-client-builder/run=false for workstation
<Kamion> yeah, kind of the wrong way round though
<ogra> but a workaround fro xubuntu probably ...
<Kamion> in general stuff works best if all installer packages behave in the Ubuntu-default way by default
<Kamion> it would be, yes, but I want to fix this in dapper
<ogra> ok
<Kamion> rather than forgetting about it for another release :)
<Kamion> because it breaks Ubuntu netboot
<Kamion> i.e. Ubuntu netboot installs of breezy and (current) dapper run ltsp-client-builder
<ogra> ugh
* ogra didnt know
<mdz> Kamion: eek
<Kamion> we could change the ltsp-client-builder default, but I think it's neater to drop its priority
<Kamion> mdz: I noticed when we were doing soyuz acceptance tests
<Kamion> it was one of my "it does WHAT? oh, hang on, it does that with katie too ..." moment
<Kamion> s
<Kamion> hmm, preseed/file is not usable for anna preseeding. this will be a little more complicated.
<astronut> i don't want to disable folding completely, just for changelogs
<astronut> err, wrong line
<Kamion> mdz: I will need to upload ltsp-client-builder after all, so how about I upload it but let it sit until after RC?
<astronut> how do you disable changelog folding in the new vim?
<dholbach> Good night fellas.
<Kamion> I'll have to change the default for ltsp-client-builder/run; it's the only sane approach I can think of
<infinity> Kamion: Which images have you built?  Just kubuntu alternate?
<Kamion> infinity: yes; I'll keep going
<Kamion> Ubuntu alternate building
<infinity> Kamion: Kay, cool.
<infinity> Kamion: I'll start in with livecd builds in parallel as the livefses become ready.
<ogra> Kamion, bzr: http://people.ubuntu.com/~ogra/bzr-archive/ltsp/dapper/
<Kamion> ogra: thanks
<infinity> ubuntu daily-live running.
<mvo> Kamion: I just got a strange message during netinst. the partioner said it was unable to create the pations, I just created a new reiserfs parition. do you want me to copy the log? or throw it away and try again to see if I can reproduce it?
<Kamion> mvo: please always save logs from strangeness
<mdz> Kamion: fine with me
<mdz> Kamion: do you want debug and partman logs from the 2-disk loop?
<Kamion> mdz: no, it's OK, I've reproduced that
<mdz> ok
<mdz> what is irssi doing in desktop, and how did I not notice until now?
<ogra> mdz, was always there ? 
<infinity> mdz: It's been there forever.
<mdke> it's a replacement for xchat-gnome
<ogra> haha
<ogra> mdke, what replaces gaim then on the console ? 
<mdke> ogra: god knows
<mvo> haha
<infinity> centericq, but I'll be damned if I'll support that.
<ogra> telnet ? 
<mdke> has anyone running a localised desktop got a few minutes to test something for me?
<mdke> *few seconds
<Kamion> ogra: ok, if you could merge http://people.ubuntu.com/~cjwatson/bzr/ltsp/installer-fix/, I'd appreciate it, thanks; I've deployed the change to cdimage that makes Edubuntu keep on working despite that
<Kamion> or I can upload it myself if you prefer
<mdz> ogra,infinity: that doesn't answer *either* of my questions :-P
<ogra> Kamion, i'll do it, youre busy enough nowadays, thanks
<thom> ogra: bitlbee, clearly
<infinity> mdz: It's probably cruft from back when "ubuntu-desktop" meant "install everything that the Ubuntu devs have on their machines and use every day"
<bddebian> heh
<infinity> mdz: It should probably go, since people who want it will know what it's called and how to get it.
<thom> it went in for the same reason mutt did, iirc
<thom> to enable console users to have a sane experience
<Kamion> ogra: cheers, appreciate it
* thom attempts to dredge up the remaining memories of the room of death in brazil
<infinity> mdz: I could see an argument that it would be useful to get support on IRC if your X is broken... But OTOH, same thing.  If you don't know what it is, you'll never discover it and run it.  If yo udo know what it is, you can install it.
<mdz> infinity,Mithrandir: aaarrgghh
<mdz> oo.o Impress and Calc are both named "Spreadsheet" now
<infinity> ...
<mdz> so we get to do this dance again after RC
<ogra> ouch
<Kamion> ogra: oh, you could close bug 46426 in that changelog too
<infinity> So close...
<Ubugtu> Malone bug 46426 in ltsp "Xubuntu install CD install ltsp" [Normal,Unconfirmed]  http://launchpad.net/bugs/46426
<ogra> Kamion, will do :)
<infinity> mdz: I'll be sure to convey your "aaarrgghh" to Mithrandir when he wakes up.
<mdke> infinity: out of curiosity, are these openoffice changes requiring fresh translation?
<infinity> mdke: Requiring?  No.  The old strings will suffice.  But people offering new translations for the .desktop files between now and... Uhh... 24 hours from now won't be turned down.
<infinity> .desktop files don't fuzz, so it's not critical.
<mdke> infinity: oh, I thought that was all in rosetta nowadays
<mdke> oh, so old strings aren't lost, np
<Kamion> janimo: could you move ltsp-client-builder from your ship seed to your installer seed? it doesn't make a practical difference, but it makes more sense to keep all the udebs in installer
<janimo> Kamion: will do. So it won;t install in default mode right?
<janimo> and is it feasible to add a ltsp-specific boot menu entry to the CD after RC?
<Kamion> janimo: it will for the RC, but the fix that ogra has in hand now will make it not do that for release
<ogra> only if you preseed ltsp-client-builder/run=true
<Kamion> janimo: yes, certainly, sorry I haven't got round to it today
<janimo> np
<Kamion> ogra: the boot menu entry can be attached to a preseed file that does that, yes
<ogra> thats cool
<ogra> i sometimes get requests from people wanting to build derivatives ...
<ogra> (with ltsp setup)
<janimo> ogra, is openssh-server helpful to have in seed to for ltsp?
<ogra> s/helpful/essential ;)
<janimo> ok, then I leave it there :)
<ogra> our setup requires it (even you *could* set up our ltsp to use xdmcp, but who wants that :) )
<janimo> I got the impression last time if was not strictly required
<ogra> its only suggested by ltsp-server 
<ogra> but thats because you *could* use ltsp differently
<ogra> i tend to agree it should be a dependency, but mdz had some valid arguments against making it a hard dep iirc
<ogra> (setting it up for xdmcp would at least require to drop ldm and install gdm manually as well as other manual fiddling)
<infinity> Kamion: If you want to spin alternates for edubuntu and xubuntu too, I'm covering all the -server (done) and -desktop (half done, pending FS builds) bases.
<crimsun> Applications> Office  lists "OpenOffice.Org Spreadsheet" twice (the second should be Impress's)
<infinity> crimsun: We know. :/
<crimsun> (sorry, just updated )
<Keybuk> I think my eyes are going weird
<Keybuk> I can't tell which way up this CDR is supposed to go
<ogra> wow
<infinity> Kamion: Actually, nevermind, I'll do all the pending alternate builds too.
<ogra> Kamion, does UNRELEASED in the debian/changelog file come from your vim ? 
<ogra> or is bzr doing such stuff now ? 
<infinity> ogra: From him.
<ogra> ah
<infinity> ogra: Unless he has some fancy changelog mode that does it for him.
<infinity> (It's standard Debian fare for "This is a CVS version, if I accidentally upload it, katie will reject it")
<ogra> ah
<ogra> i've never seen it before
<Keybuk> infinity: semi-standard
<Keybuk> given dch, vim and emacs all do it differently
<ogra> but then i always use dch -i
<infinity> Keybuk: Anything with more than 5 users in Debian is "standard" :)
<Keybuk> fair point
<Keybuk>        Two different sets of heuristics can be  used,  as  controlled  by  the
<Keybuk>        --release-heuristic  option or the DEBCHANGE_RELEASE_HEURISTIC configu
<Keybuk>        ration variable. 
<thom> is the corollary to that that anything Keybuk uses is non-standard?
<Keybuk> thom: I set the NEW standards!
<thom> new standards in massacring my terminal, maybe
<Keybuk> how did I massacre your terminal?
<infinity> The long dash.
<thom> whatever that was in "DEBCHANGE_RELEASE_HEURISTIC configu..."
<infinity> Came out here as an inverted @P
<Keybuk> heh
<Keybuk> you can blame Kamion for that one
<Keybuk> it came out of groff
<thom> ah, utf-8 hyphen?
<Keybuk> must be
<Keybuk> U+2010 HYPHEN
<Keybuk> yeah
<Keybuk> so this "new standard" to "massacre your terminal" would appear to be UTF-8
<Keybuk> I keep forgetting how far behind FreeBSD is ;)
<thom> yeah yeah
<thom> i've not figured out what part of the unholy freebsd/screen/irssi trinity is responsible
<Keybuk> "thom"
<thom> hush.
<thom> :P
<sfllaw> thom: It's definitely not screen or irssi.  That works fine here.  It's probably something in your terminal and lower.
<Keybuk> ogra: btw, your splash screen looks the best
<sfllaw> s/and/or/
<ogra> Keybuk, usplash or gnome ? 
<Keybuk> gnome
<Keybuk> the usplash one looks like someone weed on it
<ogra> heh
<ogra> Keybuk, look at the alternate wallpaper ;) its cool
<thom> sfllaw: mmm, it works occasionally and then with the same terminal doesn't work at others, so i'm not so sure
<Keybuk> ogra: the Edubuntu Young one?
<ogra> Keybuk, yeah
<Keybuk> it is cool
<ogra> we have a JaneW from the same artist http://www.progbox.co.uk/jane.jpg
<Keybuk> I shall recommend Edubuntu to all my paedophile friends ;)
<Keybuk> heh, did he do you too?
<ogra> only the former version, it had the edubuntu girl
<ogra> nope, not yet, and its a she :)
<Keybuk> now, why do we not have this icon theme on the real distro?
<ogra> gartoon ? 
<ogra> no idea
<Keybuk> and how did you manage to get an entire icon set designed, when ubuntu can't manage a single icon?
<ogra> it was already there ;)
<Keybuk> ah, cheating
<Burgwork> Keybuk, I believe gartoon is jimmacs work
<ogra> nope
<ogra> Burgwork, a guy from nl calling himself zeus did it
<ogra> http://zeus.qballcow.nl/icons.php
<Burgwork> ogra, hmm, indeed. jimmac did gorilla
<ogra> yep
<bddebian> Later folks
<ogra> hmm, while looking at his page ... i should look at his blankon theme for edgy looks nice
<Keybuk> I have a nasty thought what may have run cron
<Keybuk> I think the first time I ran the installer, it thought the time zone was New York
<Keybuk> when I changed it to London, I wonder whether that instantly applied the time change
<Keybuk> no, it doesn't appear to
<Kamion> ogra: as it happened I did it by hand, but that's only because my 'uch' alias overrides dch's defaults
<infinity> Kamion: Still around/alive?
<infinity> Oh, so you are.  TIMING.
<infinity> Kamion: I'm doing the alternate builds along with the live builds, so you're off the hook there... BUT...
<Mirv> thom: at least you should have screen -U, irssi v. 0.8.10 and term_charset to UTF-8 (same for your terminal program).. at least in that case irssi wouldn't be the problem, old/buggy screen or old/buggy terminal could be
<ogra> Kamion, i was just wondering, bever saw that anywhere
<infinity> Kamion: Something seriously odd seems to have happened to the kubuntu builds.
<Kamion> infinity: er - don't please?
<ogra> Kamion, uploaded to the queue btw
<thom> Mirv: aye
<mantas_> hi all, maybe someone could tell me how many hours is left for uploading fixed translations to ubuntu dapper ?
<Kamion> infinity: ?
<Kamion> mantas_: none
<infinity> Kamion: Err, don't why?
<Kamion> infinity: don't build xubuntu - I want to install a workaround for the ltsp thing
<infinity> Kamion: Oh.  A bit late, but it can build again. :/
<infinity> Kamion: Your kubuntu build, however, looks... Not happy.
<infinity> Kamion: http://cdimage.ubuntu.com/kubuntu/daily/20060524.1/
<Riddell> looks ok to me
<Keybuk> sfllaw: I'm quite happy doing much ppc testing, though mine is probably the slowest in existance, so it takes a while
<sfllaw> Keybuk: Thanks!
<ogra> Riddell, report.html
<infinity> Riddell: Which part of "there's nothing in that directory" looks okay to you? :)
<Kamion> it's still oversized
<Kamion> infinity: you must have caught it mid-mirroring
<ogra> infinity, its there, youre to fast
<ogra> :)
<mantas_> Kamion, but in release roadmap deadline is 25 may, not 24
* infinity scratches his head.
<infinity> Ctrl-R really should resolve that..
<infinity> Maybe the mirror I'm stuck on is unhappy.
<ogra> infinity, i get caught by it very often dont worry youre not alone :)
<Kamion> mantas_: for language packs, yes
<infinity> ogra: Fair enough. :)
<Kamion> mantas_: you said "upload" which I thought meant some other package
<Kamion> i.e. non-langpack
<mantas_> Kamion, no, I'm about uploading fixed .po files into rosseta ;)
<Kamion> mantas_: for langpacks, I don't believe we have set a precise number of hours.
<Kamion> mantas_: and in any event langpack changes can and will happen after release too
<mantas_> Kamion, so, aproximatly when ubuntu team will build last langpack for ubuntu dapper final version ?
<Kamion> Riddell: looks like you're 12+, 14+, 25+ MB oversized
<Kamion> mantas_: the person responsible for that (pitti) is not here
<Kamion> so we cannot ask him
<ogra> and its a public holiday tomorrow here, i guess he wont be around wither
<ogra> *either
<mdz> is anyone else getting a BADSIG on the current dapper Release?
<sfllaw> So apparently doko is ill.  Can anyone take over his Alternative CD testing for i386?
<infinity> Kamion: Okay, my premature xubuntu-daily build is done (along with edubuntu-daily)... Sorry about that.  The floor is yours.
<mantas_> ok, as I understand I still have at least 12 hours for uploading fixed translations and pitti will build langpacks from these translations after holiday :)
<infinity> Kamion: I'll just polish off the livecd builds.
<Keybuk> mdz: I didn't a few minutes ago
<mdz> Mark and I both did just now
<Kamion> infinity: oh, hmm, we want sparc on releases for RC
<Keybuk> mdz: elmo's cache of love could have burped?
<Kamion> infinity: so it might be helpful if I could arrange for that to land in the right daily directories
<Keybuk> mdz: seems ok here
<mdz> that cache has been giving me a lot of love lately
<mdz> I've never seen it fuck up apt before
<infinity> Kamion: Yeah, I've built all of the ports stuff too.
<Kamion> infinity: sorry, I should have done this before this round of builds
<infinity> Kamion: We can just twiddle them by hand for now, I figures. :/
<Keybuk> mdz: could have grabbed an empty file?
<Kamion> infinity: yeah, but it's in the wrong directories which will make publishing inconvenient
<infinity> s/figures/figured/
<ogra> infinity, oh, edubuntu install wasnt really necessary, was it ? 
<infinity> ogra: You uploaded new artwork.  I assumed you wanted it...
<ogra> that could have gone in after RC, but well, now its there :)
<Kamion> infinity: oh, hang on, it's only for ubuntu-server
<Kamion> infinity: so I only need to rebuild that
<infinity> Kamion: Which is, conveniently, the fastest build of the bunch.
<Kamion> mdz: could you confirm please, dapper-server-sparc on releases.u.c but not any other dapper-*-sparc?
<infinity> Kamion: That was what we discussed a day or two ago, yeah.
<infinity> Kamion: The LiveCD is broken on sparc, and Mark doesn't want to publish the alternate.
<Keybuk> I like how the GTK+ ubiquity doesn't let you click "Install" while it's installing
<mdz> Kamion: confirmed
<Kamion> Keybuk: er, that window should have gone away while it's installing
<Keybuk> Kamion: it does
<Keybuk> it _doesn't_ on the KDE one
<Kamion> unless you mean something different from what I think you mean
<Kamion> Keybuk: oh, yeah, the KDE frontend's window handling around there is very bad
<Keybuk> yeah, it lets you get ubi very confused
<Kamion> the main window is supposed to go away, and there's only supposed to be a single progress bar not several
<Keybuk> it amused me for 0.2s
<Keybuk> AHA!  I HAVE CAUGHT THE LIVE CD RUNNING CRON!
<Riddell> Keybuk: disappearing windows are confusing according to KDE's usability people
<Keybuk> Riddell: windows that let you click their buttons are more confusing, no? :)
<mdz> Keybuk: so fix it already :-P
<Riddell> I don't disagree there
<Keybuk> mdz: I'm trying to find out _how_
<Keybuk> it's anacron being run
<Keybuk> but, as you say, it's not run at boot
<mdz> Keybuk: rm -f /etc/rc?.d/S??cron
<Kamion> Riddell: surely a window that will never be used again but that sticks around anyway is more confusing
<Kamion> well, never used again except in error cases
<StevenK> chmod -x /usr/sbin/cron ? :-P
<mdz> removing the S links is the preferred approach; that's what casper does for everything else currently
<mdz> this is very trivial to fix
<mdz> though I have no idea why cron.daily is running for you, when it's clearly 2243
<Keybuk> it's not cron.daily
<Keybuk> it's even better
<Keybuk> it's cron.monthly
<Kamion> doesn't that run at 0652?
<mdz> but but but
<mdz> I didn't think anacron ran from cron.monthly, but apparently it does
<Keybuk> Kamion: yes, but anacron also runs these things at "about 15 minutes after you boot" if it hasn't happened for a while
<mdz> anacron is insidious
<Keybuk> I'm trying to find what triggers _that_
<Keybuk> mdz: part of my secret edgy desires that scare Kamion is to get rid of anacron
<Kamion> Keybuk: so anacron must be started at boot, surely?
<Keybuk> Kamion: yes, but casper takes care of that
<Kamion> even if it's just lying dormant
<Keybuk> oh, wow, anacron ran cron.daily, weekly AND monthly
<Keybuk> (just to be on the safe side)
<mdz> it runs from cron.daily at 0625, cron.weekly at 0647, cron.monthly at 0652 AND cron.d at 0730!
<mdz> Keybuk: none of which are even remotely close to now
<Keybuk> mdz: indeed
<mdz> Kamion: casper disables anacron's init script, always has
<Keybuk> and it's not the system clock being screwy either
<Kamion> mdz: right
<Keybuk> mdz: if you're logging in remotely and running anacron, you're getting a beating ;)
* mdz whistles innocently
<Kamion> mdz: I mean if it's running, it must have been started somehow ;-)
<Keybuk> *blink*
<mdz> good thing Mithrandir ported over my casper backdoor
<Keybuk> May 24 21:14:48 ubuntu anacron[5345] : Anacron 2.3 started on 2006-05-04
<Keybuk> May 24 21:14:48 ubuntu anacron[5345] : Will run job `cron.daily' in 5 min.
* Kamion might actually be worried if I didn't reckon I'd read all the casper code by now :)
<Keybuk> May 24 21:14:48 ubuntu anacron[5345] : Will run job `cron.weekly' in 10 min.
<Keybuk> May 24 21:14:48 ubuntu anacron[5345] : Will run job `cron.monthly' in 15 min.
<Keybuk> May 24 21:14:48 ubuntu anacron[5345] : Jobs will be executed sequentially
<Kamion> started on *what* date?
<mdz> ...
<Keybuk> Kamion: typo
<Kamion> oh good
<Keybuk> I had to type that ;)
<Keybuk> hmmmmmmmmm
<Keybuk> I have a thought
<mdz> Keybuk: do you have /etc/rc?.d/S*anacron or no?
<Keybuk> mdz: I do not
<Keybuk> Matthew Garrett may be about to lose his testicles
<mdz> !
<sfllaw> Hmm.  I wonder why I can't download any ISOs from http://cdimage.ubuntu.com/dvd/current/
<Keybuk> sfllaw: because Apache sucks
<sfllaw> wget reports "Connection closed at byte 0. Retrying"
<sfllaw> Oh.
<sfllaw> :(
<mdz> Keybuk: apm/event.d/anacron?
<Keybuk> mdz: this is what I'm thinking
<Kamion> Keybuk: let me guess, you put the power lead back in
<sfllaw> Keybuk: rsync isn't giving me much love either.
<Keybuk> Kamion: no, but the daemon started
<Keybuk> so "noticed" the power lead
<mdz> Keybuk: isn't invoke-rc.d smarter than that?
<Keybuk> sfllaw: rsync worked for me
<sfllaw> There we are.
<Riddell> sfllaw: ftp works
<Keybuk> mdz: yeah, like that stuff uses invoke-rc.d
<Kamion> mdz: not unless you have a policy-rc.d
<mdz> Keybuk: it does
<Kamion> Keybuk: it does
<mdz> Kamion: I thought it checked the current runlevel and futzed about with the symlinks
<mdz> seems PERFECTLY REASONABLE
<infinity> That IS what it does.
<Kamion> we should probably make casper create a policy-rc.d
<Kamion> in edgy
<mdz> infinity: in which case it ought to work...
<mdz> sfllaw: keep trying; Znarl said it was only one server in the rotation I think
<Kamion> hmm, the invoke-rc.d code does seem to check the symlinks though
<Keybuk> except apmd isn't started on PowerPC, is it?
<infinity> Yes, it's meant specifically to allow for runlevel futzing...
<ogra> sfllaw, btw cat-ing together live and install iso and rsyncing that gains you a small bit lees download time
<infinity> Oh, if it's PPC...
<mdz> ogra: it gains a lot in fact
<infinity> Keybuk: Anything fishy going on with pbbuttonsd, the increasingly poorly-named daemon?
<Keybuk> infinity: pbbuttonsd is the daemon that starts immediately before anacron in my syslog
<Keybuk> in fact, it's within a second
<Keybuk> which on this machine implies a connection
<Keybuk> given it takes a second just to do a write()
<mdz> aha
<ogra> mdz, well there is still a lot left to download
<Keybuk> oh, and look
<mdz> Keybuk: sounds like pbbuttonsd is eating your lunch
<Keybuk> yeah, pbbuttonsd issues a power event when it starts "because we're on AC power"
<infinity> And it doesn't use invoke-rc.d, I assume?
<ogra> i thought pitti disabled all PM functions in pbbuttonsd
<infinity> Naughty, naughty pbbuttonsd.
<Keybuk> pbbuttonsd just calls mjg59's apm stuff
<mdz> so invoke-rc.d sucks
<infinity> Oh.
<mdz> it is the only reasonable explanation
<Kamion> yes, this does feel like an invoke-rc.d bug, reading through the code and doing sh -x
<infinity> Testing the sucking of invoke-rc.d is easy to do.  sh -x /usr/sbin/invoke-rc.d anacron start 
<infinity> It really does seem to be written to do what it claims it's meant to do.  It'd be a shame if it doesn't actually work. :)
<Keybuk> aha!
<Keybuk> actually, invoke-rc.d is behaving correctly
<Keybuk> it's SysV that's fucked
<Keybuk> casper _removes_ the S* script
<Keybuk> it never replaces it with a K* script
<mdz> invoke-rc.d can go to hell
<Kamion> oh
<mdz> that's perfectly valid
<Kamion> no S*, no K* => undefined state
<Kamion> according to the sysvinit lot
<Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=156161
<Ubugtu> Debian bug 156161 in sysvinit "Subject: sysvinit: invoke-rc.d starts daemon when it shouldn't" [Normal,Open]  
<mdz> they suck
<Kamion> henrique says "put a K link in there"
<mdz> henrique can lick my testicles
<infinity> I'm inclined to agree with him, actually.
<Keybuk> ...it's been a long release
<lool> hmm
<infinity> Given hoe runlevels work, no symlink means "well, it can go either way.. HAVE FUN!"
<infinity> s/hoe/how/
<Kamion> right
* ogra eeeks about the last comment on bug 45536
<Ubugtu> Malone bug 45536 in gnome-power-manager "Shutdown, but logoff" [Normal,Unconfirmed]  http://launchpad.net/bugs/45536
<mdz> only for the special case of having an S link in runlevel S and none in the current runlevel
<Keybuk> mdz: or switching run levels
<infinity> Yeah, some people actually use more than 3 runlevels. :)
<Keybuk> switch from 2 to 3, without a K link, and it mayyyy be still running, etc.
<Kamion> yes, if you actually USE runlevels, then it matters
<Keybuk> oddly, I still do;  I have a runlevel 3 on my laptop that starts all the launchpad crap
<infinity> Anyhow, if you really want something to be off in 2, it should have a K.  hmh is right, though I'm sure he'll still lick your testicles.
<Keybuk> so I can do "init 3" if there's a chance Mark is going to look over my shoulder
<mdz> Keybuk: anyway it's still easy to fix
<Keybuk> yes, let's fix casper!
<infinity> ogra: edubuntu livecds are ready.
<mdz> apmd doesn't seem to be as stupid in this respect as pbbuttonsd
<ogra> infinity, thanks ! rsyncing
<mdz> or else acpid doesn't run the ampd hooks
<infinity> mdz: It's all the same scripts.  It's casper that should just get K links added where it removes S links. :)
<mdz> no one noticed for the past year
<infinity> rename 's/^S/K/' /etc/rc?.d/S??anacron
<mdz> so clearly this is powerpc-specific :-P
<mdz> infinity: I suppose casper has already loaded perl...
<infinity> Several times.
<infinity> adduser is the first, I think.
<Keybuk> infinity: pretty much
<ogra> woah, still plenty of space on my liveCDs
<Keybuk> for STUPID in /root/etc/rc?.d/S??anacron; do
<Keybuk>     mv $STUPID $(dirname $STUPID)/K00anacron
<Keybuk> done
<Keybuk> is what I've done
<crimsun> (I presume uploads are being queued presently?)
<mdz> K${basename%S} would work too though
<ogra> crimsun, /topic ;)
<crimsun> ogra: lovely, thanks.
<infinity> Kamion: Other than your xubuntu alternate hacking, and whatever you're futzing with WRT -server image placement, I think everything should be (re)built now.
<mgalvin> sorry to be a pest... is this going to be the finial rc (hopefully); just wondering when to move the rc doc to the main web site
* mgalvin does not want to jump the gun
<mdz> I'm testing the new desktop-i386 build now
<mdz> mgalvin: we won't know until we've tested it
<infinity> mgalvin: We're hoping this will be the real deal, but there's no knowing until we test.
<infinity> Hrm.  I think one of the cdimage mirrors is wonky.
<mgalvin> right, ok, of course, i was just wondering so I know not to got to far :)
<infinity> rsync's giving me the same "some stuff just ain't there" problems that I was getting via http.
<mgalvin> thnx guys
<Kamion> infinity: ubuntu-server's done, xubuntu alternate building
<Kamion> magellanic is being very slow to trigger
<Kamion> so it could be overloaded
<Kamion> Znarl: ^-- ?
<infinity> If I just want translations for console utilities (coreutils, gnupg, etc), what packages do I want?  language-pack-$LANG?
<Kamion> yes
<infinity> I'm thinking I should flesh out the ubuntu-server ISO before release with some of those.
<Kamion> mm, probably a good plan
<infinity> We're rather popular in the eastern block, for whatever odd reason, maybe Polish, Czech, Russian, etc would be appreciated.
<Burgwork> infinity, as an edgy plan, maybe have cds for "Africa" or "Asia", etc.
<Kamion> Burgwork: suggestion comes up about once a month, I'm really uncomfortable with it
<infinity> Burgwork: We've discussed localised CDs before, but it's just way too many ISOs to test with a small team.
<Burgwork> yep
<Kamion> Burgwork: it multiplies our testing effort unacceptably
<Burgwork> understandable
<infinity> In the case of ubuntu-server, though, I can have my cake and eat it too, since it's so light.
<infinity> So I can probably ship a fair number of langpacks.
<Burgwork> Kamion, maybe involve a few loco teams?
<Burgwork> anyway, this can be discussed later. Now is for release. sorry to bother you all
<infinity> A "build your own unsupported ISO" for loco teams to generate something they can redistribute locally might be cool.
<Kamion> Burgwork: we generally don't have time.
<infinity> But we can't really build and mirror dozens of extra ISOs ourselves.
<Kamion> we need to keep response latency very low during release times.
<ogra> the right way is to have a second CD with all langpacks imho we could even provide regular translation update CDs
<ogra> not additional localized install CDs
<Znarl> Kamion : magellanic was in the middle of a pulse, it's finished and recovering now.
<infinity> ogra: Well, if you're a loco team distributing desktop CDs to a bunch of locals who aren't all that nerdy, having a localised CD would be nice.
<infinity> ogra: But, like I said, I think that's something we should perhaps provide an interface for them to generate as an unsupported image, not something we should ship.
<ogra> infinity, sure but thats up to the loco imho
<ogra> yeah
* ogra remembers amu is offering such a service ... 
<Kamion> ogra: my concern about that is different: it's that once we start doing that, we'll almost certainly get lazy and not fit any langpacks at all onto the main CD, which means that we'll effectively have to ship the langpack CD in shipit, and that will negate all the cost benefits to Canonical gained by moving to the live CD installer
<Kamion> ok, new xubuntu images up that should work around the ltsp installation problem
<ogra> Kamion, indeed that shouldnt happen ... i'd also see the langpack CD as a job of the rosetta team, not of the distro team specifically
<ogra> (oor as a joint work of both of them)
<infinity> Znarl: FSVO of "recovering"... I assume it's still in the process? :)
<infinity> Znarl: Cause I'm still getting a lot of "there ain't no file where you're looking, idiot" errors from rsync.
<mvo> ogra: we even have a spec for langpack cds
<Kamion> ogra: while that's a nice dream, it seems highly unlikely to happen; the Rosetta team would rightly claim that they just do the infrastructure, and it's our job to get it out to users (the way we currently do with language packs)
<Kamion> I don't think that we get to assign work to the Rosetta team that's not really in their remit
<ogra> mvo, yes, i'm hoping for it to happen some day for edubuntu ...
<ogra> Kamion, well, i'm a dreamer, i know ... but sometimes things i dream actually happen :)
<Znarl> infinity : Do you have an example?
<infinity> rsync: link_stat "/ubuntu-server/daily/current/dapper-server-amd64.iso" (in cdimage) failed: No such file or directory (2)
<infinity> rsync: link_stat "/ubuntu-server/daily/current/dapper-server-i386.iso" (in cdimage) failed: No such file or directory (2)
<infinity> Etc.
<infinity> rsync: link_stat "/daily/current/dapper-alternate-i386.iso" (in cdimage) failed: No such file or directory (2)
<infinity> The latter being much older, and I'd expect it to be synced by now...
<Kamion> ogra: I'd like to make the Launchpad team write ubiquity for me too, but it seems unlikely ;-)
<ogra> heh
<ogra> admit, you didnt try it ;)
<Keybuk> infinity: what are those aussie choccie biscuits called?
<Kamion> I have a queer fondness for continuing to be paid
<ogra> lol
<Keybuk> like uk penguins, but not called that
<StevenK> Keybuk: Montes? Tim Tams?
<Kamion> Keybuk: tim tams
<ogra> mmm tim tams
<Keybuk> tim tams was it!
<StevenK> Speaking of, I have some Tim Tams in the fridge.
<StevenK> Blast, there was only one left.
<mdz> ubiquity/i386/erase install successful
<mdz> complete with two OpenOffice.org Spreadsheet menu items
<mdz> I wonder how many times that will get duped
<mdz> infinity: do you still have oo.o in ccache somewhere?
<infinity> mdz: Yeah, but it doesn't cache well.
<Keybuk> mdz: I just filed a dozen bugs abou tthat
<Riddell> is the cd build server busy or can I make new kubuntu alternative?
<mdz> Keybuk: thanks pal
<infinity> mdz: A new build will still take 3 or 4 hours, I suspect.
<infinity> Riddell: One was already spun for you.
<infinity> Riddell: Since the archive hasn't changed since then, you should be good to go. :)
<mdz> infinity: I expect the correction to the patch is trivial
<ogra> infinity, his seeds have ;) 
<Riddell> infinity: 20060524.1 overflowed
<Keybuk> why do you have to do a new build of open office?
<infinity> Riddell: Ahh. :)
<Keybuk> can't you just hack the debs open, fix the .desktop file, and whistle innocently
<Keybuk> ? :P
<ogra> Keybuk, to fix the .desktop file
<ogra> heh
<infinity> Keybuk: I've done that before in the Debian archive for text-only changes...
<Keybuk> it shhhould be possible
<mdz> look at the moral decay which follows when you forego the requirement that things actually build from source
<infinity> It's simple.
<mdz> it's abhorrent
<ogra> mdz, i have an ooo impress on edubuntu amd64 live 
<mdz> ogra: that's because its openoffice is old
<infinity> I had a script to do "arch-indep only changes", complete with adding the new changelog from the new source package, fixing control, and repacking.
<Keybuk> mdz: you really want to restart the entire process all over again, including building openoffice, under strace, just to fix an icon? :)
<mdz> Keybuk: not for RC, but for final, yes
<ogra> mdz, amd64 wasnt updated ? 
<infinity> It doesn't need to build under strace, it needs to build on terranova. :)
<mdz> ogra: no
<ogra> ohoel, k 
<ogra> grmpf
<_ohoel> :-)
<ogra> thanks :)
<Keybuk> hmm, I appear to need to hold down the Fn key to type my password
<Keybuk> oops
<ogra> just type it here, than you can copy and paste :P
<mdz> I've successfully tested i386 desktop and alternate erase installs
<Keybuk> ograismysweetheart
<mdz> unfortunately the tube is calling me
<Keybuk> you tube to the K&K?
<infinity> I think I need to do the nap thing.
<mdz> Keybuk: yes
<mvo> bye mdz
<infinity> I'll be back to testing in the "morning", whatever that is.
<infinity> mdz: Happy tubery.
<BenC> are there any other test targets that need to be done that I can take a crack at?
<ogra> gah, my dvdrom freaks your when ubiquity starts gparted
<Keybuk> ah, I keep forgetting you're American; and don't do the "walking" thing :)
<mdz> infinity: if I mail tollef about the oo.o thing, does he have access to do the build somewhere it'll work?
<BenC> I have an array of equipment that is being underutilized at the moment :)
<infinity> mdz: No, but if you pass me the diff (or tell me what needs to be changed), I can kick it off right now.
<mdz> Keybuk: I walk quite a lot at home actually...I just don't know my way around here
<mdz> i have a terrible sense of direction
<Keybuk> I'm hoping the weather will be nice, I want to start skating again; London is usually a good opportunity
<thom> mdz: if you find yourself swimming you've gone the wrong way
<Kamion> Riddell: go for it
<ogra> *giggle*
<Keybuk> mdz: K&K is basically "walk to the tube and keep going"
<Kamion> mdz: A-Z ++
<Riddell> Kamion: netinstall CD worked perfectly for kubuntu by the way
<thom> Kamion: when i use the A-Z i can't get a satellite view
* Keybuk has flashbacks of Tour Guide Thom
<ogra> whats a-z ? mobile navi ? 
<Kamion> Riddell: with that preseed/url? great
<Kamion> ogra: London pocket map
<ogra> ah
<mdz> Kamion: a-z?
<Kamion> er, street plan really
<Kamion> thickish book
<ogra> analogus navigation system :)
<mdz> google maps has good map data for here but doesn't do well with addresses
<Kamion> but pocket-size as far as length and width go
<Keybuk> Google Maps famously can't cope with UK addresses
<ogra> well, london doesnt do well with adresses :)
<mdz> infinity: I'd have to download a 73M diff
<ogra> (at least if you are german)
<mdz> ok, ok, I'll try
<infinity> Err, fair point.  Which .desktop needs to be renamed, and to what?
<mdz> infinity: the one which runs ooo-impress needs its name changed from "OpenOffice.org Spreadsheet" to "OpenOffice.org Presentation"
<mdz> as the changelog says
<infinity> mdz: Alright.  I'll just do that, then.
<Keybuk> what is it with some people?  "NM CVS HEAD doesn't build with -Werror" ... "uh, we don't ship either NM CVS HEAD or are foolish enough to compile it with -Werror" and set to rejected
<Keybuk> guy sets it back to confirmed
<Keybuk> grr
<infinity> mdz: Are uploads landing in an unchecked queue or something that I can easily manipulate with the queue tool?
<ogra> meh the pertition selection in ubiquity is evil ...
<mdz> infinity: they're landing in the usual spot; the queue processor is just disabled
<mdz> I don't know the incantation though
<infinity> mdz: Ahh, kay.  I can likely work out how to process a single one without issues.
<Kamion> ls -l /srv/launchpad.net/ubuntu-queue/incoming/*
<Kamion> ogra: thanks for your constructive feedback :-P
<ogra> Kamion, its complaining that a partition is assigned to more than one mountpoint which isnt true 
<Keybuk> infinity: wave process-upload.py over it
<Kamion> ogra: do you have multiple blank rows in the mountpoints table?
<ogra> i have hda4 / ands hda2 swap
<ogra> yes
<Kamion> ogra: known bug, on the list
<infinity> Keybuk: Yeah, but very carefully. :)
<ogra> ok
<ogra> any way around it ? i dont want to touch the other partitions
<Kamion> bug 46402
<Ubugtu> Malone bug 46402 in ubiquity "espresso mistakenly complains about partitions having multiple mount points" [Major,Confirmed]  http://launchpad.net/bugs/46402
<Keybuk> infinity: backup the database and archive before you do <g>
<Kamion> er, restart ubiquity and don't cause it to create multiple blank rows this time, I think
<Keybuk> make sure you sudo -u lp_upload -i first too
<mdz> infinity: I have no idea how the patching works and I have to run
<mdz> back in the morning
<Keybuk> mdz: enjoy
<ogra> hmmk
<Kamion> the queue processor runs as lp_queue not lp_upload
<Keybuk> does it?
<Keybuk> oh
<ogra> ouch and the german translation of the cancel dialog is very confusing
<Keybuk> ignore me then
<infinity> Keybuk: I will. :)
<Kamion> ogra: it should be fixable in Rosetta if you do it by the weekend
<ogra> Kamion, will do i think, the dialog asks if i want to cancel the install and offers a cancel and a quit button ... indeed i clicked blindly on cancel because of the text :)
<Kamion> oh that's not the translation
<Kamion> it's that way in English too, there's a bug about that too
<ogra> it should ask me to quit :)
<ogra> ah good
<Kamion> yes, not a huge deal though because the obvious mistake just takes you back into ubiquity
<ogra> yep
<Kamion> I'll fix it in edgy
<ogra> ++ for keeping all the settings :)
<ogra> (like users fullname etc)
<infinity> debdiff + openoffice source packages = go for breakfast.
<Keybuk> Kamion: jdub would approve
<Keybuk> always make the least destructive button the easiest to click
<infinity> You should just change the dialog to have two identical cancel buttons, and a single string that says "Guess."
<ogra> hehe
<mdke> | Blue pill | Red pill |
<Kamion> the final screen is better - "Continue using the live CD" and "Restart now" - but I forgot about the abort dialog
<Keybuk> shouldn't that say "DESKTOP CD" ? :)
<ogra> Keybuk, shh
<infinity> No, cause "desktop CD" means "Live CD + Desktop Installer"
<Keybuk> maybe we should call them Ubiquitous and Ubiquiless
<infinity> Though I'd prefer "Continue Live Session" to the current string.
<infinity> Since that's really what you're doing.  Carrying on the session, not "using the CD".
<Kamion> mm, I sort of prefer having a sentence rather than the jargon "session"
<mvo> infinity: i did the ubuntu-server/netboot test with the "normal" netboot images as "server". is this correct? 
<infinity> Maybe I want to shut down, pull out the CD, and use it as a frisbee, but that's not what the dialog's asking me. :)
<Kamion> though I take your point
<infinity> mvo: No idea, TBH.  I've not done a server netinstall.
<Kamion> file a bug if you want me to remember; nothing from release fortnight is going to stay in my head :)
<infinity> Kamion: Yeah, I'll see if I care after I've mangled OOo.
<mvo> infinity: oh, right. I should go to bed. I thought I had read your name in the i386 column, but it was the cd column :)
<infinity> mvo: Out of curiosity, what kernel did you end up with after that?
<ajmitch> morning
<mvo> infinity: its already overwritten with the next install
<infinity> mvo: Oh. :)
* mvo is suprised to see lilo as defualt for ubuntu-server
<mvo> why was it selected?
<infinity> It's not...
<infinity> Unless you installed on XFS...
<mvo> I did
<infinity> Evidently, grub doesn't *do* XFS.  Or, so I've been told.
<thom> yeah, you can't have grub on your root partition
<ogra> hmm, still not ?
<Kamion> there's a rumour that grub 0.97 has that fixed, but I haven't tested and now isn't really the time for experimentation
<Kamion> I'll try it out early edgy and see if it works on the machine I have where it used to reliably fail
<Kamion> infinity: that ubiquity infinite loop is a one-liner ...
<Kamion> -                    pass
<Kamion> +                    self.succeeded = True
<Kamion> on line 299
<Kamion> of ubiquity/components/partman.py
<infinity> Kamion: Does it go somewhere useful after that? :)
<infinity> (ie: take over the whole disk for me)
<Kamion> yeah
<infinity> Right.  Care to upload that, then, since we seem to be holding off for me to do OOo AGAIN?
<infinity> (Want me to test it first?)
<mvo> do we have a testplan that goes beyond "ServerTesting" in the wiki?
<infinity> mvo: The testplan for -server is mostly "check if you got the right kernel installed, see if the thing reboots alright, and if you're doing a LAMP install, did it install apache2, php5, mysql5?"
<Kamion> infinity: if you could test it, that wouldn't hurt ...
<infinity> It's pretty light, since -server doesn't really DO much of anything, except dump you in a base system.
<Kamion> infinity: oh, we're holding off for OOo? hadn't realised that
<mvo> infinity: ok, that was my plan too :)
<infinity> Kamion: mdz's asking me to fix it and upload before he took off implied that.
<infinity> (And I'm uploading now)
<Kamion> infinity: if I have a few minutes, I'd like to prod at the other big-deal items
<infinity> Kamion: Rebooting Zofia's machine now to test that one-liner.
<infinity> Kamion: You have hours, if we're waiting on another OOo build.
<infinity> Kamion: You should also get some sleep sometime, though, if we're going to be testing tomorrow dring daylight.
<infinity> s/dring/during/
<Kamion> yeah, will do, don't worry
<infinity> Here's hoping no one asks you to write another new installer next cycle.
<infinity> I don't envy your "everything hinges on Kamion's last-minute bugfixes" position right now. :/
<ogra> Kamion, whats about the PQSERVICE filesystem bug ? i still have it mounted after an ubiquity install on the new system 
<Kamion> ogra: PQSERVICE what now?
<ogra> thats the windows recovery partition on my haddisk
<Kamion> um no idea
<ogra> its mounted by default in the newly installed system
<infinity> Shouldn't that partition be marked hidden?
<ogra> we talked about it a while ago ...
<ogra> yes
<infinity> ogra: What's the partition type?
<mvo> Riddell: here?
<ogra> infinity, cfdisk doesnt have it
<infinity> ogra: fdisk -l
<ogra> neither
<infinity> Err, it doesn't show up at all?
<ogra> nope
<ogra> only on my desktop
<infinity> Then that's the problem.  Your manufacturer is an idiot.
* mvo wonders where he can find kubuntu netinst images
<ogra> well i know that, its acer
<infinity> It should be a normal partition with a hidden partition type.
<ogra> hmm, doubleclicking it gets me to /
<mjg59> Yes, partition types with the hidden bit set (which is bit 8, I /think/) probably shouldn't be mounted
<infinity> They're doing something rather evil to make it not show up at all.
<ogra> yup
<infinity> mjg59: Yeah, but partitions with that bit set would show up in fdisk -l
<ogra> but it only shows up in live installs, not with the install cd
<mjg59> infinity: Sure
<infinity> mjg59: His is hidden in some thpethial way.
<Keybuk> ok, I've just managed to completely bodge up this test install
<Keybuk> TIME FOR BED
<infinity> mjg59: Since his doesn't actually show up at all.
<mjg59> infinity: Though last time I checked, "hidden" partitions still got mounted
<mjg59> Uh. If it's not in fdisk, it won't be in /proc/partitions
<mjg59> Or if it is, dmesg should give a pretty good clue how it's got there
<infinity> mjg59: Yeah, that would qualify as a bug, then.
<mjg59> infinity: Yes, now you mention it, I agree
<mjg59> It just hadn't really occured to me before
<mjg59> That ought to be a pretty simple check...
<ogra> i even had these little popups telling me that pqservice was 99% full, but that was fixed at some point during development and disappeared
<Riddell> mvo: hih
<mvo> Riddell: hello! where can I find netinst image for kubuntu?
<Riddell> mvo: same as ubuntu image but different preseed see bottom of KubuntuFiles
<mvo> Riddell: aha, thanks
<infinity> Kamion: Confirmed, your fix lets me see parts of ubiquity I've never seen before. :)
<ogra> discovery #
<infinity> Kamion: Alright, I just practiced my leet manual queue processing skills on OOo.  If and when you have a ubiquity upload, let me know.
<ogra> hmm, why isnt the cursor theme set by the X server anymore ? 
<Kamion> la la la I hate gparted
<infinity> mvo: I still didn't get my sexy Tbird icon in app-install-data. :(
<infinity> mvo: I assume you have a roll-up of changed data pending for post-rc?
<mvo> infinity: hm, I was sure I added it. but for post-rc i have some stuff pending, I can include it then
* _ion wonders whether his computer is compiling gnash or actually computing the question for the answer "42".
<_ion> Or maybe both computations just happen to take an infinity (no pun intended).
* ogra really wonders when he'll get the first typo bugs for "Welcome to Edubuntu 6.06 LTS !" in teh ff startpage 
<ogra> this capital LTS is so omnipresent ...
<Burgwork> ogra, not a big fan of the LTS, myself
<ogra> Burgwork, well you dont build a distro where people will expect "Edubuntu 6.06 LTSP" ;)
<neuralis> mvo: apparently apt 0.6.44 includes incremental updates. there's an accepted SoC project that you were going to mentor to implement the same thing. i was going to ask the student to take a look at the apt implementation and see how much it overlaps with his proposal; is this alright with you?
<infinity> neuralis: I'd suspect mvo knows about apt's new features, since he uploaded them. :)
<mvo> neuralis: the implementation in 0.6.44 only works for indexfiles (Packages/Source.gz)
<mvo> neuralis: oh, and what infinity said :)
<infinity> mvo: Have you spoken with the soyuz people about getting a mirror-side implementation for that, BTW, or are we just going to skip on that feature for Ubuntu?
<neuralis> infinity: d'oh, that occurred to me half a second after i hit enter :)
<mvo> infinity: skipping seems to be the best, it is optimized for the debian case with only a single update to the Packages file per day
<mvo> it works by keeping ed-style diffs around
<infinity> mvo: Yeah, I know how it works.  I figured it might actually be better for us, if done right.
<mvo> for ubuntu (and debian) I would like to explore a zsync based idea
<mvo> infinity: oh, interessting. can you elaborate?
<infinity> mvo: Especially for the compulsive updaters who are downloading more in Packages.bz2 every hour than they are in actualy package data.
<infinity> mvo: Because of our short cycles, the "Packages files are huge, ARGH" problem is magnified, IMO.
<mvo> how often do we update the Packages file currenlty? 4 times/day? more?
<infinity> Well, if someone uploads something at least once and hour, we update is 24 times.
<infinity> s/is/it/
<infinity> And if soyuz gets the speed bumps required to bump us back to 30 minute cycles, we get 48 updates a day.
<infinity> (Again, assuming people upload during each cron.daily)
<infinity> On busy days, I'd say we approach that, though.
<mvo> that would mean 48 diffs per day, rather a lot of files. I wonder how well it would work
<infinity> Wouldn't have to mean that.
<infinity> The implementation could be bent a bit.
<mvo> Riddell: do you have a special testplan for kubuntu?
<infinity> You could have the "daily diff", which just keeps growing throughout the day, until it's a full-day diff.
<mvo> now that is a interessting idea!
<Kamion> infinity: ok, I've got a few ubiquity changes ready and tested now. Would you mind eyeballing the diff for me?
<infinity> Kamion: Have at 'er.
<Kamion> infinity: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.0.7.diff
<mvo> infinity: I put that as a spec for paris (and will see what my student comes up with)
<infinity> My yoghourt is mocking me.
<infinity> Under the lid, it says "you are not a winner".
<thom> infinity: it's only telling you what we've been saying all along :-)
<Riddell> mvo: yes, bottom of Testing/Short
<HrdwrBoB> so what it's really saying is that you are #1 loser
<Kamion> Riddell: wouldn't mind if you eyeballed the diff above either, since it has kde-ui changes (precisely parallelling gtkui changes)
<mvo> Riddell: *cough* now I could have spotted this :P
<ogra> mvo, if it werent 2am :P
<infinity> +            if check is None or check == '' or check == ' ':
<infinity> Thankyou Python, for not providing an easier way to state that.
<Kamion> I think it's probably only ever ' ' or something sensible, but I was being hyper-careful
<Kamion> Python does actually, I could say "if check in (None, '', ' ')"
<Kamion> I'll change that and re-test
<infinity> I love how I keep seeing double between kde-ui and gtk-ui.... There must be some clever way to, oh what are the kids calling it these days, "abstract" that... :)
<infinity> Kamion: Anyhow, the diff, from what I understand of the context and the changelogs, appears to be rational.
<Kamion> yup, works fine
<Kamion> yes, the level of frontend duplication is very annoying
<Riddell> Kamion: looks sensible
<Kamion> but edgy :)
<Kamion> Riddell: thanks
<bddebian> Heya folks
<Kamion> Riddell: I know qtparted never says "1 Cancel" at the moment, but it was easier to keep the code in sync
<infinity> Kamion: If you want to upload that, I'll manually process the upload, then I can go have a nap while the buildds crunch on OOo...
<infinity> Kamion: (And so should you)
<Kamion> this was certainly the last thing I was planning on doing before bed
<bddebian> heh
<ogra> hrm
<ogra> Kamion, the workstation selection in the install CD suddenly installs "server"
<ogra> (edubuntu that is)
<infinity> Kamion: AWTY?
<ogra> dpkg -l|wc -l
<ogra> 706
<ogra> :(
<Kamion> infinity: uploaded
<Kamion> ogra: syslog etc.
<infinity> ogra: We all got together and decided to surprise you with this space-saving technique.
<ogra> yep, looking into it now ...
<infinity> Kamion: Danke.  Processing.
<infinity> Nap time for me.  See you all in the morning for more testing.
<bddebian> Gnight infinity
<Kamion> And I think I'll go to sleep too. Back in ~7.5 hours; please SMS me (or get somebody who knows my number to do so) if anything release-critical comes up
<bddebian> Gnight also Kamion
<Kamion> (it's *unlikely* I'll wake up, but you never know ...)
<ogra> Kamion, can you bookmark that for tomorrow http://people.ubuntu.com/~ogra/syslog 
<Kamion> ogra: that syslog shows it installing the desktop.
<Kamion> search for "'pkgsel" (leading apostrophe)
<ogra> Kamion, yes, but no trace for gdm and the like 
<ogra> go to bed i'll dig ...
<Kamion> apt says it's going to install gdm, and then apparently doesn't
<ogra> yep
<ogra> neither edubuntu-desktop
<Kamion> but yeah, going
<ogra> but there is no error at all
<xhaker> anyone think nautilus sound preview should be gstreamer powered? or atleast aplay?
<xhaker> i'm trying to find the code responsible for this on nautilus cvs
<jsgotangco> good morning
<ogra> jsgotangco, hey
<jsgotangco> ogra: another marathon night (or day)?
<ogra> yup
<ogra> (night) 2:42 am here
<Riddell> 50 minutes ahead of britain?
<ogra> err
<ogra> :52
<ogra> i'm half way sleeping already
<Riddell> me too, finishing this last install and I'm done for the day
<ogra> did you manage a full test cycle ? 
<ogra> why the heck does x-window-system install xolgo and xclock ? 
<bddebian> Heya jsgotangco
<mvo> ogra: wasn't this always be the case? iirc x-window-system-core was the minimal one
<bddebian> Hmm, did they shutdown uploads or no?
<Riddell> ogra: all 6 CDs plus netinstall.  but I'm far from completing the whole testing grid
<ogra> mvo, i meant -core, sorry ... seems i have these packages in my ltsp clients now :)
<mvo> -core contains xlogo? someone should talk to the X maintainer then ;)
<ogra> which one ? there are so many currently :P
<ogra> lol
<ogra> x-window-system-core depends on xbase-clients
<ogra> and xbase-clients depends on 50 single-binary packages or so 
<ogra> ..xload, xlogo, xlsatoms, xlsclients, xlsfonts, xmag, xman, xmessage, xmore, xrgb, xrefresh, xsetroot ...
<mvo> ogra: haha, right. lets just pick one at random
<ogra> why are they all in single packages ???
<ogra> o_O
<mvo> dude ... "modular" :P
<mvo> haven't you noticed the xlogo-doc package? with the manpage?
<ogra> hmm, someone should tell daniels that scattered must not mean modular :)
<ogra> *giggle*
<bddebian> heh
<ogra> mvo, does that carry the docs for the xlogo-dev package as well ? 
<mvo> heh :) xlogo-dev-doc? but I think it is getting silly now :P
<ogra> yeah, as silly as this packaging
<bioeng> Hi everyone
<bioeng> I just wanted to hang out here
<bioeng> I'm going back to school
<bioeng> I'm getting a degree in EE
<bioeng> so I wanted to be around some software people
<Riddell> bioeng: the place to start helping tonight is https://wiki.kubuntu.org/Testing/Current
<bioeng> Before I do this, I have one question
<bioeng> Is it possible to dual boot Ubuntu and Windows XP?
<jsgotangco> Yes
<ogra> thats a question that better suits to #ubuntu 
<bioeng> Can you get a lot of embedded systems experience with Ubuntu?
<jsgotangco> Riddell: do you need a hand on amd64 test?
<ogra> bioeng, please ask non development related question in #ubuntu, this is the coordination channel for development here
<bddebian> Do we officially support Sparc?
<ogra> bddebian, yes
<bioeng> I will ask there
<ogra> but only -server
<jsgotangco> wow
<bddebian> ogra: Ah
<jsgotangco> ogra: that is news
<ogra> there wont be a desktop CD 
<ogra> (no official one)
<Riddell> jsgotangco: yes please, go for one of the missing cells in the kubuntu table here if you can https://wiki.kubuntu.org/Testing/Current
<Riddell> but all results are good to know
<jsgotangco> Riddell: cheers
* mvo goes to bed
<Riddell> bddebian: I don't think it has been announced yet
<ogra> nope
<ogra> its a public secret :)
<ogra> hmm, intresting the default install semms to finish fine 
<bddebian> ogra: :-)
<bioeng> One question:  what level of programming skill is required to develop for this OS?
<bddebian> bioeng: Believe me, not a great deal :-)
<ajmitch> ogra: interesting to hear, actually :)
<bioeng> Just basic programming?
<infinity> bioeng: Everything from basic shell scripting to deep kernel hacking.  And none of this belongs in this channel.  If you're interested in helping out, please check out #ubuntu-motu
<ogra> ajmitch, yes, since the workstation install failed (without errors but only half of the desktop installed)
<bddebian> bioeng: Check out the MOTUs
<ogra> infinity !!
<ogra> infinity SLEEP !!
<bioeng> OK
<infinity> ogra: I'm just a figment of your imagination.
<ogra> haha
<thom> infinity: you're asleep, fool
<bddebian> heh
<bddebian> Heya LaserJock
<ogra> meh, why doe this work and the other doesnt :'(
<ogra> woah kde-i18n-de is 17MB now ? 
<ogra> that was 12 or so in breezy
<wftl> Hello everyone. Is there actually any difference between the DVD Dapper vs the CD (other than media). They appear to be the same and my publisher is asking which we should include with the book.
<jsgotangco> grab the liveCD that would be much better IMO
<ogra> dvd contains the desktop and the alternate iso as well as all of supported
<wftl> ogra: So a user accepting a default boot won't see any difference.
<ogra> but jsgotangco is right, i'd also go for the desktop (live) CD for publishing
<wftl> jsgotangco: thanks for that tip
<ogra> since thats your default install media now that we have the ubiquity installer
<ogra> where do you publish ?
<wftl> ogra: Addison Wesley is my publisher. The new book is called "Moving to Ubuntu", due out late July.
<ogra> in a country with generally bad internet access (Africa, India) the DVD might be a better choice
<wftl> ogra: Does the DVD have additional sources though?
<jsgotangco> that is neat, ubiquity is actually perfect for "moving" new users
<wftl> Nothing visible from the menu.
<ogra> it has *all* packages in the supported set ... 
<wftl> ogra: not in the menu though.
<wftl> ie: Applications
<ogra> you dont install single packages from the menu ;)
* Riddell reminds ogra that Africa is not a country
<ogra> right, sorry to all africans in here :)
<jsgotangco> heh
<wftl> ogra: Granted, but you can't run the additional packages from the live menu. 
<wftl> You need to install it first.
<ogra> yeah
<ogra> the advantage of the DVD is that you dont need internet to install a lot of packages ... 
<ogra> the disadvantage is that they might be outdated (missing security updates etc)
<ogra> for a book like that i'd got with the desktop CD
<wftl> Okay, so the package repositories are on the DVD then. I just can't see them unless I install and fire up Synaptic, correct?
<ogra> for the "nairobi computer magazine" i'd go with the DVD
<ogra> wftl, yep
<Riddell> the other disadvantage of the DVD is that you need a DVD reader to use it
<ogra> yep
<wftl> Riddell: Good point, and not everyone will have a DVD. 
<ogra> which in turn might make it not a good coice for named magazine 
<wftl> Okay then, CD it is.
<wftl> Thanks, ogra, Riddell, jsgotangco. I appreciate it.
<jsgotangco> cheers
<jsgotangco> good luck on the book project too
<ogra> yeah
<wftl> Thanks. Lots of excitement around it already. Should be fun.
<Riddell> wftl: make sure you have a good kubuntu chapter in your book
<ogra> and a good edubuntu one !
<bddebian> Heh @ Riddell & ogra
<wftl> Riddell: already done. There's a chapter on [ahem]  turning Ubuntu into Kubuntu (so to speak).
<ogra> geez, now the WS install works 
<Riddell> wftl: excellent :)
<wftl> No Edubuntu chapter though, sorry.
<ogra> must have been cosmic rays or something
<wftl> Riddell: Had to. I normally run Kubuntu so . . .
<wftl> ;-)
<ogra> wftl, bah, and we even ship the most revolutionary LTSP impelmentation currently available 
<wftl> ogra: LTSP? Where?
<ogra> wftl, edubuntu
<bddebian> ogra: Is there an edubuntu team on LP?
<wftl> ogra: Coolness!
<ogra> installs a ltsp classromm server out of the box
<wftl> ogra: That's wild! I need to check it out.
<ogra> and has a new ssh based ltsp implementation
<ogra> bddebian, sure, arent you a member ? you could even join edubuntu-members and get an edubuntu.org mailaddress ;)
<bddebian> Heh
<ogra> but there are also edubuntu-bugs, edubuntu-testers and many more
<bddebian> I was just going to check out your bug list :-)
<ogra> its trivially small :)
<ogra> (compared to kubuntus for example ;) )
<bddebian> What team name are they subscribed/assigned to?
<ogra> edubuntu-bugs
<Riddell> ogra: do those e-mail addresses work?
<ogra> Riddell, yep
<bddebian> Yeah I've worked on kubuntu bugs.  It's a hefty list :-)
<ogra> dont yours ? 
<Riddell> dunno, never trie
<jsgotangco> wftl: you can actually swith ubuntu/kubuntu to edubuntu desktop even
<Riddell> is it launchpad-id@edubuntu.org?
* Riddell hugs bddebian 
<ogra> jsgotangco, but that wont bring you ltsp out of the box though :)
<bddebian> Riddell: Well you never did tell me if I was doing you any good :-)
<jsgotangco> true
<jsgotangco> ogra: you're saying my workstation tests are worthless heh
<ogra> jsgotangco, no, my failed one was
<Riddell> bddebian: I still havn't read bugmail from that day you asked
<Riddell> I'll probaly let you know by the weekend :)
<ogra> jsgotangco, http://people.ubuntu.com/~ogra/syslog
<ogra> jsgotangco, search for gdm in there
<ogra> or edubuntu-desktop 
<Riddell> ooh, jr@kubuntu.org works
<ogra> you wont find it more than once
<bddebian> Riddell: Heh
<Riddell> wonder how long before that get spam
<bddebian> ogra: Yeah, that's a pretty small list :-)
<ogra> yup
<ogra> since we switched to source only packages the list is very small 
* Riddell beds
<ogra> kdeedu is a good bunch of binary packages :)
<jsgotangco> May 25 00:03:05 in-target:   dvd+rw-tools ed editres edubuntu-artwork edubuntu-desktop ekiga eog
<ogra> jsgotangco, yep
<bddebian> Gnight Riddell
<ogra> but the unpackaing configuring and installing lines are missing
<ogra> and there is no error at all .. it finished fine, and rebooted to console
<jsgotangco> hrmmm
<jsgotangco> yeah
<ogra> no gdm and only half of the desktop installed
<jsgotangco> i noticed that near th end
<ogra> but for now i blame my broken DVD reader 
<ogra> it sometimes has bad days
<ogra> but what should you expect from a dvd reader thats not even able to play an audio CD
<jsgotangco> rotfl
<jsgotangco> ogra: hmmm did you consider breezy->dapper upgrade for edu in the test?
<ogra> nope
<ogra> not yet
<ogra> i'll pull a breezy i386 iso on the weekend and test that out
<ogra> i also have to write ltsp upgrade instructions to update the clients 
<ogra> jsgotangco, you didnt note down your successfull installs on https://wiki.ubuntu.com/Testing/CurrentEdubuntu 
<jsgotangco> pfftt sorry
* jsgotangco goes there now
<ogra> YAY
<ogra> WS install amd64 is good ... finally
<ogra> jsgotangco, wow, that was fast :) thanks 
<jsgotangco> testing expert now
* ogra starts i386 WS
<SuperQ> hey, is 2.6.16-23 going to make it into the RC installer CD?
<jsgotangco> ogra: amd64 autoresize, workstation, expert check
<ogra> yay
<ogra> did you try the ltsp builder in expert ? 
<ogra> cbx33 had some probs
<jsgotangco> heh doing it now
<ogra> SuperQ, you mean if we upgrade from 2.6.15-23 to a 2.6.16 kernel within the next hours (one week after the kernel freeze ?)
<jsgotangco> i need a network connection to do that right?
<ogra> nope
<jsgotangco> okay
* jsgotangco is running out of nodes
<ogra> its like in the default install
<ogra> but  i dont really expect it to work anyway
<jsgotangco> doesn't hurt for another failure to happen to be sure
<SuperQ> ogra: no, I mean will something >= -23 be part of the installer image
<SuperQ> ogra: It wasn't in the daily a couple of days ago
<ogra> SuperQ, we wont ship 2.6.16
<Lathiat> i think the .16 was a typo ?
<Lathiat> given -23 is th current 2.6.15 ubuntu revision
<ogra> and the kernel freeze was supposed to be 7 days ago
<SuperQ> oh.. sorry.. 2.6.15-23
<SuperQ> ogra: tyopo
<SuperQ> :)
<Lathiat> has anyone else heard of -23 breaking intel hd audio?
<ogra> so we wont change anything wrt kernel for RC
<SuperQ> right
<ogra> also the RC candidate is pretty much finished ... 
<ogra> only some hours away
<SuperQ> I just want to make sure 2.6.15-23 will be the boot kernel for the RC installer
<ogra> yep, the current one will be the RC kernel (unless someone find something really evil today)
<SuperQ> ok, good
<SuperQ> some of the hardware on my gf's T60 is missing from beta2
<SuperQ> hardware support
<SuperQ> thanks
<jsgotangco> ogra: hmm the install didn't do anything at all on setting up LTSP
<ogra> yup
<ogra> thats what cbx33 reported as well
<jsgotangco> ogra: that happened when i didnt have a network
<jsgotangco> when i plugged in, its now doing ltsp chroot
<jsgotangco> but it seems it only went to 50%
<ogra> heh
<ogra> its not depending on network
<ogra> but it depends on the mounted cd, is that still mounted ? 
<ogra> also look at console 3
<ogra> it should show any output there
<jsgotangco> the chroot failed
<ogra> yep
<ogra> i'll test myself after some h of sleep
<jsgotangco> k
<jdub> oh man
<jdub> sounder sucks these days :(
<ajmitch> too much noise & heat\
<jsgotangco> :/
<vinboy> hi
<vinboy> is the release candidate out yet?
<Burgundavia> vinboy, nope, you will see an announcement
<vinboy> ok
<vinboy> in 6 hours
<fabbione> vinboy: when it's ready
<sivang> re all
<kagou> Good morning
<sivang> hey kagou , what's up?
<kagou> sivang, coffee time :) and you ?
<kagou> sivang, is that you working on hubackup ?
<sivang> kagou: it is , I know it needs a lot of more work :)
<kagou> sivang, it look promising. do you have cvs or web site ?
<sivang> kagou: bzr branch is it http://mercury.linuxguru.net/~sivan/upbackup--main
<sivang> kagou: also you can apt-get source it
* pygi copy bzr repo
<nomed> sivang, is it a launchpad proj too ?
<nomed> i see it is 
<sivang> nomed: yes, scanned fro revisions and everything, I'm also going to mirror it at supermirror when I find a minute.
<nomed> sivang, would it be possible to add dev bzr branch to the proj page ? 
<sivang> nomed: is there already? what's the link you are talking about?
<nomed> ohh yep i see
<nomed> there was a strange link at the proj frontpage in launchpad
<nomed> sivang, are u using notification-daemon too at the end ?
<Keybuk> heh @ Dilbert ... "Now, I know how much you hate the phrase 'In lieu of a raise'"
<pygi> sivang, I have good news for you
<jdub> hrm, is there any way to figure out what PCI version a motherboard supports from within linux?
<sivang> pygi: Mario, sorry I was away last day - you know all manhy aarrangment etc
<jdub> "only firefox and your mobo vendor's website" is an acceptable answer if that's the case ;)
<sivang> pygi: I saw you emailed me and I did not exactly understand about what
<pygi> sivang, no problem at all, just tell me once you are back 
<pygi> yea, that message carried no common sense :)
<sivang> pygi: back for some time now
<pygi> sivang, oki, you know that backup thingy....well he wasn't accepted for us (he did, but there was collision with 3 other orgs)
<pygi> he'll work with us this summer 
<pygi> not for money tho, but he'll still work, so :)
<sivang> pygi: ah, do you think he'll manage it? I mean, if he's already going to be busy - probably asking him for one more poject could be not that good for him..distractions etc. but if he's interested in helping, then why not.
<pygi> sivang, I haven't asked him to help...he offered help ;)
<pygi> sivang, and yes, he seems very talented, and he can probably manage it
<Keybuk> grr, somebody is doing it again.  Filing bugs because "things look wrong" and not because they have an actual problem!
<sivang> pygi: what's the other project he got accepted to?
<pygi> sivang, he got accepted by 4 orgs(record) but resolution went to Gentoo (WYSIWYG (insert the doc format) editor)
<sivang> pygi: nice
<pygi> sivang, anyway I'll look at what we have currently today or tommorow so we can start hackin' on it
<pygi> okay, I gotta run now
<sivang> pygi: very cool, I may be away on and off until I get sorted (paper work, other stuff, probably movin again) so feel free to start ahead , analyze the ode, and draw a plan how to work out towards Anat's plan.
<sivang> pygi: btw, how is e caled on IRC?
<jdub> Keybuk: I WANT A DMA!
<jdub> Keybuk: TWO! I WANT TWO!
<sivang> hehe
<Burgundavia> jdub, no, the bikeshed should be blue!
<Keybuk> jdub: hehe
* jdub posts EOT
<Keybuk> it's sounder, it's inherently off-topic and rambling
<Keybuk> if it were u-d, I would have got the AK47 out long ago
<Keybuk> actually
<Keybuk> there's a link you can put on your EOT :p
<Keybuk> http://www.catb.org/~esr/jargon/html/magic-story.html
<jdub> it's inherently off-topic-ish, but there's no excuse for pointless, argumentative, unproductive drivel on any list
<Treenaks> Just make enable DMA randomly (or not) on each boot, that should make everyone happy :P
<sladen> jdub: IIRC, PCI-Express, 64-bit and 66Mhz versions are all transparent to the OS.
<Treenaks> sladen: 'PCIE is transparent, but with extra magic added', afaik
<mdz_> morning
<jdub> (i ended up getting a useful answer from intel, via the clug archives)
<jdub> (my mobo is pre i810, so doesn't support PCI 2.2)
<Keybuk> Treenaks: yeah, one day we'll fix the extra magic
<Keybuk> right now the magic is gone
<sivang> battery going down, laters all
<Keybuk> look in /sys/bus/pci_express/devices, look how many different links there are, then look at how many different link _names_ there are
<Treenaks> Keybuk: ooh nice!
<Keybuk> it's not really a major bug until we have something that _cares_ about PCI-Express
<Treenaks> (like some X drivers?)
<Keybuk> the X drivers will access the card through the PCI bridge
<Keybuk> usually they start talking PCI, and then switch to PCIe once they realise they can
<Kamion> morning
<Mithrandir> mdz: (re Calc & Impress both being named spreadsheet): Sorry. :-(
<mdz> Mithrandir: sorted now; let's do this thing
<infinity> mdz: I'm going to do OOo-amd64 right now, if that's alright.
<mdz> infinity: please
<infinity> Unless someone with more bandwidth wants to...
<infinity> Mithrandir: ?
<mdz> that would also be sensible
<infinity> Or I can just do it in the DC, and ship the changes home to sign.
<Mithrandir> infinity: it's a national holiday for me here today so I'd prefer to not work today.
<infinity> Mithrandir: Understood.  I'd prefer not to work today too. :)
* infinity gets on it.
<Kamion> are the other arches ready for candidate builds?
<infinity> i386 should be, since I just published the i386 OOo binaries.
<Keybuk> eta for the candidates?
<infinity> powerpc JUSt finished the OOo build, so we may as well wait for that to upload and publish.
<mdz> I just verified the menu entries on i386 ;-)
<Keybuk> if > 1hr, I'll pop out now to get milk and essentials, rather than later; if that's ok?
<mdz> Keybuk: >1hr
<Keybuk> I was dreaming about usplash last night ... very bizarre
<infinity> Oh, publisher's off, BTW, so I can drive it by hand immediately after I get uploads in.
<infinity> Keybuk: Sick.
<mdz> znarl: I'm seeing rsync connections unexpectedly closed/reset on cdimage
<mdz> znarl: rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<omeg> Keybuk: did you get any splendid new ideas for it?
<Keybuk> omeg: I couldn't decide whether to add progress bars for running fscks, or just disable the automatic fsck anyway (except for bad unmount)
<lifeless> mmmm progress mmmmm
* Kamion looks at bug 46521 and is impressed that the reporter managed to boot the desktop CD in the first place
<Ubugtu> Malone bug 46521 in ubiquity "Installer crashed - Powerpc system with no yaboot bootstrap partition." [Normal,Unconfirmed]  http://launchpad.net/bugs/46521
<Kamion> the occasional automatic fsck is a good thing to keep, I think; filesystem damage isn't always accompanied by the filesystem being marked dirty
<mdz> does anyone else see this rsync problem?
<mdz> Kamion: so we're rolling a new candidate for ubiquity 1.0.7?
<Kamion> we were rolling a new candidate for OOo anyway, I thought
<Kamion> if we're not, then I don't mind if it waits until post-RC
<mdz> I expected to have it waiting in the wings for post-RC, but I suppose we do have the option
<mdz> we could roll one and start testing, and have the existing candidate as a fallback
<Kamion> sorry, I just assumed that we were doing OOo now because we wanted it in the RC
<Kamion> infinity was under that impression too
<mdz> oh, well if sleep was already lost on it, we should definitely go for it then
<Kamion> still, the infloop fix for systems with multiple disks is worthwhile
<mdz> indeed
<infinity> mdz: It'll take less than an hour to get OOo in for all arches now, so I think it's a win.
<mdz> Kamion: and VERY VERY SCARY that we didn't hear about it until now
<Kamion> it was probably introduced in ubiquity 0.99.83, the resize handling changes
<infinity> mdz: If only to avoid the huge amount of dupes for the broken string. :)
<Kamion> which was after Flight CD 7, so I'm not so surprised that I wasn't getting "mass-market" reports of it
<mdz> well, unless this rsync problem is fixed, I won't be able to download the new candidate very effectively
<mdz> is it only me, or no?
* infinity tests.
<mdz> first connection works, second one blows up
<infinity> Oh, all my images are up to date, so I can't really tell...
<infinity> They happily download 93 bytes each, though.
<mdz> infinity: doesn't matter, mine are too
<fabbione> mdz: i can connect fine
<mdz> fabbione: how many times in sequence?
<mdz> it's always the second connect which fails for me
<mdz> receiving file list ...
<mdz> 3 files to consider
<mdz> sent 111 bytes  received 138 bytes  498.00 bytes/sec
<mdz> total size is 2159151104  speedup is 8671289.57
<mdz> rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<mdz> (that's daily-live  followed by daily)
<fabbione> 21
<fabbione> mdz: probably you are hitting the ip limit
<mdz> hmmm
<fabbione> and one of your session is still hanging there
<fabbione> wait a little bit
* mdz tries a sleep
<fabbione> did you break an rsync in the middle?
<mdz> sleep fixes it
<fabbione> nah sleep is pointless
<fabbione> ?
<mdz> sleep 1 between the rsyncs got it going again
<fabbione> hmm try removing it again
<fabbione> probably the hanging connection did timeout?
<mdz> working now too
<fabbione> also.. to what cdimage are you connecting?
<mdz> maybe
<mdz> cdimage.ubuntu.com
<fabbione> there is more than one
* Kamion always rsyncs-over-ssh from lithium. Don't tell anyone.
<fabbione> Name:   cdimage.ubuntu.com
<fabbione> Address: 85.133.25.10
<fabbione> Name:   cdimage.ubuntu.com
<fabbione> Address: 85.133.25.11
<Kamion> (I got into the habit when rsync from cdimage was much more regularly broken, and never changed my scripts when it got more reliable ...)
<mdz> Kamion: I don't keep keys on the office server, or forward an agent to it either ;-)
<fabbione> Kamion: not everybody has access to these boxes.. you lucky B*****D
<Kamion> mdz: heh
<Kamion> fabbione: well, quite ...
<fabbione> ;)
<fabbione> infinity: how is OO.o doing on the != x86 arches?
<infinity> fabbione: PowerPC is built, -amd64 is uploaded (as of 2 minutes ago) and the publisher is running.
<fabbione> infinity: sparc?
<infinity> sparc's still grinding away... But we're not (officially) testing sparc desktop CDs anyway, so...
<fabbione> infinity: right.. 
<sivang> hmm, nice spash
<sivang> splash eve
<infinity> sivang: Which one?  The new GNOME splash?
<sivang> infinity: yes, quite nice
* _ion noticed shipit allows one to order just one CD now. Has something changed regarding the "shipping costs for just one CD / cost of the actual CD >= toobig" matter?
* infinity reads off the post-it on his desk:
<infinity> "Yes, I think the new GNOME splash is great too, because if I didn't think it was, mdz would kill me."
<kagou> lol
<fabbione> infinity: ahahahha
<sivang> infinity: Well, I happen to really think it's nice :) I liked the transparent upper part 
<mdke> yeah, good art all round
<infinity> I'm just trying to avoid getting murdered in Paris for accidentally convincing people to bikeshed over yet another piece of artwork.
<mdz> just wait, there are more changes to come
<infinity> So, yeah.  THE NEW SPLASH IS AWESOME.
<mdz> infinity: friends don't let friends endure last-minute artwork changes: https://launchpad.net/distros/ubuntu/+source/ubuntu-artwork/+bug/46219
<mdke> not the final artwork eh
<Ubugtu> Malone bug 46219 in ubuntu-artwork "Folder icons in 'Human' theme are huge" [Major,Fix committed]  
<fabbione> Kamion: i assume the new ppc -desktop- has fixed ubiquity, right?
<infinity> fabbione: Define "fixed"
<infinity> fabbione: It has 1.0.5, but not 1.0.7... I think.
<fabbione> infinity: for the link_kernel template thingy
<fabbione> ok
<infinity> Oh, yeah, that's fixed.
<fabbione> i assume it is unreasonable to ask for new images?
<infinity> Since it's easier to do them all at once, I'm just gonna wait for amd64 OOo to hit the archive.
<fabbione> ok
<infinity> (Oh, and PPC OOo is still publishing..)
* infinity gets out and pushes drescher.
* sivang wonders at the meaning of bikeshed is used in infinity's sentence.
<mdz> sivang: wikipedia
* sivang wikipedias
<mdz> infinity: oo.o-amd64 is in this publisher run as well?
<infinity> mdz: The source.  It'll be one more run to get the binaries in.
<sivang> ah, I see.
<infinity> mdz: Thankfully, the binaries build in about a minute, so it'll be quick turnaround.
<mdz> cool
<_ion> Huh, what's up with this? "10 CDs requested in 2006-05-20. 10 CDs approved and sent to the shipping company in 2006-05-24"  Dapper isn't even released yet.
* infinity completely fails to get wikipedia to tell him anything interesting about bikesheds.
<dAndy> http://en.wikipedia.org/wiki/Color_of_the_bikeshed
<infinity> Oh, I had to follow a See Also from Parkinson's law.  Silly me.
<dAndy> yep :)
<mdz> _ion: presumably they're queueing orders for us
<ajmitch> evening
<sivang> infinity: I'm bothered by mediawiki's search capabilities. none of the returned search restuls mention the search term itself and where it was found, this can be confusing.
<mdz> infinity: have had a chat with celso and after dapper, we can have a go at doing builds without waiting for the publisher
<_ion> mdz: I.e. no CDs have actually been sent to the shipping company?
<infinity> mdz: \o/
<mdz> _ion: the shipping company and the company who manufactures the CDs are the same company
<_ion> mdz: Ah, okay.
<infinity> mdz: I've told him before that build-from-incoming is a somewhat useful thing for sane security releases anyway (so we don't have to stage interdepending releases), so yay.
<dAndy> sivang: (offtopic i know) google.com, search for "site:en.wikipedia.org bikeshed"
<OculusAquilae> carlos: ping
<carlos> OculusAquilae: pong
<OculusAquilae> carlos: hi, here konversation's and k3b's translation is ok, but ktorrent still isn't translated (daily build)
<carlos> let me check...
<carlos> OculusAquilae: my fault, sorry, It will appear today
<OculusAquilae> ok, nice 
<OculusAquilae> I'll check again tonight (european)
<janimo> carlos: what's the diff between checking the 'someone should review this translation' box, if I am only making suggetsions, not part of the team?
<carlos> janimo: atm, nothing at all
<janimo> carlos: vs not checking the box.
<janimo> carlos: good, thanks
<janimo> carlos, is what is worked on now in rosetta  too late for release?
<carlos> janimo: I don't understand the question, sorry...
<janimo> there's a bug in the Spanish Xfce interface which noone fixed so far
<Kamion> ah, I won't bother then, I've occasionally tried to use that box to indicate "I maintain this package and it is obvious to me that this translation is wrong"
<Kamion> which happens from time to time
<janimo> like I did an dedit now in rosetta, will it make dapper or only updates?
<carlos> Kamion: well, you, as the maintainer should have rights to edit any translation... I should fix that bug
<Kamion> carlos: that would be lovely, certainly :-)
<Kamion> there are a few installer translations I just know to routinely ignore
<carlos> janimo: the final language pack will be generate on Monday
<janimo> carlos, ah nice then it will hopefully get fixed by then
<carlos> with translations done until Sunday
<janimo> ok
<infinity> mdz: Second publisher run going for OOo binaries.
<infinity> mdz: We should be building images in ~25 mins.
<mdz> infinity: woo
<carlos> janimo: you would need to talk with jordi, he's sorting the order of importance for Ubuntu packages (which ones should be translated first)
<carlos> janimo: and he will need some help from you for XFC
<janimo> carlos, ok I'll drop in #rosetta today
* sivang notices he knows some of the answers to the weakest link's question in the backgorund.
<carlos> janimo: #launchpad please, #rosetta is not used
<infinity> Hrm, if this is the last OOo upload of the release, LP's going to list me as the creator of OOo.  That's so not good.
<carlos> infinity: are we building new OO.org packages?
<carlos> :-(
<carlos> OO.org's translations take two days to be imported....
<infinity> carlos: Better start now.  They're all uploaded now. :)
<carlos> infinity: well, it's finishing previous build..
<mdz> carlos: yes, with new untranslated .desktop files!
<carlos> mdz: how did you added those new .desktop files ?
<mdz> carlos: they're not new, but the strings changed
<infinity> Shoehorn and lube.
<carlos> ok
<Kamion> infinity: please reduce OOo's memory usage immediately kthxbye
<infinity> alias openoffice=vim
<infinity> Sure, it won't help a lot, with the way VIM's been bloating in the past 5 years, but it'll help a smidge. :)
<Kamion> heh
<infinity> Dear drescher, If you really loved me, you'd sprout a CPU from the future and insanely fast solid state disks.  Regards, Adam.
<infinity> PS, when you get tat CPU from the future, feel free to use your new AI features to optimise soyuz on-disk.
<Kamion> I'll settle for the queue tool not making me want to get a coffee each time I run it
<infinity> It only makes you want coffee?  Such restraint.
<infinity> Kamion: Are you ready to log in to lithium, batch up some commands, and hover over the [enter]  key? :)
* infinity logs in to all the livefs hosts and does the same.
<infinity> Actually, do we want to bother building new alternates for the new OOo, or should we just do -desktop- CDs?
<infinity> mdz: ?
<Kamion> infinity: yes
<mdz> infinity: yes
<Kamion> tell me when I can start building alternates
<infinity> Kamion: Alright, then.  Batch up some alternate builds, and I'll give the word when the  publisher exits. :)
<Kamion> don't need a new ubuntu-server, do I?
<infinity> Nope.
<infinity> Nothing changed there since the last build.
<infinity> Should just want {u,ku,edu,xu}buntu alternates.
<infinity> "just"
<Kamion> ready when you are
<mdz> infinity: are the new livefses building now?
<infinity> mdz: Not until the publisher exits.  Chicken and eggs and all.
<mdz> oh, still waiting on the publisher
<infinity> Well, I can statr all but amd64...
<Kamion> hardly worth it
<mdz> amd64 is the fastest, isn't it?
<infinity> But since amd64 isn't appreciably faster than powerpc and i386, there's not much point.
<mdz> oh
<infinity> Kamion: No point in re-rolling any ports images, BTW, if you were about to.
<infinity> Kamion: LiveCD is universally broken for various reasons on all of them, and the only thing that would have changed on the alternate is OOo on ia64.. Which no ones actually tested to see if it even works.
<Kamion> ok, no, hadn't queued those up
<infinity> (It just gets it for free from the OOo-amd64 build)
* infinity taps his foot...
<mdz> almost there
* infinity wonders how many people are doing the "ps axu | grep 1004" dance on drescher right now.
<Kamion> 'ps -u lp_publish xf' is easier to remember
<Kamion> hm, 'ps -u lp_publish f' I mean
<infinity> potayto, potahto.
<Keybuk> watch "ps f -u 1004" ? :)
<Kamion> let's call the whole thing off
<Keybuk> because then you get to say "P.S. F.U" :)
<Keybuk> infinity: you say potato, I say vodka!
<infinity> There, mirrors triggering.
<infinity> Kamion: Go! :)
<mdz> go go gadget cdimage
* ajmitch sits back & watches the action
<Kamion> going
<Kamion> you know I should've put an echo in between cd builds there, oh well
<Kamion> not to mention screened it ...
<infinity> screen is for the weak.
<infinity> I say that because I also forgot to screen the livefs builds. :)
<infinity> I'm sure my DSL will hold up for the next hour.... Maybe...
* infinity fidgets nervously.
<Kamion> we rock
<infinity> Kamion: Are you running the alternate builds serially?
<Kamion> yes, I'm still in habits due to a machine with crap I/O
<infinity> (So when livefses start rolling in, I can do livecd builds in parallel..)
<Kamion> sure
<Kamion> although most of the alternate builds will be done by that time
<Kamion> the livefs builds are serial, I presume
<infinity> Show off.
<Kamion> not my fault your stuff is slow ;)
<infinity> Yeah, I need to spec (and allot myself time for) livefs build re-engineering during edgy.
<infinity> I'm pretty sure I can cut the build time nearly in half in some cases.
<infinity> I just don't feel the urge to do it in the last week before release.
<Kamion> the layered-unionfs idea would be great to have if it's at all feasible
<Kamion> though I guess the ubiquity code to work around the lack of that is relatively stable
<infinity> Even if it's not, I can simulate it with a deboostrap cache.
<janimo> Kamion: for the release, you'll take care of the  xubuntu gfxboot new image too right?
<janimo> converting usplash->to rle, etc
<Kamion> janimo: how about I start on it now while waiting for stuff to build
<janimo> Kamion: cool, there's a bug filed, but you can just get xubuntu-artwork
<infinity> janimo: Did up upload omeg's usplash image already?
<janimo> infinity: yes
<infinity> janimo: I might want to grab xubuntu-artwork and fix it a bit. :)
<janimo> infinity: ok go ahead :)
<Kamion> yes I have the bug here
<janimo> hmm?
<janimo> I knew it could not be the last...
<infinity> Yeah, I need to cut out the progress bar, since we did so for ubuntu and edubuntu.
<infinity> (To get rid of the "glow" around it)
<infinity> No big deal.
<janimo> oh, I liked that glow :)
<janimo> anyway
<ogra> me too :)
<Kamion> huh, the progress bar is part of the image now?
<Kamion> I'll cut it out for the gfxboot image
<ogra> the backgroung
<janimo> but the gfxbott image does not use the glow no, so should not be blcked on this?
<ogra> s/g/d
<infinity> janimo: Well, you can keep it if you want.  We cut it from ubuntu after some long discussions on the matter, then omeg decided he'd rather they were consistent, so figured we should cut it from all of them.
<infinity> Kamion: Yeah, doesn't affect you, just cut it out. :)
<janimo> infinity: +1 for consistency
<janimo> so whatever ubuntu uses, I just was not aware of it
<janimo> so how does one know how much time is approximately left if there;s no progress bar?
<Keybuk> janimo: progress bar consists of a backing colour and a foreground colour
<Keybuk> the backing colour is lighter than the backgroundf
<infinity> janimo: Err, the progress bar is drawn by usplash.  The bar you see on your PNG is entirely covered up, except for a small glow around the edges.
<Keybuk> both colours are drawn by usplash, over top of whatever was in the PNG there anyway
<morgs> Kamion: bug 46534
<Ubugtu> Malone bug 46534 in ubiquity "Infinite loop selecting drive to partition" [Normal,Unconfirmed]  http://launchpad.net/bugs/46534
<Keybuk> when I did the ubuntu art, I cut the artwork to just the logo to reduce size and stuff
<Keybuk> and mostly because I didn't realise there was a glow there ;)
<infinity> morgs: That's fixed in the images we're building right now.
<morgs> infinity: thx!
<janimo> Keybuk: so now you're on the art-team too ;) ?
<Keybuk> janimo: no, I'm on the "infinity's bitch" team
* infinity cracks a whip.
<ogra> janimo, Keybuk is older than the art team as launchpads emblem art directory
* Keybuk yelps with a combination of pain and pleasure
<infinity> The emblem art director?
<ogra> yeah :)
<infinity> Keybuk: I have you to blame for my lp-buildd bricks-and-spade emblem? :)
<Keybuk> ogra: heh, I've been futzing with ubuntu's artwork for longer than that; I'm vaguely responsible for the ubuntu logo lettertype
<Keybuk> infinity: no, I just did the ubuntu-code-dev hammer (by copying an icon, not exactly rocket science)
* infinity keeps meaning to change that, but after doing emblems for X, archive, and security, I got bored.
<mdz> morgs: sounds like a duplicate of bug 46398
<Ubugtu> Malone bug 46398 in ubiquity ""Select a disk" loops forever..." [Major,Fix released]  http://launchpad.net/bugs/46398
<infinity> Keybuk: I hope you appreciate the effort that went into the archive emblem.  You have no idea how hard it is to make a floppy disk look like a floppy disk at that size without just looking like a little blob of pixels in a box. :)
<sladen> dholbach: what's the deal with the over-sized network-manager logs;  I'm loathed to fix it and create an addition upload as it's a 10MB download for everyone
<sladen> dholbach: OTOH, it's annoying and the latest change has been to resize the *wrong* icon
<dholbach> sladen: i have no idea what you are talking about. I never made any changes to network manager's logs - I didn't even know that network manager *writes* logs
<sladen> dholbach: s/logs/logos/ icons
<morgs> mdz: yes it is a dupe... I did search but clearly only saw open bugs
<Keybuk> heh @ http://modernduck.com/
<dholbach> sladen: are you talking about gnome-netstatus applet?
<Keybuk> infinity: but we don't SHIP on floppies
<sladen> dholbach: yes, bug #34521, currently assigned to you
<Ubugtu> Malone bug 34521 in ubuntu-artwork "network monitor's icon have too much unused space" [Wishlist,Confirmed]  http://launchpad.net/bugs/34521
<infinity> Keybuk: We should. :)
<dholbach> sladen: ok, so that's not network-manager
<infinity> Keybuk: Go back to our roots... But instead of downloading a few dozen floppies, now you get thousands!
<sladen> dholbach: yes.  s/network-manager/gnome-netstatus/g;s/logs/icons/g
<dholbach> sladen: wait for ubuntu-artwork 24
<dholbach> sladen: i uploaded it, but it is currently held for the RC freeze
<ogra> infinity, what became of the masterplan to ship on punchcards ? 
<sladen> dholbach: is it already fixed in there, or does it need adding to there?
<sladen> dholbach: ah
<Kamion> morgs: I do read my e-mail too ... :-)
<dholbach> sladen: you can try http://daniel.holba.ch/ubuntu/ubuntu-artwork_24_all.deb as well
<infinity> ogra: We all became dirty hippies who wanted to save the trees.
<ogra> infinity, plastic cards ;) 
* morgs is a bit overzealous today
<Kamion> but thanks for the effort
<morgs> Kamion: thx, I'll go away now and wait patiently :-)
<Kamion> ogra: trees -> compression over lots and lots of time -> oil -> plastic
<Keybuk> infinity: no doubt Mithrandir can come up with some sick initramfs/unionfs/etc. trick that means we can do a LiveFloppy
<ogra> bah :)
<infinity> Keybuk: Dude, ew.
<fabbione> Keybuk: lol
<Keybuk> boot with the first one (boot loader) that asks you to insert each subequent one until it's got all of the kernel and initramfs together, then boot those to get you to insert the rest and build up the rofs
<infinity> Keybuk: You're SO gonna get it in Paris for that.
<infinity> Hrm, our kernel is JUST over floppy-sized now.... I hadn't noticed that we'd crossed that barrier.
<ogra> Keybuk, with gnome and everything ? 
<Keybuk> ogra: of course
<Keybuk> we'd never have to worry about it being oversized
<Keybuk> JUST ADD MORE FLOPPIES! :D
<infinity> FloppyOffice could set new records for launch time.
* ogra remembers his CDrom starting even if he hovers over the gnome menu ... you'd need a lot of prompts for the right floppy 
<infinity> Especially if you need to keep inserting old floppies to page data in.
<Kamion> you'd have to find a machine that can only boot off floppies but yet has enough memory to assemble it all
<infinity> "Please insert floppy #258 ... <grind, grind> ... Please insert floppy #134"
<infinity> Kamion: Assemble, aschmemble.  You keep a table of which floppy has which parts of the FS, and you just keep swapping back and forth.
<infinity> Random access floppy array.
<iwj> It should be a kernel block device driver with a kernel-provided graphical dialogue box to pop up and ask you to change the disk.
<Keybuk> given the failure rate and typical half-life of floppies these days, you'd probably have to do some kind of RAID
<infinity> Keybuk: Floppy RAID makes sense, yes.
<ogra> lol
<iwj> `Floppy no #134 has gone bad.  Please remove it and throw it away.'
<infinity> (I wondered why it wasn't built into the spec in the first place, like it is for CD audio, for instance)
<iwj> infinity: Because the hardware used to be reliable enough that it worked properly.
<_ion> http://ohlssonvox.8k.com/fdd_raid.htm
<iwj> Nowadays floppies (the disks) are cheap but dreadful.
<infinity> iwj: True.  The drives were better, and no one assumed you'd keep a floppy for 10 years either, I suspect.
<morgs> http://ohlssonvox.8k.com/fdd_raid.htm
<Keybuk> I actually went out of my way to ensure I got a floppy drive in the AMD64
<Keybuk> and I've never used it
<infinity> morgs: You're echoing...
<iwj> _ion, morgs: That lacks the `please insert ...' factor.
<infinity> Keybuk: I had to scam one from another box when I build Zofia's amd64 machine, just to get the &@#$$@ SATA controller recognised by the WinXP installer.
<dholbach> mdz: ok with uploading  http://librarian.launchpad.net/2922282/legacy-icon-mapping_xfce_step_2.diff ? that would add more icon symlinks for the XFCE guys, making them happier - what do you think? (it will cause the icon sets to have to be rebuilt, but I think I'd have uploaded them at least once anyway)
<Keybuk> infinity: heh, which controller?
<infinity> Keybuk: (since floppy is still the ONLY method MS gives you for loading SCSI drivers in the installer)
* morgs reads before typing
<ogra> hey, lets user the elastic 720k ones .... ubuntu "the first distro with wobbly media instead of wobbly windows"
<infinity> Keybuk: Just a plain old VIA southbridge of some sort or other.  Just happened to be newer than XP.
<Kamion> Ubuntu and Kubuntu alternate builds are done, BTW
<omeg> Alternate builds?
<Keybuk> omeg: the CD formerlly known as "install"
<ogra> omeg, come over to edubuntu, we'll keep the familiar old names like live and install ;)
<infinity> I love this quote: I was able to transfer "DEVO Uncontrolable Urge.mp3" which is 3.6 MB in 32 seconds. Which is pretty good I think.
<Kamion> "alternate install CD"
<_ion> infinity: :-)
<omeg> Er, I'm sure that new way of naming CDs will make sense once I get them.
<infinity> mdz: Oh, if you're curious, amd64 was actually the slowest livefs build, not the fastest.
<infinity> (Just barely)
<mdz> dholbach: is that last hunk a whitespacechange?
<mdz> infinity: interesting, why?
<mdz> powerpc used to be slowest by a good margin
<infinity> mdz: Because terranova and royal are beasts, I suspect.
<infinity> mdz: PPC useed to be the slowest before it got a 64-bit kernel.
<dholbach> mdz: I suppose so - it's a patch somebody from the xfce guys contributed
<infinity> mdz: Then the PPC machines becamse the speed demons of the DC.
<infinity> became, too.
<mdz> dholbach: seems harmless enough
<dholbach> mdz: ok cool
<janimo> dholbach: thanks, is this from nomed directly or upstream tango?
<Kamion> janimo: done; I'm afraid you'll have mismatched gfxboot splash images for the RC though, as I didn't do it in time for the Xubuntu alternate install build
<dholbach> janimo: I applied the upstream change already
<ptlo> heya all. i've heard rumors that translation deadline has been pushed to 28th instead of today, is that true? (the -translator list doesn't mention it)
<janimo> Kamion: np, thanks
<dholbach> janimo: it's from nomed, yes
<Riddell> I take it it's still OK if openoffice.org2 packages can't be installed by the CD builder
<janimo> Kamion: unless OOo needs another build :)
<infinity> Riddell: Yeah..
<infinity> Kamion: Were we ever going to look at that archive cruft/buggery, or just blindly ignore it? :)
<janimo> ptlo: I was told this Sunday is the last day
<Kamion> infinity: I was certainly hoping to do something about it before release
<Kamion> Riddell: but in the meantime, yeah, ignore that
<Kamion> Edubuntu alternate install builds done
<ogra> thanks :)
<ptlo> janimo: thanks
<ogra> sladen, ltsp-4.2 installs should be treated like firefox or flash installs from the binary packages in malone the implementation differs to much from ours to easily support it 
<infinity> New ubuntu -desktop- CDs ready for testing.
<fabbione> infinity: danke
<ogra> sladen, but feel free to subscribe me to all such bugs :)
<sladen> ogra: which is your prefered 'generic package' to have LTSP-related bugs assigned to?
<ogra> ltsp :)
<ogra> but 4.2 isnt supported its a completely separate implementation that installs a comeplete chroot from a 200MB tarball ...
<mdz> Kamion: are the desktop builds all done?
<Kamion> mdz: infinity's doing those; Ubuntu's done, don't think the others are
<infinity> mdz: No, just Ubuntu desktop builds.
<ogra> so thats upstream ltsp.org stuff ...
<Kamion> janimo: Xubuntu alternate install builds done
<infinity> So, do we reset the table to all ??s before we get started on this batch?
<janimo> ok, rsyincing
<_ion> dholbach: Re: bug 40607, generally everything seems to work very well with the patch, but there's one problem: the "close" button in tabs is very small, but the dialog-close icon isn't scaled down, instead only its center is shown. Any thoughts?
<Ubugtu> Malone bug 40607 in tango-icon-theme-common "Ok/Cancel buttons" [Normal,Unconfirmed]  http://launchpad.net/bugs/40607
<janimo> Kamion, I wonder if the Xubuntu text should say 128M of ram instead of 192. The alternate CD installs and somewhat runs on 64M too
<Kamion> oh, Xubuntu's still mirroring, meh
<Kamion> janimo: how much memory does it take to do a desktop CD install on Xubuntu?
<Kamion> that's the relevant number
<janimo> Kamion, 128M w/o swap worked in qemu for me
<giftnudel> more then 64
<Kamion> janimo: ok, sure, I'll change the text for the next build then
<infinity> "As much as python wants, muahaha"
<janimo> giftnudel:  64M is for the alternate install
<giftnudel> yes
<dholbach> _ion: somebody told me that stock icons were in 20x20 - maybe that's a problem
<dholbach> _ion: I don't know for sure
<giftnudel> janimo: the desktop needs more than that
<janimo> 128 and no swap, exactly as the OLPC specs :)
<ogra> irgh, where does this awful ugly g-p-m icon come from =
<janimo> giftnudel: yup as I said desktop 128, alternate 64
<giftnudel> janimo: yes, i didn't get that
<_ion> dholbach: Well, there's a 16x16 dialog-close icon in Tango. But apparently only the middle 9x9 of a close icon is shown in the tabs' close buttons.
<Kamion> janimo: the actual alternate *install* should work in 32MB; but it might take more to run the desktop I guess
<dholbach> _ion: that I don't know.
<_ion> Seems more like a Gtk problem than an icon theme problem.
<ogra> dholbach, did the hicolor theme change wrt g-p-m ? i dont have the beautiful green battery in gartoon anymore
<janimo> Kamion: well I run it on a 64M laptop. It is slow though
<dholbach> ogra: gpm 2.14.x doesnt have icon theme lookup in its code
<janimo> especially firefox
<ogra> gah
<ogra> thats evil
<dholbach> ogra: I changed the 'hardcoded' icons to be the ones our designer made
<ogra> it looks awful since it doesnt match gartoon at all anymore
<Kamion> janimo: BTW I committed a d-i change yesterday that should make it snappier on slow machines - stopped cdebconf having to save its templates database between every installer step
<janimo> Kamion: but mentioning 128M is ok for both I gues
<Kamion> (upstream, not dapper)
<janimo> so edgy?
<Kamion> yeah
<ogra> dholbach, cant you just use them in the icon theme ? so others have a fallbach that doesnt look like a "heizdecke" ?
<dholbach> ogra: read my last sentence :)
<Kamion> janimo: limits changed to 128MB for Xubuntu desktop CD; I've made it quote memory requirements on the desktop CD page as well as the alternate install CD page too
<dholbach> ogra: gpm 2.14.x doesnt have icon theme lookup in its code
<janimo> Kamion: thanks.
<ogra> grmbl ... i thought that was added with 2.12.x already
<ogra> dholbach, sorry then ...
<mvo> dholbach: that sounds like a edgy spec: bring icon-theme suppoer to the world
<Kamion> janimo: oh, you have some uninstallables on your CD, looks like oversizing
<Kamion> janimo: http://cdimage.ubuntu.com/xubuntu/daily/current/report.html
<janimo> ohh
<janimo> since yesterday?
<Kamion> janimo: adding language-support-* to the CD is ambitious, although I guess you might have space if anyone does
<Kamion> janimo: dunno, I just checked today
<ogra> mvo, the code for g-p-m theme support is there since ages... its just not committed to any released version it seems
<janimo> rigth I added 15 langpack yestreday but to desktop cd
<Kamion> yesterday had language-support-{en,es} uninstallable on powerpc too
<Kamion> http://cdimage.ubuntu.com/xubuntu/daily/20060524/report.html
<janimo> it's most;y ppc stuff
<janimo> as yesterdays install was tested by Gloubiboulga and the only hitch was the ltsp thing
* mvo is off for lunch now
<infinity> Yeah, PPC's CDs are a bit tighter, since it has to ship two kernels.
<janimo> oh and I added the langpacks only to 386 and amd64
<janimo> so it may be something else
<Kamion> janimo: amd64 is fractionally oversized (.25MB); powerpc is 3MB over
<Kamion> I'm pulling your seeds now to have a look
<janimo> somewhere I can see these numbers?
<infinity> You can see the exact numbers in the filesizes of the generated images. :)
<infinity> You can get pretty good guesses from running germinate against your seeds.
<Kamion> http://people.ubuntu.com/~cjwatson/cd-build-logs/xubuntu-daily-20060525.log, search for "CD 2 will only"
<infinity> (Which is handy if you're playing with changes to langpack shipping and such)
<Kamion> infinity: no you can't actually in this case, unfortunately
<Kamion> (filesizes of generated images)
<infinity> Kamion: Oh, right, it's overflow.
<Kamion> debian-cd crops to 700MB internally and overflows onto another CD - it's only visible in the build log
<ogra> xubuntu oversized ?
<infinity> Kamion: Was only thinking oversize, not overflow.
* ogra cant belive that :)
<infinity> ogra: He has WAY more languages supported than you. :P
<Keybuk> http://www.empireonline.com/news/story.asp?NID=18858
<infinity> He may have just gone overboard a bit.,
<Keybuk> oops, ww (but funny anyway)
<ogra> infinity, you mean more than one ? 
<janimo> ogra, more than 15 ;)
<ogra> :P
<Kamion> janimo: you have a crapload of language-support-* on all architectures; would be easy to trim that
<ogra> janimo, make that 14 (at least on ppc and amd64) ;P
<janimo> Kamion: right. So I'll take some out of ship right?
<Kamion> janimo: yeah, you can make some [i386 amd64]  or [i386]  -specific if you like
<Kamion> and yes, as infinity says, germinate is handy for judging the effects of seed changes in advance
<Keybuk> indeed, that's what germinate was originally designed for ;)
<Keybuk> rather than actually driving the archive changes
<_ion> dholbach: http://librarian.launchpad.net/2924006/close-problem.png (screenshot), http://librarian.launchpad.net/2924007/close-solution.png (mockup)
<mdz> dholbach: I still get that problem where I can't drag files out of example-content due to it being read-only; did you or seb128 find any more info about that?
<dholbach> mdz: hum, it works nicely for me, are /usr/ and /home/ on different partitions? I just remember something about that.
<heno> dholbach: that's what I get too, but most people may not set it up that way
<dholbach> _ion: I see the problem.
<mdz> dholbach: no
<dholbach> heno: *did* you set it up that way?
<dholbach> hrm
<mdz> everything on /
<heno> dholbach: separate partitions, yes
<mdz> dholbach: this is on the live CD
<mdz> jamesh: around?
<heno> mdz: so it's sort of expected behaviour, no?
<jamesh> mdz: yeah
<heno> except that it will confuse new users
* Kamion starts pre-publishing stuff to releases.u.c
<dholbach> mdz: oh right... well that works for me.... could you try    gnomevfs-copy /usr/share/example-content/Experience\ ubuntu.ogg ~    and see if that gives any output?
<infinity> Kubuntu -desktop- images are all ready.
<janimo> Kamion: so will the ppc and amd images need a rebuild for RC? I made the russian lang support pack i386 only (~5MB)
<mdz> doko_: ping
<dholbach> mdz: he said he was bitten by the mexican bug, when we talked yesterday (briefly)
<Keybuk> sure, he's just hiding because of all the pain and suffering OO.o has caused
<Kamion> janimo: yeah, let me know when
<mdz> Keybuk: and I just found another bug
<heno> dholbach, mdz: FWIW, there is a section in 'about-these-files' that explains how to copy them to your home dir
<mdz> Keybuk: https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/46544
<infinity> Keybuk: Sometimes, conflict avoidance /is/ rational.
<Ubugtu> Malone bug 46544 in openoffice.org "Launchpad integration points to Breezy package" [Normal,Unconfirmed]  
<Keybuk> mdz: do we have any clickthrough states for lpi?
<Keybuk> uh, stats?
<infinity> mdz: Ahh, at least that doesn't feel terribly RC critical.
<mdz> Keybuk: no idea
<Keybuk> maybe I should ask in the right channel
<mdz> infinity: no, but should be fixed for final unfortunately
<impaque> hello, i just wanted to ask with what CFLAGS is majority of packages for ubuntu built with?
<infinity> mdz: I can deal with more uploads to fix stuff for final.  I just refuse to upload again for RC. :)
<Keybuk> imbrandon: -pipe -funroll-loops
<imbrandon> ?
<Keybuk> oh, wait, UBUNTU :)
<impaque> Keybuk: yes, ie. majority of it's packages. :)
<infinity> mdz: If doko's down for the count, though, I don't mind fixing this particular typo after RC.  It's trivial, afterall.
<jamesh> -pipe makes programs run faster, doesn't it?
<Keybuk> impaque: we don't use any
<Keybuk> just -g -O2 as you'd expect
<infinity> (We do use -pipe, actually, not that it makes any difference anywhere but on the buildd)
<jamesh> :)
<impaque> Keybuk: ok, no -mcpu?
<Keybuk> infinity: oh, wow, we should so press release that! :)
<impaque> infinity: :D
<mdz> infinity: actually the bug is that it's hardcoded at all.  I didn't realize it was
<infinity> And we override -march/-mcpu on i386, yes.
<mdz> but I guess we need to settle for fixing the hardcoded URL for dapper
<impaque> infinity: ok, thanks!
<infinity> mdz: Would you prefer that it goes to the more generic URL?
<Keybuk> -m*mumble* 486 -m*whisper* pentium4 isn't it?
* Keybuk can't remember
<mdz> infinity: I'd prefer it used launchpad-integration like everything else
<mdz> Keybuk: no, those are the defaults now
<infinity> -mtune=pentium4 -march=i486
<Kamion> I'm going to have to work out how lpi works for ubiquity and oem-config in edgy, I guess
<infinity> But yes, those are the default now anyway, and I'd love to just scrap gcc-opt completely.
<impaque> infinity: so, no i386. and, yes, there is -mtune?
<infinity> mdz: And where would lpi send users?  The generic URL?
<mdz> infinity: it looks it up in lsb_release
<Keybuk> infinity: oh, they renamed -mcpu to -mtune; wow, I may actually remember which one does what now
<Keybuk> impaque: libstdc++ doesn't support i386 ... cf. Debian passim.
<mdz> whereas oo.o apparently does this: ++                                      rtl::OUString aURI( DEFINE_CONST_UNICODE( "https://launchpad.net/distros/ubuntu/breezy/+sources/openoffice.org2/+gethelp" ) );
<ogra> meh
<infinity> mdz: Ahh, kay.
<mdz> infinity: don't forget s/org2/org/ as well when you fix it
<infinity> mdz: I'll test the URL before I upload. :)
<mdz> that renaming was a change that I VETOED btw
* infinity doesn't trust his non copy-and-paste skillz.
<Keybuk> <mpt_> Get Help Online has never been implemented
<mdz> Keybuk: s/$/ yet/
<impaque> thanks
<ogra> mdz, http://cdimage.ubuntu.com/daily/20060525/report.html agrees with you :)
<ogra> (will we get rid of these for final ?)
<Kamion> I hope so, yes
<infinity> ogra: Yes.
<ogra> ah, good
<Kamion> I'll look at it when we're past RC, and figure out the best answer
<Keybuk> mdz: right, that's what I thought -- we just used the gcc defaults
<janimo> Kamion: seeds are mirrored now
<infinity> Keybuk: Well, GCC only recently changed to match gcc-opt..
<infinity> Keybuk: But NOW, we really should just drop gcc-opt like a hot potato, IMO.
<Keybuk> infinity: I still remember with a cold sweat the day that gcc enabled optimisation by default
<Keybuk> and debugging got that little bit harder
<mdz> Kamion,ogra: curiously, Fedora's installer doesn't seem to suffer from bug 22930
<Ubugtu> Malone bug 22930 in gtk "Mouse focus doesn't return until mouse is moved off button" [Unknown,Unconfirmed]  http://launchpad.net/bugs/22930
<ogra> hmm
<infinity> I wonder if they've fixed GTK, or hacked around it in their installer...
<ogra> i know there are workarounds on C level
<infinity> If they've fixed GTK, *I want that fix*.
<ogra> i guess they just work around it in the app ... but i might be wrong
<Keybuk> the cheeky thing is that the RH GTK+ maintainer is the same as the Debian one
<mdz> if they worked around it in the app, we want that fix too
<janimo> what is affected now by this bug besides hwdb?
<mdz> janimo: ubiquity
<mdz> very prominently
<infinity> Yeah, and it's REALLY annoying in ubiquity.
<janimo> I tought it was worked around
<ogra> janimo, the logoutr dialog we have as well
<janimo> ogra, xfce logout dialog had it but got fixed
<ogra> janimo, HOW ?
<infinity> Less of an issue for the logout dialog, since you're not likely to have your mouse over one of the buttons as the window comes into focus.
<janimo> it may be more than only one bug thought
<ogra> thats what we're looking for !
<infinity> Ubiquity, where you just hover over the "next" button is horrible.
<janimo> ogra, it messed with direct X grabs, and needed to be told to mess with them in another way
<Kamion> mdz: they probably don't (need to) disable buttons between steps
<janimo> so was not clean gtk anyway
<Kamion> yes, that bug is extremely annoying
<ogra> infinity, i know where the logout dialog appears after using it twice ... so my mouse usually is where the button appears
<Kamion> if you never disable/enable buttons, you don't encounter the problem
<Kamion> ogra: do you happen to know the C-level workaround?
<ogra> mdz, i'll dig through it to find out what RH did before final
<ogra> Kamion, nope
<ogra> Kamion, see comment 18 here http://bugzilla.gnome.org/show_bug.cgi?id=56070
<Kamion> janimo: thanks, rebuilding
<Ubugtu> Gnome bug 56070 in gtk "Can't click button after setting it sensitive." [Normal,Reopened]  
<mdz> Kamion: hmm, I wonder if that would actually be better
<ogra> and comment 19's attachment
<Kamion> the hack in comment 19 definitely wouldn't be acceptable
<Kamion> I'm not hooking motion-notify-event and sitting computing pointer positions all the time
<ogra> yep
<janimo> but the logout dialog buttons are not disabled at any point are they?
<Kamion> mdz: possibly. it's a useful visual clue, but the cursor change is probably sufficient for that
<Kamion> I'd have to teach the back/forward handlers to do nothing in that case
<ogra> janimo, nope, but if your mouse is above the one you want to click if the dialog appears, it is unresponsive
<janimo> ogra: yes i know, that's wh I think it's a deeper bug or more than one bug
<ogra> janimo, its a gtk bug 
<ogra> a very old one
<Keybuk> Kamion: there's an easy hack to that
<Kamion> the logout dialog is only an issue due to FIST-sized buttons :)
<Keybuk> make the button explicitly not sensitive in its click event
<Kamion> Keybuk: what do you mean?
<ogra> Keybuk, ??
<StevenK> I think I get where Keybuk is going.
<ogra> explain it to us 
<Keybuk> Kamion: got WORKRAVE'd there :p
<Keybuk> let me "fix" the demo to show you
<StevenK> Okay. Keybuk can show, since I can't seem to find the words to explain it.
<ogra> StevenK, use gestures :P
<StevenK> They tend not to translate into IRC.
<ogra> depends how wordy you describe them ;)
<Kamion> if you mean "just make the clicked event do nothing if you don't want the button to do anything", that was my plan ...
<StevenK> That's what I was trying to get out.
<ogra> you mean dont fiddle with sensitivity at all
<Kamion> (since I'm already handling clicked)
<StevenK> Kamion: With any visual clue that pressing the button will have no effect at all?
<mdz> i386 desktop CD is good here
<Keybuk> what I was suggesting was explicitly generating the "mouse off" event when you pop open the dialog
<Keybuk> that way, when the dialog is closed, gtk thinks you moved off the mouse anyway
<Kamion> StevenK: well, that's why I set them insensitive at the moment, but we do also set the mouse cursor to busy
<mdz> bug 46544 / bug 46546 were the only issues I encountered
<Ubugtu> Malone bug 46544 in openoffice.org "Launchpad integration points to Breezy package" [Normal,Unconfirmed]  http://launchpad.net/bugs/46544
<Ubugtu> Malone bug 46546 in openoffice.org "Launchpad integration uses hardcoded URLs" [Normal,Confirmed]  http://launchpad.net/bugs/46546
<ogra> i'm not sure its restricted to the sensitivity handling
<Kamion> Keybuk: ... eww?
<Kamion> Keybuk: though I could see that working ...
<mdz> Riddell: how does kubuntu look?
<Kamion> neat idea :)
<mdz> ogra: and edubuntu?
<StevenK> An ugly ugly hack that we rip out during edgy?
<Kamion> it'd be a relatively contained hack, I guess
<ogra> mdz, ppc missing all others were good in the last build ... i'm just done with rsyncing the recent iso
<Kamion> StevenK: s/during edgy/whenever it gets fixed/; it doesn't look trivial, from the upstream bug
<StevenK> Kamion: Just surround it with the commands: # Eyes closed now please
<ogra> mdz, https://wiki.ubuntu.com/Testing/CurrentEdubuntu
<StevenK> Er, s/commands/comments/
<Keybuk> Kamion: it may just be button.leave() in PyGTK
<mdz> ogra: there's an edubuntu section on /Current, use that instead
<ogra> hmm ...
<sladen> dholbach: yes, -24 fixes it.  But the main netstatus icon has still be reduced almost to the point of invisibility
<ogra> mdz, so should i transfer all data from the sheet the edubuntu-testers team uses ? 
<infinity> ogra: New edubuntu -desktop- CDs are ready.
<ogra> infinity, thanks
<Riddell> mdz: still syncing today's images,last night was all perfect on all 6 CDs
<mdz> ogra: yes, if it applies to the same build
<ogra> yep, as i said we used the url i just posted for all tests
<iwj> Is Testing/Current supposed to have the new version number in it ?
<infinity> iwj: Probably.  And it should probably get all the fields reset to "?"
<janimo> will there be separate announcements for derivatives?
<Kamion> Keybuk: looking at gtkbutton.c, I don't think that would be enough; looks like I'd need an explicit button.emit('leave-notify-event')
<iwj> infinity: Willdo then.
<Kamion> er with an event parameter there too
<infinity> iwj: Don't reset the -server stuff, we didn't build new -server images.
<dholbach> sladen: I agree - I will pass it on.
<iwj> Are there going to be new DVD's too ?
<iwj> infinity: Noted.
<infinity> Kamion: Shall we spin new DVDs?
<Kamion> or maybe gtk.main_do_event() or something
<Kamion> anyway, later
<Kamion> infinity: sure, I'll start on that
<Kamion> after this xubuntu build
<Kamion> actually, I'll start it now
<mdz> yay for parallel CD builds
<ogra> Riddell, do you plan to fix the "KDM enables usplash on logout" bug before final ? 
<iwj> New {,x,k,ed}ubuntu too I take it.
<infinity> iwj: yes, they've all been re-rolled, desktop and alternate.
<infinity> iwj: Well, Xubuntu images are still being rolled, but otherwise what I said is true.
<iwj> Right.
<iwj> I'll leave the FAILs in but annotate them with the old version number.
<Kamion> janimo: Xubuntu alternate re-rolled
<Riddell> ogra: I will take another look at it, but I can't promise to have it working in all cases
<janimo> Kamion: thanks
<Riddell> it does work in the majority of cases at the moment
<Kamion> janimo: you seem to be within size limits now
<ogra> Riddell, ok ... seems people using ltsp.org ltsp have that problem as well
<infinity> janimo: You'll have Xubuntu -desktop- stuff shortly... Just waiting on a slow buildd.
<infinity> "Slow"...
<janimo> infinity: oh I tought desktop was done already?
<janimo> as it did not need rebuild
<infinity> janimo: No, xubuntu was last on my list...
<janimo> ok
<infinity> janimo: You use ubiquity, yes?
<janimo> infinity: yes
<infinity> janimo: If so, then you needed this rebuild. :)
<janimo> :)
<Riddell> ogra: what's the issue they have?  there's a couple of problems there
<janimo> Kamion: so is the ltsp fix in RC or not, I did not get that from the changelog
<ogra> Riddell, bug 45427
<Ubugtu> Malone bug 45427 in kdm "quitting kdm session on xdmcp terminal(ltsp) causes usplash to appear on server session" [Normal,Needs info]  http://launchpad.net/bugs/45427
<Kamion> janimo: there's a workaround in place for RC
<janimo> it may need ot be mentioned as a known issue if it is in RC
<janimo> ah great
<Kamion> janimo: (assuming it worked properly)
<Kamion> was basically preseeding ltsp-client-builder/run=false
<Riddell> ogra: right, fun
<Kamion> janimo: I'd like confirmation that that workaround has worked properly though
<janimo> Kamion: sure
<mdz> Kamion: 2-disk loop fix confirmed in the current build
<Kamion> mdz: hooray
* Keybuk spanks rsync
<Keybuk> it keeps hanging on me today
<Keybuk> rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<fabbione> Keybuk: see #c
<Keybuk> heh
<ogra> Keybuk, i also have reports in #edubuntu ... is it the server ? 
<fabbione> ogra: yes
<infinity> s/server/servers/
<Keybuk> it would appear to be the server, yes
<jsgotangco> yeah
<jsgotangco> its kind of erratic
<Keybuk> infinity: I assumed it was just Znarl reading from a piece of paper and typing very fast
<iwj> Urgh, wikis don't make a very good database.
<fabbione> sfllaw: one of the bugs has a patch.
<fabbione> sfllaw: my hang was due to a GPS serial port connected
<sfllaw> Bug 41679 is fixed upstream.
<Ubugtu> Malone bug 41679 in wvdial "wvdialconf does not write conf file " [Unknown,Unknown]  http://launchpad.net/bugs/41679
<sfllaw> Bug 31272 has a patch.
<fabbione> sfllaw: but i we just don't have time to fix it now with RC out
<Ubugtu> Malone bug 31272 in wvdial "wvdial modem detection hangs dapper installer" [Unknown,Unknown]  http://launchpad.net/bugs/31272
<fabbione> or almost
<sfllaw> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361040 is a simple problem with "set -e" aborting the configure script.
<Ubugtu> Debian bug 361040 in wvdial "Subject: wvdial fails to configure on testing" [Important,Open]  
<Kamion> sladen: surely it would be better for bug 38333 to be a duplicate of bug 43114, not the other way round
<Ubugtu> Malone bug 38333 in ubiquity "No Hibernation: '/etc/mkinitramfs/conf.d/resume' is not created" [Normal,Fix released]  http://launchpad.net/bugs/38333
<Ubugtu> Malone bug 43114 in acpi-support "GDM Choices Cause Sleep and Hibernate Failure" [Major,Needs info]  http://launchpad.net/bugs/43114
<Kamion> the latter has better status and contents
<fabbione> sfllaw: i think if you want that stuff in, the person to talk is mdz/Kamion.
<sfllaw> fabbione: I personally don't care very much about it making it.
<sfllaw> But mdz's comments in 31272 makes it sound like it's release critical.
<sfllaw> "Sure, just don't forget to disable it before the release if no other solution is found"
<fabbione> sfllaw: ok, so what do you want me to do exactly?
<sfllaw> But then again, it's priority Normal, so meh?
<fabbione> sfllaw: if you want to prepare the package i can upload it for you with mdz blessing
<Kamion> if it's hanging the installer for people, then we can't fix that in updates, so it does need to land before release
<sfllaw> fabbione: Basically, it was to give advice about Ubuntu conventions.
<fabbione> sfllaw: well if it is an RC issue, let's get it fixed and in the archive (after mdz approval)
<sfllaw> fabbione: All right.
<fabbione> sfllaw: that's what i would do
<sfllaw> I'll prepare Ubuntu packages for WvStreams and WvDial.  And send them to you for vetting.
<sfllaw> I don't trust myself to upload directly into the archive yet.
<fabbione> sfllaw: just slam the debdiff somewhere
<sfllaw> Will do.
<fabbione> sfllaw: mdz will like to review it too
<iwj> sfllaw, infinity: I think I've finished with updating Testing/Current now.  It has the new version numbers and I've generally changed uncommented PASS back to ? and added version number to other PASSes and FAILs.
<infinity> sfllaw: You realise you can divine if you're on a serial console with "fgconsole", right?
<infinity> sfllaw: See /etc/init.d/keymap.sh for the hint.
<sfllaw> infinity: That would be stylish!  Thanks.
<Keybuk> iwj: you appear to have nuked my edubuntu pass's entirely
<ogra> Keybuk, wasnt that the plan ? 
<ogra> to erase *all* pass entries ? 
<Keybuk> ogra: iwj left some, for some reason
<ogra> ohoel_, ok
<infinity> sfllaw: That would make you grow a dependency on console-tools, but I suspect that's not a problem.
* ogra waves to ohoel_ 
<infinity> janimo: Okay, Xubuntu -dekstop- CDs finally done.
<janimo> infinity: thanks
<infinity> Everyone: All new images, except for the DVDs should be ready now.  Go forth and test.
<sfllaw> infinity: I could just poke the right ioctls under Linux.  But that's a good pointer.
<iwj> Keybuk: I left (a) DVD's and (b) server installs.
<mdz> Keybuk: rsync isn't treating me very well either just now
<iwj> mdz: Me too.
<iwj> Are these livecd isos supposed to rsync well ?
<mdz> 45 minutes to get edubuntu install rsynced
<Keybuk> mdz: it seems our sysadmins decided today was a good time to break the cdimage servers
* janimo just lost the whole alternate image of yesterday bc rsync
<mdz> iwj: they are very rsync-friendly, yes
<mdz> perhaps there's something going on with the server
<iwj> It currently seems to think it's going to take 3 hours.
<mdz> iwj: in fact they're friendlier than the install CD in this case
<janimo> iwj: that's just the start of the CD
<mdz> Keybuk: is that conjecture or are you in touch with them?
<iwj> Keybuk: (a) new DVDs not out yet and (b) I'm told no new server CCs.
<Keybuk> mdz: see #c
<janimo> where it differs since last image
<ogra> dapper-live-amd64.iso
<ogra>    688642048 100%    2.00MB/s    0:05:28  (1, 100.0% of 1)
<iwj> s/CC/CD/
<mdz> Keybuk: NOOOOOO
<ogra> strage, worked fine here for all isos
<mdz> Keybuk: GRRRRRRR
<janimo> so are these the RC images or candidates for RC?
<infinity> janimo: The latter, but hopefully also the former.
<ogra> yes
<Keybuk> they're the RCCs
<Keybuk> CRCs?
<infinity> janimo: Kamion's pre-publishing them in hopes that they'll pass. :)
<janimo> ah, ok. the pushing them to release.u.c what made me thing they're the RC
<Kamion> they're only pushed to .pool
<Kamion> not visible to general bystanders yet
<Keybuk> iwj: you've changed others from PASS to <version>-PASS though/
<iwj> IJLTS CRCDCDRRCDDC.  HTH.
<Keybuk> but deleted other PASSs
<Keybuk> but confusing
<infinity> Kamion: Are we not publishing -server- on releases?
<iwj> Keybuk: Only when there was a comment.  I didn't want to delete comments since I thought they might be important.
<ogra> mdz, who made that edubuntu table on Testin/Current ? 
<mdz> ogra: presumably sfllaw
<iwj> See `information about older versions' under Howto.
<iwj> ogra: It's possible that my attempts to remove stale passes have messed it up.
<ogra> workstation is missing completely ... and i dont think we're intrested in OEM (i dont even know if we have that)
<infinity> Kamion: Oh, it has its own .pool... I didn't notice that.
<infinity> Kamion: Sketchy. :)
<ogra> iwj, nope, its generally missing stuff
<iwj> ogra: Talk to sfllaw but I think he'll say to edit it to be how you want.
<infinity> Kamion: In that case, it just needs sparc pre-published as well.
<iwj> Well, I think I'll go and have lunch while this image downloads.
<mdz> ubuntu alternate i386 passed here
<sfllaw> ogra: "edit it to be how you want"
<Kamion> infinity: oh, I'll do server in a bit, sure
<Kamion> infinity: I think it'll stop having its own .pool.
<infinity> Kamion: yeah, I was just about to say... Since the image names are unique...
<Kamion> right, it'll just start living with the Ubuntu images now
<infinity> Kamion: And we want -desktop-, -alternate- and -server- all in one HTML index now, right?
<mdz> kubuntu desktop i386 pass
<mdz> infinity: yes
<ogra> sfllaw, yep, thanks ... i wasnt even aware of that table since the edubuntu-testers team used https://wiki.ubuntu.com/Testing/CurrentEdubuntu
<Kamion> infinity: yup, that'll happen automatically
<infinity> Kamion: Spiff.
<Kamion> publish-release is moderately cool like that.
<sfllaw> ogra: Nobody told be about that one.
<infinity> Okay, I'm going to go find some "lunch" before I get back to testing-land.
<sfllaw> And I didn't bump into it.
<Kamion> only moderately, mind. it *is* still a huge pile of shell.
* janimo goes away till the CD is wgetting
<Keybuk> NOBODY BREATHE!  I've got an rsync to 98%
* Kinnison turns blue
<Keybuk> and it appears to have stalled
<ajmitch> Keybuk: I've had an rsync stuck at that for an hour or two :P
<Keybuk> mdz: are you anywhere near Znarl? :)
<ajmitch> I suspect rsync is meant to go at more than 2K/sec
<Kamping_Kaiser> i was hoping to get a package (smbfs) made available on the ubuntu cd, but the SeedManagement wiki page doestn answer the qustion who/how to ask (that i saw)
<Mithrandir> there's surely something weird here, yes.  I'm only getting ~200k/sec.
<fabbione> yes it's all a known problem
<fabbione> rsync is fucked. kthxbye
<ogra> sfllaw, sorry my fault (i guesS)
<Kamion> $ publish-release daily ../ubuntu-server/daily/20060524.2 server poolonly rc
<Kamion> wonkiness. still, it worked
<Keybuk> infinity: 
<ogra> sfllaw, we also have no "desktop or alternate" CDs 
<Keybuk> quest scott% telnet localhost 80
<Keybuk> Escape character is '^] '.
<Keybuk> GET /~scott/dapper-dvd-amd64.iso HTTP/1.1
<Keybuk> Host: localhost
<Keybuk> HTTP/1.1 200 OK
<Keybuk> Accept-Ranges: bytes
<Keybuk> Content-Length: 3172501504
<Keybuk> Connection closed by foreign host.
<Keybuk> (abbreviated, but you get the gist)
<sfllaw> ogra: Good to know.  Thanks.
<sfllaw> What is the syntax to close bugs from inside Ubuntu's debian/changelog?
<Keybuk> sfllaw: there is no syntax
<Mithrandir> sfllaw: nonexistent
<ogra> sfllaw, we decided it would look a bit to funny to call the default CD we ship "alternate" :)
<sfllaw> Ah.
<sfllaw> ogra: Makes sense!
<Kamion> I use "closes: Malone #nnnnn", I also see "LP#nnnnn", "closes: LP#nnnnn", "closes: launchpad.net/bugs/nnnnn", "Malone #nnnnn", and a bunch of others
<mdz> Keybuk: no, or you might not be hearing from him right now
<Keybuk> I use Ubuntu: #nnnn
<Keybuk> mdz: that's kinda what I was hoping ... some ultra-violence
<Keybuk> anyone know if there's a signal I can send rsync to say "save what you've done, and work if I run you again"?
<Keybuk> cause if I ^C it now, it'll have to start all over again :'(
<infinity> Keybuk: --partial
<ogra> isnt that a commandline option you have to give *before* you run into this ? 
<ogra> yeah
<Keybuk> infinity: that's what I've used
<infinity> Keybuk: Oh, a signal if you forgot --partial?  No idea.
<Keybuk> so hopefully it'll resume from the 98% and just do the last 2%
<Keybuk> once I've waited for the "GO AWAY"
* Kinnison always uses -P
<zul> heylo
<mdz> --partial screws you in one case, and saves you in another
<infinity> Keybuk: As for the apache bug, I may know where that's happening... I'll poke it with a stick post-RC, and see if maybe we can squeeze a quick fix in.
<mdz> you need to decide ahead of time which way you're more likely to be fucked
<ogra> is there a reason why the names are in the tables already ? i somehow doubt seb128 will do all edubuntu i386 CD tests today
<Keybuk> which case does --partial screw you for?
<ogra> err amd64
<infinity> --partial screws you when updating images.
<mdz> where is seb128 anyway?
<Keybuk> mdz: holiday
<Keybuk> ogra: *shrug*  I was just going to do powerpc starting at the top
<Keybuk> infinity: it does?
<ogra> mdz, public holiday in france germany and i guess many other countries
<infinity> If you get 50% into a --partial, then it dies, rsync copies the 350MB partial file over your 700MB original.
<mdz> we really need a proper calendar
<Keybuk> infinity: cute
<ogra> mdz, i think there was a mail to warthogs 
<Keybuk> whatever happened to the company hula server?
* Kinnison fires up vmware for another round
<Keybuk> jdub: ?
<ogra> we have a hula server ?
<mdz> ogra: that was like a week ago
<ogra> mdz, yes, but referring to ancestion day iirc
<ogra> (which happens to be today)
<Mithrandir> Ascension day.
<ogra> yes, sorry
<ogra> (german males tend to to drink all day and walk the streets until they fall dead on this day)
<mdz> ogra: right, requiring that I keep it in my head for a week
<ogra> yeah, we should probably have something like the fridge calendar 
<ogra> in friendly ical format
<Keybuk> ogra: aren't you supposed to be off today too?
<ogra> Keybuk, did i ever care what i'm supposed to be ? 
<Keybuk> fair point
<ogra> its the most exciting time of the release, i wouldnt want to miss the fun :)
<ogra> (even its exhausting :) )
<Keybuk> o/~ See androids fighting ... Znarl and Elmo
<TheMuso> c
<Keybuk> WOHOOO!!!!!!!!!!!!!RIO_QWIRO_QWOPEFIO_W$_R()")($
<Keybuk> I HAVE A CD IMAGE!
* Keybuk burns it, quickly, before the illusion vanishes
<sivang> heh
<thom> anyone would think you've never seen one before
<Keybuk> thom: today they are a rare thing
<ogra> only the rsanced ones 
<ogra> *rsynced
* ogra has all 6 edubuntu images :P
<Kamping_Kaiser> hehe
<ogra> edubuntu amd64 workstation PASS ...
<Keybuk> ubuntu powerpc desktop PASS
<Keybuk> hmm
<Kinnison> ubuntu i386 desktop live PASS
* Kinnison runs ubiquity
<Keybuk> why are OpenOffice.org Presentation and Spreadsheet the wrong way round?
<Keybuk> ONLY JOKING
<ogra> heh
<vinboy> ?
<zul> Keybuk: i think you would have people murdering you for some reason :)
<_ion> :-)
<vinboy> r u guys the testers?
<Keybuk> that's a good point, next week I'm in the same room as mdz
<ogra> vinboy, want to be one as well ? 
<mdz> Keybuk: I checked that
<zul> hah!
<vinboy> ogra: nah, my connection is 256k
<Keybuk> oh, wow
<vinboy> too hard to be a tester :P
<Keybuk> it didn't even *wait* before running cron.daily this time
* Keybuk beats Mithrandir up
<mdz> fabbione: if you'd prefer to close #11850 and open a separate bug for this issue, feel free
<mdz> fabbione: but there needs to be a bug open
<Kamping_Kaiser> vinboy, sos mine
<fabbione> mdz: leave that one.. i don't really care
<mdz> Kamion: are the DVDs on cdimage current?
<ogra> Keybuk, heh, utnubu wants to call their rpc-xml too for patch monitorint the "scottwatcher" :)
<ogra> *tool
<Keybuk> "voyeur"
<ogra> *giggle*
<mdz> Keybuk,Mithrandir: is someone working on fixing that?
<Keybuk> Kamion: oh, I think I know what might have crashed qtpartman last time ... I deleted the partition map partition
<Keybuk> mdz: it's in incoming
<Kamion> mdz: Ubuntu is; Kubuntu is building
<mdz> Kamion: thanks
<Keybuk> hey, jono, pull up an RC and start testing! :)
<Kamion> Keybuk: oh, DDTT :)
<Keybuk> well, an RCC
<Kamion> Keybuk: and either qtparted or partman. make up your mind. :) FWIW I think it was qtparted not partman
<Keybuk> Kamion: the traceback said both qtparted and partman
<Keybuk> whatever you have on the Kubuntu CDs :)
<jono> Keybuk: will do :)
<vinboy> are the RC images available somewhere yet/
<Riddell> 12:44 < Riddell> vinboy: no, that's why I'm asking for help testing
<vinboy> ok
<vinboy> thx
<Keybuk> http://cdimage.ubuntu.com/
<Keybuk> pick the daily-live/current of your choice
<vinboy> ok
<vinboy> i prefer to use bittorent
<vinboy> bcoz it has md5 hceck
<vinboy> i had a corrupt download using HTTP last time
<iwj> Ooh, the kubuntu test plan has been much improved.
<Kamion> that's fine, there are torrents there, although they may not be very well seeded at present
<iwj> Wikis are obviously just like USENET in this respect.
<Keybuk> so, you know how Alt+F4 under d-i gives you the log of what it's doing?
<Kamion> yes?
<Keybuk> it doesn't do that on ubiquity
<Keybuk> it doesn't do that AT ALL
<Kamion> hahaha
<mjg59> Oops
<Kamping_Kaiser> lol 
<Kamion> that had never occurred to me
<iwj> Hrm, this disk from my junk pile doesn't seem to be wholly reliable.
<dholbach> Keybuk: haha, did you know about "scottwatcher"? http://people.debian.org/~stratus/scottwatcher/ - I'd be terrified, if I were you :-)
<Keybuk> it hadn't occurred to me either, it was taking a while in the Installing phase, so I just pressed it to watch the log go past for something more interesting to look at
<Keybuk> the interesting thing is that it only appears to close the progress bar window, ubiquiuty carries on happily
<iwj> Excellent, I accidentally ran the installer twice and the second copy exploded with a strange window full of unsubstituted strings plus a stack trace.
<BenC> pretty sure that wasn't supposed to happen
<BenC> I just did an update through update-manager, when I had a "needs reboot" notification already present, and the notification went away after the update
<Keybuk> dholbach: this explains the sudden number of e-mails asking whether we can exclude packages from the nda output
<BenC> nm, it popped up a minute later
<dholbach> Keybuk: um, nda?
<Keybuk> dholbach: the program that generates ~scott/patches/
<dholbach> ah ok
<sladen> Kamion: one of the disadvantages of dup'ing them that way around is that the lower numbered one has been fixed (several months) ago and closed.  Marking it a dup of a bug that has 'gdm' in the title effectively reopens it and against a package that isn't related.
<nomed> hi all
<nomed> janimo around ?
<janimo> nomed: yes
<janimo> hi
<nomed> hi
<janimo> I saw your mails and the xfce commits
<nomed> i met kelnos this morning ...
<nomed> he told me he was fine ..
<nomed> "commits"
<nomed> ?
<janimo> he committed the OFFICE patch to libxfcegui4
<janimo> what do you mean he was fine? fine with something?
<nomed> ohh
<nomed> true
<janimo> and to xfdesktop4
<nomed> hope for xfce4-mixer too
<nomed> not for that ..
<nomed> sent even  a patch to icon-naming upstreamer ..
<nomed> and fixed tango-icon-theme-common
<Keybuk> I can't decide whether it's a bug or not that ubiquity carrys on if you do Alt+F4
<Keybuk> today, it's good :)
<nomed> janimo, i guess now it's complete
<janimo> nomed: I saw Daniel said he'd commit the tango patch
<dholbach> janimo: which one?
<nomed> yep
<nomed> dholbach, icon naming
<nomed> :)
<nomed> i guess
<dholbach> i uploaded it already
<janimo> as for mixer it was not applied, xfce devs do not touch each others' packages
<dholbach> but it's in the queue
<janimo> so whenever mixer mainatiner has time I guess
<nomed> dholbach, thanks for that
<dholbach> de rien
<nomed> janimo, you can add that patch in the mean time
<janimo> nomed: sure
<janimo> as I was not going to update mixer from svn anyway 
<ogra> edubuntu amd64 default install manual partitioning PASS
<nomed> janimo, as soon as i have the time i'll fix the gdm theme ..
<nomed> if nobody did that
<janimo> nomed, thanks. I saw there are 3 variants for teh icons, but they  look the same to me
<ogra> fabbione, any idea why the cursor theme doesnt default to the jimmac theme anymore ? it was compiled in the X server since warty iirc
<nomed> usplash will need the author
<janimo> active, prelight and one I forgot
<nomed> janimo, they are the same yes
<nomed> they should be probably different
<fabbione> ogra: no and X didn't change that 
<janimo> so I think it's enough if I just copy the two icons in gdm
<nomed> and the one for langs
<janimo> nomed, ok take care of it then and let me know when they are ready for upload.
<janimo> thanks
<nomed> k
<ogra> fabbione, yes, i had a very long discussion with daniels about it in hoary, it was set to be the xservers default 
<ogra> seems we now only set it through the artwork package :(
<iwj> I've just reproduced bug 46404 and I think it's RC.
<Ubugtu> Malone bug 46404 in qtparted "partitioner locked up" [Normal,Unconfirmed]  http://launchpad.net/bugs/46404
<iwj> Should I confirm it myself ?
<nomed> janimo, do u know if it exists an svg version of the usplash image ?
<iwj> I suppose it just might be my dodgy disk so perhaps I shouldn't.
<nomed> or if the author is registered to the package in malone ?
<janimo> nomed: I don;t think it makes sense for it to be a svg but I have no idea
<nomed> i guess if not he should
<Riddell> iwj: I'll look at it in a bit
<iwj> Riddell: OK.  I just want to make sure it gets some attention; things like this at this stage are rather worrying ...
<Keybuk> ubuntu powerpc install from desktop PASS
<sladen> nomed: the images for the usplash-* have been hand-optimised.  If you want the shape, you can get that from the Ubuntu logo and try to do some gradients to replicate the usplash look, and you maybe able to do the 'glow' with some low-alpha copies behind the logo
<nomed> sladen, i don't want to hack it :)
<nomed> i just would that the author fox a small issue :)
<nomed> s/fox/fixes
<infinity> nomed: What needs fixing?
<infinity> omeg: Around?
<nomed> infinity, when i select a res of let's say 1024x768
<mantiena> hi all
<nomed> i see clearly two white lines
<sladen> nomed: what's the issue.
<iwj> Is anyone doing any a11y testing ?
<nomed> it looks like it's 2 px smaller
<sladen> nomed: where, can you take a picture.  somebody reported that being related to 640x480 which is used on some machines
<iwj> For example, is ubiquity supposed to be driveable using only the keyboard ?  Because I can't seem to get `Next' to work (!)
<infinity> nomed: This is on the Xubuntu splash?
<infinity> nomed: Cause I was going to tweak it a bit anyway for janimo.  I can look at that at the same time.
<iwj> Keybuk: please save Testing/Current ...
<mantiena> where I should ask about rosetta problems ? my translations (.po files), uploaded yesterday, still not imported into rosetta and now other users are working on outdated translations :(
<Keybuk> iwj: I don't have it open?
<iwj> This page was opened for editing or last previewed at 2006-05-25 13:39:58 by ScottJamesRemnant.  You should refrain from editing this page for at least another 10 minute(s), to avoid editing conflicts.
<Keybuk> *shrug* it lies
<ogra> iwj, i even added my stuff since then
<ogra> (and didnt get that warning)
<iwj> Keybuk: Did you close your edit window without cancelling an edit ?  Or are you reloading the result of a save ?
<iwj> Never reload the result of a wiki save.
<Keybuk> neither
<Keybuk> moin is hallucinating
<iwj> Hrm.
<iwj> Well, I'll edit my thing in and see if that helps.
* Kinnison rsyncs the next image down in his set of tests
<nomed> infinity, https://wiki.ubuntu.com/DanieleFavara?action=AttachFile&do=view&target=xubuntu_usplash_issue.png
<nomed> i think you can see that line i mean .. 
<infinity> nomed: Oh, on the top and bottom?  Cool.
<nomed> yep
<infinity> That's in the original PNG.  Oops.  Easy fix.
<infinity> nomed: I'll fix that when I fix the other thing I'm tweaking it for. :)
<nomed> infinity, perfect thanks
<ogra> edubuntu amd64 live session PASS
<jsgotangco> yay
<iwj> Apparently Kinnison saved it in between my edit start and end.
<iwj> Kinnison: ^
<Keybuk> iwj: it will now allow you to resolve any conflicts caused by that
<Kinnison> iwj: oops, sorry
<iwj> It's strange.  It says `do not just save this page' but having double-checked that's exactly what it seems I should do.
<iwj> Kinnison: It might be moin being mad.  Did you get an edit lock warning ?
<Kinnison> I got a warning for keybuk
<iwj> You should have come here and cleared it with Keybuk then ...
* Kinnison read him saying it was hallucinating
<iwj> I got a warning for Keybuk too and announced here that I was proceeding anyway.
* Keybuk finds moin far easier if you just ignroe the locks entirely
<iwj> Really ?
<Keybuk> and treat it like CVS, resolve the conflicts if you cause any
<ogra> meh, Kamion, the "partition selected more than once" bug is fixed over here, but the screensaver kicks in again in ubiquity during formatting
<Kinnison> iwj: If I managed to blat your edit, I apologise. If you blat mine I know exactly what I did so I can recover
<iwj> Keybuk: That's all very well unless you're trying to do something like my removal of stale passes.
<ogra> i got a warning for iwj now
<iwj> Kinnison: It's OK, neither edit is blatted.
<iwj> ogra: Feh.  Just a mo.
<iwj> ogra: ???  Mad thing, it's warning me about you now !
<ogra> heh
<ogra> saved
<iwj> Seems sane again now.
<iwj> Hey, maybe we should have a collaborative text editor.
<LinuxJones> Yesterday's upgrade seems to have messed up some apps authenticating as root user ie. gksudo gedit <file> spews out authentication errors then hangs :(
<iwj> Or maybe we should have a revision control system.  It would be nice if someone invented something like that, wouldn't it.
<iwj> Or a database.
* ogra wonders what dholbach does with all these mails :)
<ogra> LinuxJones, gksudo gedit <file> ? that cant work ... you need gksudo "gedit <file>"
<Keybuk> ogra: he uses them for bedding material
<LinuxJones> ogra, even running stuff from root terminal won't run ie users-admin
<iwj> su's stupid command line parsing continues to be copied :-(.
<ogra> yep
<ogra> LinuxJones, hmm, works fine here on todays liveCD
<ogra> i just happen to have that running here
<LinuxJones> ogra, I don't see my username in /etc/sudoers has the username (of the account that installed Ubuntu) or am I now required to add my username to the admin group ?
<jdub> Keybuk: pong
<Keybuk> jdub: I didn't ping, I just ordered ;)
<jdub> Keybuk: oh, maybe i missed a line before the "jdub: ?"
<Keybuk> jdub: company hula/calendar server
<jdub> oof
<jdub> hula totally isn't ready yet
<jdub> but yeah, that'd be freaking rad
<Keybuk> something !hula then
<Keybuk> MS Exchange?
<ogra> LinuxJones, yes, the admin group is used since hoary iirc
<jdub> that's what i still have to recommend, unfortunately
<Kamion> sladen: marking an open bug (that's apparently still active and causing a problem) as a duplicate of a closed bug on a different package that *has* been fixed is even worse. If you don't think they're related, then don't mark them as duplicates at all.
<Keybuk> jdub: could you prod the appropriate people to work on it?
<ogra> jdub, just an ical like the fridge has would already be rad
<ogra> just to keep evo up to date with holidays and the like
<ohoel_> oh right
<_ohoel> ^^
<Kamion> iwj: ubiquity is known to be a11y-weak, I'm afraid. Although I believe it is at least *possible* to drive the GTK frontend using only the keyboard, even if not entirely easy ...
<jdub> Keybuk: "elmo, please set up an exchange server for us!" -> ah, no thanks :)
<Kamion> ogra: yes, sorry, that screensaver bug is still open
<Kamion> iwj: (so I'd consider it a bug if that weren't possible)
<LinuxJones> ogra, ok thanks it's obviously been a while since I've had to look in there :)
<mdz> sfllaw: are you tracking test results for the current candidate build?
<sfllaw> mdz: If you mean, "am I looking at Testing/Current", then yes I've been keeping my eye on it.
<LinuxJones> ogra, it's odd that certain ones will run like synaptic but others like users-admin won't.
<_ohoel> Kamion: tabbing between fields in places like "tell us about yourself" is  a bit complicated
<sfllaw> mdz: I've also been fixing RC bugs.  I've got two debdiffs for you to look at, in a couple of minutes.
<Kamion> _ohoel: I fixed that ages ago
<Kamion> _ohoel: what version are you using?
<mdz> sfllaw: no, I meant "Testing/Current needs to be flushed because we have a new candidate"
<_ohoel> right, beta2 I think 
<iwj> Kamion: OK, I'll file a bug but not consider it RC.  Users who want to drive only with the keyboard are to use the d-i CD, then, I take it.
<Keybuk> mdz: since when?
<mdz> sfllaw: it still has results from 20060524, while we're now testing 20060525
<Keybuk> iwj flushed it earlier
<iwj> That's obviously not ideal because the d-i CD has many fewer a11y tools.
<Kamion> _ohoel: if that's Kubuntu, this was fixed in ubiquity 0.99.67
<infinity> mdz: iwj flushed it when we rolled new images.
<ogra> heh
<_ohoel> Kamion: I'll download an test a fresher image :)
<iwj> mdz: I left those old results in, with image dates attached, when they had comments.
<Kamion> iwj: if it's easy to fix, I still have one other RC bug in ubiquity, so I can squeeze minor KDE UI tweaks in
<mdz> infinity: actually it looks like he prepended the build number to the old results
<ogra> edubuntu amd64 ubiquity manual partitioning install PASS
<Kamion> iwj: heno tells me that the GTK frontend is usable without the mouse
<mdz> which makes it difficult to see the coverage
<iwj> Kamion: Oh, good.
<infinity> mdz: To some results, and others he removed.  Not sure what the logic there was. :)
<iwj> Kamion: OK.  I'll report this bug.
<iwj> Hrm, this install is busted.
<iwj> Or maybe the disk is ?
<infinity> mdz: Just wiping the ones with the old build number should do.
<iwj> I think I need to be using a different disk.
<mdz> where did dholbach go?
<vinboy> how do i get involved in the development?
<iwj> I removed the results with no comments.  I didn't want to remove the results with comments because I thought the comments might be important.
<mdz> vinboy: http://www.ubuntu.com/community/participate
<Keybuk> vinboy: right now, the best help we can get is to have testing of the CD images being produced
<iwj> If they're not important then the old results can be removed.
<iwj> I think though that keeping the old FAILs until the bug is believed fixed is probably sensible.
<Kamion> 46398 is confirmed fixed; those fails can be removed
<mdz> sfllaw,iwj: what we want is to find some reasonably convenient way to preserve the old results, but also see what's been tested with the current candidate at a glance
<mdz> this may require something more sophisticated than a wiki page
<infinity> More sophisticated than a wiki?  Is there such a thing?
<infinity> Ahh, and the amd64 machine here just opened up.
* infinity goes to abuse it.
<sfllaw> iwj: Is there really a need to keep old PASSes?
<sfllaw> Old FAILs are fine.
<sfllaw> We can just leave bug numbers next to ?
<sfllaw> heno: Ping?
<heno> sfllaw: hi
<sfllaw> heno: I missed your e-mail in my inbox until this morning.
<sfllaw> Can you take over doko and jbailey's Testing/Current tasks?
<mdz> sfllaw: it's useful to record a historical PASS vs. an "untested"
<infinity> sfllaw: I'm doing doko's i386/alternate stuff right now, but more people doing so wouldn't hurt.
<sfllaw> infinity: Thanks.
<mdz> I test i386/alternate/erase as part of my regular testing
<Keybuk> sfllaw: I'm doing anything powerpc/* from the top of the list down
<heno> sfllaw: sorry, not really. I'm redoing the website ...
<infinity> mdz: But you didn't record it.
<sfllaw> heno: OK.
<sfllaw> mdz,Keybuk: If you could record the fact that you've done so...
<sfllaw> That would be brilliant!
<Kamion> I've finally got a bit of time, so I'll see if I can do powerpc netboot now
<Keybuk> sfllaw: I have been recording it
<sfllaw> Keybuk: Ah.  I see that now.
<mdz> sfllaw: I did
<mdz> that page needs a meta refresh tag ;-)
* Kamion takes the cheesy approach to netboot
<jsgotangco> Edubuntu amd64 Install CD auto-resize PASS
<Kamion> "copy files to local hard disk and make yaboot boot off that"
<mdz> Riddell: do you have results from the current candidate yet?
<Keybuk> powerpc alternate manual PASS
<Riddell> mdz: alternative i386 and powerpc good, still rsyncing desktop CDs
<Riddell> I'll update Testing/Current
<mdz> Riddell: thanks
<Keybuk> right, I'm gonna grab lunch while this (ppc alt erase) installs -- it'll take a while
<bddebian> Heya folks
<mgalvin> hi bddebian
<bddebian> Hello mgalvin
<iwj> We could have a list of the test results and a script to massage it into a table.
<iwj> sfllaw: keep old passes> If they have interesting comments, then yes.  If we want to keep the comments then attaching them to a ? or to a subsequent test result might be wrong (it would depend on the comment).
<sfllaw> mdz,fabbione: Sent patches to fix WvDial.
<sfllaw> iwj: Maybe old passes and fails could be lowercased?
<bddebian> Hi sfllaw
<sfllaw> Then you can do a case-sensitive search for PASS and FAIL and get reasonable results?
<sfllaw> bddebian: Hi.
<bddebian> sfllaw: Where where those test pages again?
<iwj> sfllaw: That's a good idea.
<sfllaw> Testing/Current
<sfllaw> iwj: Shall I do the honours?
<iwj> Yes.
<mdz> Kamion: I can't get i386 alternate to offer me automatic resize
<Kamion> mdz: /var/log/syslog should say why not
<Kamion> log message from partman-auto
<Kamion> oh maybe it's in /var/log/partman, can't remember
<Riddell> mvo: you had amd64 kubuntu netinstall working last night didn't you?
<mvo> Riddell: yes, I added it to the wiki last night
<Kamion> mdz:yeah, /var/log/partman - first log message should be "<something> primary partitions, <something> logical partitions"
<mdz> Kamion: ok, I'm there, but I don't know how to interpret the rest
<mdz> at the start, I had the default erase-disk layout (root primary, swap logical)
<mdz> when it didn't offer the option, I used manual partitioning to create a single primary on the entire disk
<mdz> as the simplest case for resizing
<mdz> then went back to guided partitioning
<Kamion> mdz: can you paste me a chunk of the log from there down in /msg
<Kamion> ?
<mdz> should be able to
<Kamion> it requires at least 3GB free or it won't bother offering it
<Kamion> on the heuristic basis that if it's less than that, you'll be making both the existing and the new filesystems unreasonably tight on space
<Kamion> (conclusion from /msg)
<Kamion> oh, damn, my running netboot install is going to set up an LTSP chroot, since that bug fix isn't in yet
<Kamion> oh well
<sladen> Kamion: instances of that bug are going to continue to arise for as long as there are people in the wild who installed their current setup with an early Flight CD.  I can keep the instances separate if you would like, even if they are of the same class and cut and paste the same description and solution into each of them.
<Kamion> sladen: I made my comment before I saw your followup to the newer bug which synced up its status with the older one
<Kamion> sladen: I hadn't realised you were going to do that; it looked separate, and I'd expected you to do that *before* marking it as a duplicate ...
<Kamion> so reverting my duplication change is fine, sorry about that
<Kamion> what I normally do is add an explanation to the bug and only then mark it as a duplicate; it saves on confusion
<sladen> Kamion: groovy, I'll remember to do that in that order next time :)
<sladen> launchpad could do with a 'Related' relationship aswell as a Duplicate
<Kamion> yeah
<mdz> sfllaw: what's the reasoning behind http://people.ubuntu.com/~sfllaw/wvstreams.debdiff ?
<mdz> sfllaw: likewise for wvdial.diff; it's fairly opaque to me without knowing the code
<sfllaw> mdz: The wvstreams patch prevents wvdialconf from blocking on close(), which happens inside WvFile::close().
<sfllaw> That tcsetattr puts something in the output buffer.
<sfllaw> At least, for some IRDA drivers.
<sfllaw> The wvdial patch has the line cfg.commit() and some cleanup code, which causes WvDial to actually write out the config file.
<sfllaw> This patch is actually inside Debian, and was fixed ages ago, but never sucked into Ubuntu.
<sfllaw> I think that was because of the UVF.
<sfllaw> I cherry-picked it just for this release.
<infinity> Mithrandir: Around?
<mdz> sfllaw: it also changes get to xget and set to xset; what does that do?
<sfllaw> That's proper style within WvStreams programs now.  The old WvConfEmu interface is a bit broken, which is why the file didn't get written properly.
<mdz> it seems to be using a slightly differentAPI
<sfllaw> I can generate a patch with fewer changed lines, if you'd like.
<mdz> sfllaw: and you're comfortable with all of this as a days-before-final sort of update?
<sfllaw> It can't make WvDial any worse.
<mdz> ok
<mdz> sfllaw: please go ahead
<sfllaw> Thanks.
<sfllaw> fabbione: Ping?
<vinboy> does downloading the iso using jigdo prevent corrupted download?
<Mithrandir> infinity: hi
<bddebian> Heya Mithrandir
<Mithrandir> hiya bddebian 
<infinity> Mithrandir: Can you test the mad64/desktop CD and confirm that I'm not going insane?
<mdz> sfllaw: dholbach is off; we need someone else totest amd64/alt
<mdz> unfortunately the amd64 laptop I used here in the office for  beta has been "repurposed"
* mdz glares at silbs
<infinity> Mithrandir: When I hit "Adding LiveCD user", it locks up.  Booting with "splash" off, I see an infinite loop of OOPSes... Well, I think they're OOPSes... It's scrolling awfully fast to know for sure.
<Mithrandir> infinity: C-s should pause it
<Mithrandir> infinity: I can check.
<Mithrandir> infinity: except cdimage currently hates me.
<infinity> Yeah, squashfs explodey.  I wonder if it got corrupted somewhere in the build process (the CD itself checks out fine)
<Kamion> I'll start on amd64/alternate in a moment
<mdz> Riddell: I got no splash-down with my kubuntu alt install
<mdz> Riddell: not until the last bit where it gets restarted
<mdz> Riddell: is that normal?
<Keybuk> mdz: splashdown seems temperamental on kubuntu
<Kamion> just need to shovel bits over to that box
<Keybuk> I've had it about 6/10 times
<Riddell> mdz: it's not normal but it does happen not infrequently, I'm yet to spot the pattern
<Keybuk> including getting splashdown when I shouldn't have ;)
<Riddell> gdm has a nice "I'm about to change to vt1" function but kdm doesn't have that
<mdz> Riddell: probably has to do with vt switching
<Keybuk> Riddell: I thiiiiink it might be a race between X switching vts, and usplash getting started by kdm stopping
<OculusAquilae> carlos: ktorrent is translated now, thanks 
<iwj> Yay, I managed to finish a test.  PASS despite the bugs I found ...
<carlos> OculusAquilae: your are welcome
* bddebian is still downloading the desktop CD :-(
<infinity> Mithrandir: Crap.  The md5sum of the squashfs on my CD matches the md5sum of the original on king.  And the build log looks like everything was A-OK... But it just does not work for me, at all.
<Keybuk> infinity: which is that?
<infinity> Keybuk: amd64/desktop ... No workey here.
<Keybuk> ok, I'll give that one a test in a minute
<Keybuk> just about to finish the ubuntu powerpc tests, then I can move my workstation to the laptop and test on this
<infinity> Keybuk: Explodes in a mess of OOPSes around "Adding LiveCD user"
<infinity> If it's just me, I can cope, but since the last build worked fine over here, I'm thinking something when Very Wrong.
<infinity> s/when/went/
<vinboy> Keybuk: r u getting paid to do this?
* infinity starts a new amd64 livefs build in case we need it.
<Kamion> Ubuntu powerpc netboot PASS
<bddebian> w00t
<Keybuk> this has taken a while "Cleaning up" ... it must be doing my kitchen
<mdke> janimo: nice work on the xubuntu-docs translations
<Keybuk> release week and housework are not friends
<janimo> mdke, I just uploaded them :)
<bddebian> Keybuk: :-)
<Keybuk> ubuntu powerpc alternate erase PASS
<bddebian> Sheesh, you'd think a T-1 would download a little damn faster :-(
<Keybuk> ok, let's test this amd64 desktop
<_ion> The last comment in bug #40607  ideas, anyone?
<Ubugtu> Malone bug 40607 in tango-icon-theme-common "Ok/Cancel buttons" [Normal,Unconfirmed]  http://launchpad.net/bugs/40607
<_ion> I wish the gtkrc syntax allowed something like CSS selectors.
<Keybuk> _ion: it does?
<Mithrandir> infinity: reproduced.
<Mithrandir> debconf-communicate makes unionfs oops
<infinity> Mithrandir: Feh.
<Kamion> Urgh.
<infinity> Mithrandir: Okay, a new livefs is spinning right now, to see if a new build will just make it go away.,
<Kamion> When was the last successful amd64 desktop test?
<infinity> Kamion: Yesterday's images were fine.
<Kamion> Please tell me it wasn't before the last kernel change.
<Kamion> OK, so it may be cosmic rays ...
<sfllaw> mdz: Is dholbach gone for a long while?
<infinity> Kamion: Just blew up on today's build.
<sfllaw> Or just sleeping?
<dholbach> sfllaw: I'm here.
<sfllaw> dholbach: You can't test amd64?  :(
* bddebian hugs dholbach
<Kamion> sfllaw: I'll test amd64/alternate just as soon as the machine in question has finished apt-get upgrading.
<infinity> Kamion: I'm hoping for cosmic rays, hence why I kicked off the new livefs a while back. :)
<Kamion> infinity: I'm ready to start a CD image build for just amd64 when you give the word
<sfllaw> Kamion: Thanks.
<mdz> how is everyone doing on their test cases?
<mdz> sfllaw: I think he's ascending
<Kamion> Is amd64/desktop working for Kubuntu?
<Keybuk> Kamion: about to test that one too
<Keybuk> I rsync'd that one as well, just in case
<infinity> Keybuk: Please do so ASAP, to see if we have this same bug there.  Though I can't imagine why we would.
<mdz> Kamion: what's up with amd64?  I haven't been able to test it
<Keybuk> btw
<Keybuk> I concur
<Kamion> mdz: alternate or desktop?
<Keybuk> amd64 OOPS for me too
<infinity> mdz: unionfs explodes early in casper.
<infinity> mdz: Yesterday's images were fine, so I'm assuming cosmic rays and rebuilding the livefs.
<mdz> eek
<mdz> Kamion: either
<Kamion> mdz: 16:48 < Kamion> sfllaw: I'll test amd64/alternate just as soon as the machine in question has finished apt-get upgrading.
<_ion> keybuk: Attribute selectors, to be accurate.
<mdz> ok, so desktop is b0rked and alternate is untested?
<Kamion> just rebooting into it now
<mdz> I have a kubuntu dvd i386 ubiquity in progress
<mdz> and an i386 alternate OEM
<Keybuk> shall I test amd64 DVD too?
<mdz> mjg59: you need to bail out of that thread on sounder; it's hopeless
<infinity> Keybuk: If you've got the bandwidth.
<Keybuk> infinity: it's one of the ones I keep in my cache
<Keybuk> I assume it's "up to date" on beryllium?
<_ion> In pseudo-CSS, i'd need GtkButton[relief=NONE]  { GtkWidget::focus-padding: 0; xthickness: 0; ythickness: 0; } in gtkrc in order to fix the problem pointed out in the message.
<infinity> Keybuk: Should be.
* infinity goes for a quick de-stressing smoke while king finishes that livefs build.
<Kamion> mdz: FYI I have a dinner invitation with my cousin tonight, so I have about two more hours
<Keybuk> hmm, beryllium is unhappy -- won't rsync a DVD
<elmo> it's still trying to sync
<Keybuk> elmo: PUT MORE CHILDREN ON THE FIRES
<mdz> Kamion: acknowledged
<mdz> repo man has all night, every night
<elmo> it should work, it'll just be slow till the write-fest is over
<infinity> Kamion: We'll resolve this before then, or I'll slit my wrists.
<Keybuk> elmo: it wasn't sending any data
<Kamion> let's resolve it then ... wouldn't want blood on the channel
<mdz> infinity: it'll take that long to do a test
<infinity> mdz: I can whip through the amd64 tests pretty quickly.
<infinity> mdz: I had lots of practice last night when filing ubiquity bugs from that machine. :)
<mdz> infinity: livefs build + cd build + publish + rsync
<mdz> THEN you can try a test ;-)
<infinity> mdz: livefs build is about 2 minutes from done.
<Kamion> CD build for one architecture is like five minutes
<elmo> Keybuk: it's using a scheduler that massively favours writes, so all our boxes essentially stall during the sync, an beryllium has/had a hundred Gb or something to sync
<mdz> I'm giving up on this edubuntu DVD rsync
<mdz> ogra: do you have one?
<elmo> it's at xubuntu/ now tho, should be done soon
<elmo> tho, I'm having to try hard to resist adding --exclude='.*-src-.*' to the sync script at this stage :-P
<thom> elmo: s/write/read itym?
<mdz> grumblegrumble
<infinity> Kamion: livefs build done, hit the switch.
<Kamion> infinity: switch hit
<Keybuk> new amd64 live to test?
<elmo> thom: no, writes - deadline massively penalizes reads in favour of writes
<infinity> Keybuk: Shortly.
<thom> uh, oh yeah, heh
<Keybuk> infinity: was about to say, rsync claimed no diff ;)
<infinity> Keybuk: Assuming it boots, do you want to do the full live session test (wander through, check apps work, etc), and I'll do the two installation tests?
<Keybuk> infinity: yup
<infinity> Or three, whatever.
<Keybuk> it'll save me having to swap hard drives around
<infinity> Here's hoping it boots, then. :)
<mdz> infinity: do we need to wait for this massive sync to complete before we can publish that amd64 image?
<Keybuk> I never like opening quest, it growls at me
<Kamion> cjwatson@lithium:~$ md5sum cdimage/scratch/ubuntu/daily-live/live/amd64.squashfs
<mdz> I suppose rsyncing directly from lithium would be more expedient
<Kamion> 5f56a659d2fdf9832baef5ecc109684f  cdimage/scratch/ubuntu/daily-live/live/amd64.squashfs
<Kamion> infinity: is that the right md5sum?
<Kamion> I'd just grab it from lithium if I were infinity ... though IIRC Keybuk cannot
<Keybuk> I cannot
<Keybuk> I am insufficiently powahful
<infinity> Kamion: md5sum matches, yes.
<elmo> I'm happy to temporarily setup passworded rsync on lithium, if you want
<Kamion> built, it's trying to trigger beryllium at the moment and not getting very far
<infinity> Kamion: But it did on the broken one too, so I'm not holding my breath.
<Kamion> infinity: just checking it's not out of date or anything
<Keybuk> elmo: bah, give me an account on lithium, you _know_ you want to :)
<infinity> I'm syncing fine from a mirror anyway.  Obviously didn't get beryllium.
<elmo> beryllium isn't in rotation till it's uptodate
<Kamion> (BTW, the build took under 3 minutes)
<elmo> and I've had a chance to setup a working httpd on it
<elmo> Keybuk: I'd rather people didn't add ssh overhead as well as rsync to lithium, tbh
<mdz> Kamion: hmm, my OEM install seems to have crashed and burned.  it boots up to gdm.
<Kamion> I've just killed the beryllium trigger
<Keybuk> it appears to have turned up on one of the cdimages
<elmo> Kamion: why?
<Kamion> elmo: because I wanted that shell back? :P
<elmo> mmk
<Kamion> let me know when it's synced and I'll trigger again
<infinity> Synced, MD5 matches, burning.
<Kamion> mdz: crashed and burned how?
<mdz> Kamion: after d-i finished and rebooted, it came up straight into gdm.  aren't I supposed to get the firstboot stuff instead?
<Kamion> mdz: no, you'll have got a message just before reboot that you need to run oem-config-prepare when you're finished customising the system
<mdz> I read the title of the dialog...
<Kamion> feedback I got indicated that people didn't really like the "one reboot, then we throw you into oem-config, kthxbye" business in breezy
<Kamion> though I concede something more in-your-face at gdm time might help
<Kamion> mdz: log in as oem with the password you set
<Kamion> sudo oem-config-prepare
<Kamion> then reboot
<infinity> A custom GDM them with "OEM FIRST BOOT" plastered all over it might be helpful.
<Kamion> yeah
<Keybuk> hmm, rsync appears to be in fucking stupid mode -- it's just downloading from scratch fwict
<mdz> infinity: what have I told you about that sort of thing within earshot of mark
<infinity> mdz: Blindfold him.
* Kamion goes for coffee while amd64/alternate finishes installing (in pkgsel, looking OK so far)
<elmo> is FIRST BOOT our version of FIRST POST?
<mdz> Kamion: ok, so I ran oem-config prepare and rebooted, and I still didn't get the questions
<mdz> and the oem login still works
<iwj> Ugh, this breezy CD seems to have been covered in some strange kind of gunge !
<Keybuk> infinity: you kinda broke /current/ with your little rebuild :p
<infinity> I did no such thing.
<Keybuk> infinity: check MD5SUMS
* dholbach does amd64 alternate installs
<mdz> iwj: unreproducible here, my breezy CDs are fine
<iwj> :-P
<Keybuk> does anyone else REALLY not want to know what the gunge is?
<Kamion> mdz: literally 'oem-config prepare'?
<mdz> Kamion: sudo oem-config prepare
<Kamion> mdz: 'sudo oem-config-prepare'
<mdz> aha
<mdz> i reed gud
<Kamion> I should make oem-config be fascist about arguments to catch that
<Keybuk> or just dtrt
<infinity> Keybuk: Oh, special.
<Keybuk> the number of times I wish apt-get would just exec apt-cache when that's what I really meant
<infinity> Kamion: The single arch build didn't carry over the MD5SUMS from the old arches.
<mdz> Keybuk: in edgy I'm going to merge them and call the result 'apt'
<infinity> Kamion: "oops"
<Kamion> I've no idea why oem-config didn't pop up when you ran that, mind
<Keybuk> mdz: call it "smarter"
<dholbach> haha
<mdz> Kamion: it did, but I didn't think about what it was doing
<Kamion> infinity: stupid thing. fixing
<Keybuk> elmo: rsync has stalled again.  I'm upset
<mdz> Kamion: it asked me the first couple of questions and then exited apparently successfully
<mdz> didn't ask me the user info
<mdz> weird, I get a different wastebasket icon
<elmo> Keybuk: use lithium
<mdz> the old blue one
<Keybuk> elmo: ha ha
<Kamion> infinity: fixed, thanks
<Kamion> mdz: I have a suspicion it got very confused by you running it as oem
<Kamion> oem-config is wonky in dapper and needs a good kicking early edgy
<infinity> Bucket.  Of.  Cocks.
<Keybuk> is there a difference between early edgy and late edgy
<infinity> Same failure.
<Keybuk> infinity: failing for you too, huh?
<mdz> the other icons are all correct, it's very curious
* Keybuk was just checking he really burned the new cd
<infinity> This is double-plus ungood.
<infinity> Kamion: What's the size limit on an ISO to reliably not die?
<Kamion> so. RC -= amd64/desktop?
<infinity> Kamion: Maybe we went a smidge over with the new OOo-amd64...
<mdz> Kamion: or we publish the previous build
<infinity> Kamion: Humour me.  Kick something out of ship-live for a second, and retry a smaller build.
<Kamion> infinity: it's supposed to be 736051200
<mdz> infinity: rm -rf some stuff and re-mkisofs
<Kamion> it's WAY under that
<infinity> Point.  It is way under.
<infinity> I'm going to re-make it anyway.
<Kamion> locally?
<mdz> infinity: where does it fail? can it even do a media check?
<infinity> Yeah, I'm doing it locally.
<infinity> mdz: Media check worked on the last image.  Trying this one now.
<Kamion> you have the mkisofs rune?
<infinity> I can't imagine what could have broken, though, since the only two things that changed were OOo and ubiquity...
<infinity> Kamion: paste it, SVP... I forget where it lives on lithium.
<mdz> infinity: that's worth confirming
<Kamion> mkisofs -r -V 'Ubuntu 6.06 amd64 Bin-1' -o dapper-desktop-amd64-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-ize 4 -boot-info-table build-tree
<Kamion> of course that's without the sorting stuff ...
<mdz> infinity: what's the version of the one which worked?
<Kamion> er, s/-boot-load-ize/-boot-load-size/
<Keybuk> mdz: 23
<Keybuk> allegedly
<infinity> mdz: 20060524 works.  20060525 and 25.1 are broken.
<mdz> live-ship is the only difference in the iso file list
<mdz> bunch of changes in the livefs though
<mdz> oh, I'll diff 24 instead then
<Keybuk> sorry, my bad
<mdz> only desktop stuff
<mdz> nothing that's even touched before gdm starts
<Burgwork> somebody was looking for me?
<Keybuk> why do we only find squashfs/unionfs bugs _NOW_
<mdz> http://people.ubuntu.com/~mdz/temp/amd64.diff
<infinity> Keybuk: We've been living with the fragile union all release.  It just mostly works, so we've ignored the fragility. :/
<HiddenWolf> dholbach: since the -artwork update yesterday the icon nautilus places on the desktop for a mounted cd is huge, known?
<mdz> infinity: flush the livefs and rebuild it from scratch, I say
<mdz> that should reshuffle the deck enough to get it working again :-P
<infinity> mdz: We do build from scratch.
<mdz> oh
<Keybuk> I like the fact the OOPS has junk all over it
<mdz> well, hell
<infinity> mdz: The rsync trick is long gone.
<Keybuk> hmm
<dholbach> HiddenWolf: yes, it was reported at least 15 times to me and it's fixed, but the package is held in the queue until RC is out
<Keybuk> "attempt to access beyond end of device"
<infinity> And, the integrity check passed. :/
<infinity> Keybuk: Ah-ha.
<HiddenWolf> dholbach: sorry. :)
<dholbach> :-)
<Keybuk> want=<some number>, limit=<some lower number>
<Kamion> initramfs overflow?
<Keybuk> limit=1232960
<Kamion> what are the units for that limit?
<mdz> Keybuk: what are the numbers?
<Keybuk> mdz: I'll do that again
<Keybuk> I un-locked the scroll
<mdz> infinity: squashfs sorts the files then?
<elmo> rsync: send_files failed to open "/daily-live/.swp" (in cdimage): Permission denied (13)
<mdz> haha
<infinity> mdz: Yes.
<Kamion> elmo: that was me, gone now
<Keybuk> mdz: I can't seem to get the first set of numbers
<Keybuk> attempt to access beyond end of device
<infinity> mdz: mksquashfs is more or less a black box.  We just aim it at the chroot and ship.  None of the crazy stuff we had to do with ext3-on-cloop.
<Kamion> also, I just found that publish-daily has been screwing over MD5SUMS.gpg files in previous builds of the same type every time it runs
<Keybuk> loop0: rw=0, want=2016046, limit=1232960
<Keybuk> thru
<Kamion> (fixed)
<Keybuk> loop0: rw=0, want=2016188, limit=1232960
<Keybuk> *crash*
<Kamion> but I wonder how many people actually check the signatures ...
<Keybuk> limit could be bytes, or 512b (621,375,520)
<mdz> Keybuk: break it in initramfs and check out loop0 a bit
<infinity> What's mounted on loop0?  The squashfs?
<iwj> Kamion: You might not have seen, but that bug in the kubuntu install where the partitioner locks up is reproduceable.  All you have to to is try to back out of the partitioner with the back button.
<mdz> infinity: should be, yes
<Keybuk> mdz: that's exactly what I'm doing
<elmo> whee, beryllium is up-to-date
<elmo> (rsync only)
<Kamion> iwj: yeah, I saw, it's a qtparted thing, needs Riddell
<ogra> mdz, nope, not yet
<iwj> Kamion: Right.  I just want to make sure you know about it :-).
<mdz> elmo: woo
<Kamion> when you hit back there, ubiquity says "undo" to qtparted which then is supposed to not hang :-)
<mdz> ogra: mine is getting 1M/sec now
<mdz> Kamion: please add that to DRR
<ogra> mdz, lets just skip edubuntu DVDs for RC, i'll test during this week 
<ogra> (i dont think anybody beside me will test them anyway in the community)
<Kamion> mdz: will do
<mdz> ogra: I'll have one in 10m; I'll test it
<ogra> ok
<mdz> i386 anyway
<mdz> I can't test anything else
<mdz> elmo: do you know where the power supply for this powerbook of yours went?
<ogra> thats enough, i''ll test amd64 during the week (go no dvd reader in my ibook)
<ogra> *got
<elmo> mdz: no?
<mdz> elmo: I didn't take it
<elmo> well, it was there when I left, hmm
<mdz> elmo: where's there?
<elmo> the office
<elmo> I basically hadn't touched the powerbook (or it's adaptor) since my aborted attempts to hacksaw it open
<Keybuk> ok
<ogra> Riddell, are you currently editing Testing/current ? 
<ogra> (i get a warning)
<bddebian> Hacksaw to a PowerBook?  haha
<Keybuk> that limit=1232960 must be in 512 byte sectors
<Riddell> ogra: no, go ahead
<ogra> thanks
<infinity> Kamion / Keybuk / mdz : Okay, shrinking the ISO didn't help one bit, so it's likely the squashfs itself.
<Keybuk> 1,232,960 * 512 = 621,375,520
<Keybuk> which happens to be the exact size of the squashfs
<infinity> Keybuk: And something's trying to read past the end of it?  ROCK.
<Keybuk> right
<infinity> Kernel bug, or mksquashfs bug, I wonder?
<Keybuk> /dev/loop0 is the squashfs
<infinity> And how big does the kernel claim /dev/loop0 is?
<Keybuk> infinity: what rune do I need for that?
<infinity> cat /proc/partitions
<Keybuk> ah yes, it occurred to me at the same time
<Keybuk> 616480
<infinity> Okay, so that doesn't seem insanely wrong.
<infinity> Cause your error above looked like it was trying to read at least 2x the real size.
<Keybuk> indeed
<Keybuk> * 1,024 is the same value
<infinity> I wonder if we have some 512 versus 1024 k block confusion.
<infinity> But that would have bit us ages ago...
<Keybuk> yeah, that would surprise
* Keybuk is nearly at the end of the initramfs now
<bddebian> Finally, CD finished
<mdz> infinity: are you able to loop-mount the squashfs and verify it?
* Keybuk looks up casper's bottom
<bddebian> ?
<infinity> mdz: I can loop it.  Not sure what to verify.
<mdz> infinity: thinking of it, it'd have to be a squashfs bug, since unionfs asks for files and not blocks
<Keybuk> IF ONLY SOMEBODY PUT FIND IN THE INITRAMFS
<infinity> mdz: (ie: I have no md5sum manifest of the contents or anything)
<mdz> infinity: md5sum -c /wherever/the/md5sum/file/is
<Keybuk> IF ONLY SOMEBODY PUT MD5SUM IN THE INITRAMFS
<Keybuk> etc.
<mdz> infinity: we don't generate one of those?
<mdz> hmm
<mdz> infinity: you could debsums it
<infinity> No, that would take eons.
<Keybuk> oh, cute, there's a bad sector on this cd all of a sudden
<infinity> I can debsums for the packages that have sums, yes.
<infinity> Which should be most of them.
<Kamion> find -type f | xargs cat >/dev/null
<Kamion> at least see if you can read all the files
<Kamion> use find and xargs from the squashfs if they wor
<Kamion> k
<Keybuk> Kamion: thank the gods we didn't go insane and only use klibc in the initramfs
<Kamion> Keybuk: LD_LIBRARY_PATH
<Keybuk> Kamion: no, I mean seriously, thank god we didn't do that
<Kamion> heh :)
<infinity> I'm getting a lot of "No such file.."
<Kamion> damn, I keep forgetting to watch splash-down
<infinity> This can't be a good sign.
<Keybuk> infinity: my /usr/lib went missing last time
<Kamion> infinity: compare failures on the squashfs and the unionfs?
<Keybuk> does the CD contain an inventory of itself?
<infinity> dmesg is filled with:
<infinity> [4361559.926000]  __find_get_block_slow() failed. block=319, b_blocknr=316
<infinity> [4361559.926000]  b_state=0x00000020, b_size=1024
<infinity> [4361559.926000]  device blocksize: 1024
<mdz> sweet, I get checksum mismatches on the i386 livefs
<infinity> Keybuk: The ISO does.  The squash only has a manifest of installed packages.
<Kamion> Ubuntu amd64 alternate manual partitioning PASS
<janimo> Kamion: xubuntu installed and there was no ltsp 
<mdz> apparently, aspell-en ships files in the .deb in /var
<mdz> and then modifies them
<Kamion> janimo: great
<janimo> but no usplash either Iwonder why
<Kamion> oh, that might be my fault
<mdz> infinity: I only get one missing file on i386: debsums: can't open libgl1-mesa file /mnt/usr/lib/fglrx/libGL.so.1.2.xlibmesa (No such file or directory)
<Kamion> hmm, no, should be fine
<Kamion> janimo: is usplash installed? how about xubuntu-artwork-usplash?
<Kamion> janimo: look for those in /var/log/installer/syslog
<janimo> Kamion, yes it's installed in /etc/alternatives
<Kamion> janimo: dpkg -l I mean
<Keybuk> oh, wow
<janimo> can using LVM on the whole disk have any effect on this?
<Keybuk> I got a PANIC just with find and cat
<janimo> I used lvm the first time
<Kamion> janimo: no, I wouldn't think so
* janimo looks
<mdz> Keybuk: on plain squashfs or squashfs+unionfs?
<Keybuk> mdz: unionfs
<mdz> SWEET
<Kamion> the squash should be in /rofs
<Keybuk> gonna try the same on the squash now
<infinity> mdz: That's special, since that file shouldn't exist in the first place...
<janimo> Kamion, cmdline is ro quiet (no splash on it)
<Keybuk> Kamion: find /root/rofs -- would that "touch" the unionfs at all?
<Kamion> janimo: did you boot with debian-installer/framebuffer=false?
<Kamion> Keybuk: not sure
<mdz> Keybuk,infiinity: can one of you try loop-mounting the amd64 squashfs on i386 and see if it breaks there too?
<infinity> mdz: That's what I've been doing.
<Kamion> Keybuk: shouldn't've thought so apart from the name lookup on /rofs on the unionfs
<infinity> mdz: That's where I got all the missing files.
<mdz> Keybuk: only just barely, touching the /rofs inode might go through unionfs
<infinity> mdz: I'm now poking at the amd64 machine directly.
* Keybuk doesn't have an i386
<mdz> Keybuk: whatever, non-amd64
<janimo> Kamion, no plain reboot after install
<janimo> and now a new reboot
<infinity> squash is endian-sensitive, so it probably won't work on powerpc at all.
<Kamion> janimo: I mean debian-installer/framebuffer=false as a parameter to the installer
<janimo> Kamion: no, plain reboot as in I did not touch anything :)
<janimo>  /proc/cmdline is root=/dev/mapper/Ubuntu-root ro quiet
<janimo> that's what it is set to by the installer
<infinity> Okay, that was special.  On a "break=bottom", busybox throws an OOPS.
<Kamion> janimo: oh, maybe it does make a difference, we might not set up lilo with splash by default
<mdz> elmo: found it; it was hiding in the server closet
<Kamion> I thought we did, but could be I forgot
<janimo> Kamion, lilo ? hmm it looked like grub to me
* janimo reboots
<elmo> mdz: *blink* ok
<mdz> janimo: grub can't boot from lvm, unless you have a separate /boot
<janimo> it was definitely grub since the last installer screen was 'installing grub'
<Keybuk> hmm, this CD is giving me sector errors now
<Keybuk> I'm gonna toss it and burn another, won't take but a jiffy
<Kamion> janimo: can you just file a bug on debian-installer and attach /var/log/installer/syslog then, please?
<mdz> Keybuk,infinity: clearly you are both just having simultaneous hardware failures
<tseng> Keybuk: is that 100 jiffies, or 1000?
<mdz> I'm trying to arrange an impartial test here
<tseng> per clock
<janimo> Kamion, I'll file it. I chose use LVM on entire disk option. Whatever it set up I expected it erased the whole drive before
* infinity is wondering if the decision to not switch to squashfs 3.0 back in April is now haunting us.
<Kamion> it may well have set up a separate /boot
<mdz> hell. I just confirmed the hang on amd64
<mdz> Kamion: what would it take to mix and match the old amd64 build for RC?
<Kamion> mdz: straightforward
<Kamion> just means an extra careful publish-release invocation
<Keybuk> doesn't the old build have ubiquity 1.0.4 though?
<mdz> eek, I'm getting I/O errors on the CD too
<Kamion> (publish-release honours $ARCHES)
<Kamion> Keybuk: yes, we'd lose a few bug fixes, but we can cope
<mdz> wow, even sysrq+t hangs
<Keybuk> Kamion: like the link_on_boot bug fix?
<Kamion> Keybuk: which only affects powerpc
<mdz> Keybuk: that was powerpc-only
<Keybuk> ahh
<Keybuk> that's ok then
<carlos> janimo: hi, around?
<janimo> carlos: hi
<carlos> janimo: is evince-gtk a package from xfc ?
<mdz> the multiple-disk fix is the only one we'd have to document
<janimo> carlos, no but it is part of xubuntu desktop. It should use the same .po files as evince
<mdz> in hopes of avoiding dupes
<Kamion> we'd lose: crash fix when deleting partitions; infloop fix for multi-disk systems; better interaction with gparted/qtparted plus one backup crash; crash fix on blank rows in mountpoints table
<carlos> janimo: hmm, so it shares the translation domain?
<janimo> carlos, so langpack-gnome I think.
<janimo> carlos: yes
<mdz> I think we should probably revert amd64, do RC, and attack it tomorrow
* infinity concurs.
<Kamion> I agree
<mdz> in fact, if I'm not mistaken we have uploads queued
<infinity> This one looks like it'll require fresh eyes and real brainpower.
<Kamion> is everything else good?
<infinity> Both of which I'm lacking right now.
<carlos> janimo: ok, it has a bunch of .po files and lacks a .pot file so I was wondering what should I do  with those
<mdz> so maybe it'll magically go away :-HD
<carlos> janimo: if both share the same translations, I will remove the evince-gtk ones
<carlos> janimo: thanks
<mdz> all of my tests have been successful, modulo the trash icon being a little bit weird in my mutilated oem install
<Keybuk> mdz: it'll affect i386 instead
<infinity> mdz: Well, ubiquity and OOo broke it this time.  I have an OOo upload queued, so if Kamion uploads ubiquity, surely that will fix it.
<janimo> carlos, I just set its trans;lation domain to evince so we dont; add this to the base langpack too
<mdz> Keybuk: SATAN HAS YOUR TONGUE
<Keybuk> there's a casper upload in incoming
<Kamion> infinity: totem and some others too
<janimo> and would be duplication otherwise
<Keybuk> so that'll clearly make the problem go away
<carlos> ok
<infinity> Kamion: Oh, so I can blame totem?  Awesome.
<mdz> I'm not even sure what is in incoming at this point
<janimo> but if it's a problem for some reason I am ok with any solution you and/or pitti come up with
<mdz> I'd like to review them before we process the queue
<Kamion> ok, I'll start publishing now
<infinity> mdz: It's not too deep.
<janimo> same for xubuntu-system-tools and gnome-system-tools
<mdz> Kamion: sounds good
<infinity> Kamion: Make sure to take the 20060524 image for amd64... That's the one I put through rigorous testing yesterday.
<Kamion> infinity: right. you wouldn't mind repeating that test now, would you?
<Kamion> at least see that it boots
<Kamion> not that I'm PARANOID or anything
<infinity> Kamion: I still have the CD from yesterday.  Where do I verify the serial number?
* Kamion blames the imps sneaking onto lithium and rearranging the bits.
<Keybuk> maybe it's the squashfs authors birthday or something
<Kamion> infinity: .disk/info
<mdz> infinity: F1 at gfxboot, or that
<janimo> carlos, do you know what jordi wants to talk to me about (if still relevant)?
<Kamion> call me old-fashioned
<Keybuk> whoah
<mdz> Keybuk: or maybe the clock has rolled over to a bit pattern which breaks all amd64 CPUs
<Keybuk> NMI Watchdog detected LOCKUP on CPU 0
<mdz> Keybuk: I got one of those too!
<Kamion> BTW, nobody run sync-mirrors on lithium for a while kthxbye
<mdz> it's so completely fucked
<carlos> janimo: he needs a list of core XFCE packages that should be translated first
<Keybuk> that was just find on the squashfs
<Keybuk> it's definitely the squash, not the union
* Keybuk wonders whether it's still going
<mdz> Keybuk: or even lower
<janimo> he needs 
<mdz> Keybuk: squashfs doesn't explain the weird I/O errors
<carlos> janimo: only desktop and base libraries
<Keybuk> mdz: what is lower?
<janimo> carlos, should I mail him the list?
<infinity> Oh crap... Yesterday's doesn't work now either...
<Keybuk> there isn't anything between the filesystem layer and the ATA driver
* infinity ducks and runs for cover.
<carlos> janimo: if he's not around and you need to leave, yes, please
<infinity> Kamion: 20060524 booting fine.
<mdz> Keybuk: what makes you think the ATA driver isn't at fault? :-P
* Keybuk gets out of mdz's line-of-sight to infinity
<Keybuk> mdz: because we all have different ATA drivers
<mdz> you don't know what driver I have
<mdz> infinity: did you get I/O errors too?
<Keybuk> well, I know Tollef, infinity and I do ... because we've used that fact for testing before
<infinity> mdz: Yeah, but not from libata.  They were just on the loop0 block device, afaict.
<mdz> maybe someone unpacked the amd64 .deb on lithium
<mdz> installed a rootkit
<mdz> and put it back
<mdz> the kernel deb
<infinity> Kamion: Fully booted now.  Confirmed that 20060524 is fine.
<Keybuk> infinity: was 24.1 a rebuild of amd64 too?
<infinity> mdz: We don't use the kernel deb from lithium for livecd builds.  We use the kernel and initramfs that I export from the livefs build.
<Kamion> ok
* mdz peers suspiciously at infinity
<infinity> Keybuk: There was a 24.1?
<Keybuk> infinity: there was
<Kamion> publishing delayed while I recover archival copies of beta2
<jordi> janimo: hey
* Kamion glares sideways at publish-release
<mdz> Kamion: hmmm?
<Keybuk> infinity: and it has a different md5sum
<Keybuk> tell you what
<Keybuk> I'll check 24.1, shall I?
<mdz> Keybuk: knock yourself out
<Kamion> mdz: it cleans up old releases when you didn't need them any more ...
<jordi> so, yes, I'd like to talk to you about what's the order of most important xfce products
<infinity> Oh, there was too.  That would have been a slightly newer ubiquity..
<janimo> jordi hey
<mdz> infinity: is the livefs build log published somewhere I can see iT?
<jordi> hiya
<infinity> mdz: http://people.ubuntu.com/~cjwatson/livefs-build-logs/dapper/ubuntu/20060525.1/livecd-20060525.1-amd64.out
<Kamion> or ~lamont/liveLogs/
<mdz> thanks
<Keybuk> mdz: can you diff 24 and 24.1 and check what's the difference there?
<Kamion> example-content, gnome-power-manager, totem, ttf-arphic-uming, ubiquity, update-manager, update-notifier
<janimo> jordi, I understand you need a list of core xfce packages?
<mdz> squashfs automagically compresses out duplicate files? neat
<mdz> Keybuk: that's what I did
<jordi> janimo: any package added in main due to xubuntu I guess
<mdz> Keybuk: oh, you mean the manifests?
<Keybuk> mdz: 24 is known good, 25 is known bad
<jordi> but yes, the xf* packages are probably mostly it
<Keybuk> 24.1 is unknown
<mdz> Keybuk: manifests are identical
<Kamion> mdz: no they aren't
<Kamion> 18:13 < Keybuk> mdz: can you diff 24 and 24.1 and check what's the difference there?
<Kamion> er
<Kamion> 18:13 < Kamion> example-content, gnome-power-manager, totem, ttf-arphic-uming, ubiquity, update-manager, update-notifier
<mdz> Kamion: 24 to 24.1?
<janimo> jordi, ok I'll make a list
<Kamion> cjwatson@lithium:~/cdimage/www/full/daily-live$ diff -u 20060524{,.1}/dapper-desktop-amd64.manifest
<mdz> oh, I was redirecting the output
<mdz> hehe
<jordi> janimo: thanks!
* Keybuk sends mdz to stand in the corner
<mdz> yeah, bunch of stuff changed there
<Kamion> I'll delay publishing amd64 desktop until somebody tells me what to do
<mdz> +example-content 19
<mdz> +gnome-power-manager 2.14.3-0ubuntu10
<mdz> +libtotem-plparser1 1.4.1-0ubuntu4
<mdz> +localechooser-data 0.27ubuntu21
<mdz> +totem 1.4.1-0ubuntu4
<mdz> +totem-gstreamer 1.4.1-0ubuntu4
<mdz> +ttf-arphic-uming 0.1.20060513-1
<mdz> +ubiquity 1.0.6
<mdz> +ubiquity-frontend-gtk 1.0.6
<mdz> +ubiquity-ubuntu-artwork 1.0.6
<mdz> +update-manager 0.42.2ubuntu21
<Keybuk> Kamion: will tell you whether this works in ~2 minutes
<mdz> +update-notifier 0.42.5
<mdz> totem is mark's fix, he won't notice
<mdz> example-content is fairly significant though
<jordi> janimo: basically, if a translator had to start translating xubuntu from scratch, what would you tell them is the most visible package, with the most important strings, etc?
<Keybuk> mdz: ubiq 1.0.6 would be nice
<Keybuk> that has most of the bug fixes
<jordi> If I can get an ordered list of priorities, great
<Kamion> Keybuk: 1.0.7 has most of them
<Kamion> 1.0.6 only has the powerpc fix and bug 46395
<Ubugtu> Malone bug 46395 in ubiquity "Crash after comitting a delete of several partitions" [Normal,Fix released]  http://launchpad.net/bugs/46395
<Keybuk> so what changed in 25?  just openoffice?
<mdz> you know, we could dpkg -i ubiquity 1.0.7 into that chroot.......
<Keybuk> mdz: try it
<mdz> Keybuk: openoffice and ubiquity 1.0.7
<janimo> jordi, ok. That would be the all deps of xubuntu-desktop which are not alreday deps of ubuntu-desktop. But I can make a more explicit list
* Keybuk blames openoffice
<Kamion> ubiquity{,-frontend-gtk,-ubuntu-artwork}
<Keybuk> you introduced a black hole into the .desktop file
<Keybuk> the squashfs collapsed under its own mass
<infinity> It was more than just the .desktop file..
<jordi> janimo: thanks
<infinity> That was a huge OOo change for amd64.  It hadn't been updated for a month or more.
<infinity> Still, I can't see why that should break the freakin' squashfs. :)
<janimo> jordi, btw in the dapper language pack updates, will only stuff translated in rosetta appear?
<infinity> Maybe the author is punishing us for shipping the hideous hack that is OOo-i386-on-amd64.
<janimo> if upstream works on .po files on their own can that be imported too?
<jordi> janimo: it's the only way the language packs can collect new translations
<jordi> janimo: not atm, no
<janimo> ok
<Keybuk> infinity: perhaps we've opened a portal into another universe
<Keybuk> casper is going off the end of the squashfs and into HYPERSPACEFS
<sfllaw> mdz: I uplaoded new versions of WvStreams and WvDial into the archive.  Was I supposed to get e-mail notification?  Or did I do something wrong and they got silently eaten?
<infinity> I'd find this all rather more entertaining if it wasn't A WEEK BEFORE RELEASE.
<infinity> This bug better just magically go away on the next build...
<Keybuk> infinity: that'd only be more scary
<Keybuk> because it means it could COME BACK
<infinity> Keybuk: It can't come back once we ship pressed CDs.
<Keybuk> we should keep a tally of "Last known good AMD64" on Testing/Current
<Kamion> sfllaw: you won't get a notification until the queue processor is turned back on post-RC
<mdz> sfllaw: uploads are queued, /topic
<mdz> Keybuk: I don't have an amd64 where I can easily do that
<Kamion> I forgot to pre-publish server-sparc, whoops
<mdz> Keybuk: can you try it?
<sfllaw> mdz: You mean they are looked at manually.  Thanks.
<Keybuk> mdz: try which?
<infinity> mdz: There are only 20 uploads pending in incoming.  Not so scary.
<mdz> sfllaw: I mean they sit in limbo until we turn the automatic queue processor back on
<mdz> Keybuk: dpkg -i ubiquity_1.0.7*
<mdz> Keybuk: then re-mksquashfs
<Keybuk> mdz: I don't have access to lithium
<mdz> stir the entropy pool a bit
<Keybuk> unless there's a rune I can use on my console here to make a new cd iamge
<mdz> Keybuk: what does lithium have to do with it?
<mdz> Keybuk: there is
<Keybuk> can you paste, and I shall do
<Keybuk> 24.1 breaks
<infinity> mdz: That's not possible, actually.
<Keybuk> so it was't openoffice
<mdz> infinity: what?
<sfllaw> mdz: My real question, I suppose, is "did I do everything I needed to do to fix these bugs?"
<mdz> sfllaw: yes, thanks
<Kamion> you'd have to copy the whole tree and then dpkg -i
<sfllaw> mdz: Cool.
<infinity> mdz: squashfs is read-only.  Can't copy out of it to another directory to dpkg -i stuff, because it's not readable.
<infinity> mdz: Chicken, meet egg.
<mdz> infinity: 24.1 is readable, isn't it?
<infinity> mdz: Oh, duh.  Yeah.
* infinity was thinking backwards.
<mdz> it also happens to be b0rked also
<mdz> Keybuk: that is VERY DISCONCERTING
<infinity> I could just dist-upgrade the known-good 20060524 and re-squash it.
<mdz> infinity: worth a shot
<infinity> Maybe something in example content is confusing the &^$#$ out of squash's compression algorithm? :)
* ogra scratches head and wonders why his amd64 edubuntu isos are all fine then
<Keybuk> infinity: that's what I was thinking of blaming next :)
<janimo> jordi, oh so not just a list of packages but which are the most visible (i.e most worth translating?)
<mdz> that would explain ogra's results
<mdz> he doesn't ship example-content
<ogra> example-content ? 
<ogra> yeah
<Keybuk> infinity: is it easy to make one with everything but that, and one with that too
<infinity> Does kubuntu ship it?
<Keybuk> infinity: burning kubuntu right now
<mdz> infinity: yes
<Keybuk> yeah, example-content 19 on this image
<mdz> [2]   + segmentation fault  sudo cp -a /mnt /tmp/amd64-livefs
<mdz> that's on i386
<jordi> janimo: yeah, that's it
<Kamion> so 24.1 broken, I'm publishing 24?
<mdz> trying to make a copy of the livefs
<jordi> janimo: what you guys would want to get translated first.
<mdz> Kamion: so far, yes
<mdz> who verified 24?
<Keybuk> Kamion: 24.1 is broken
<Kamion> infinity did
<Keybuk> infinity has verified 24
<infinity> mdz: I verified 24.
<mdz> [4391213.265000]   [<f917931b>]  squashfs_read_data+0x10b/0x490 [squashfs] 
* mdz cries
<janimo> jordi: ok, so does this still mean al packages need to be mentioned in sort of descending order of importance? Like devel libarries and such too?
<Kamion> BenC: around?
<infinity> Good thing we're not hinging our installer on this technology or anything.
<Kamion> BenC: might be good to start tracking down the kernel bug here while we still can ...
<Kamion> in case it disappears tomorrow and then comes back on release day
<mdz> not that that's ever happened before...
<jordi> janimo: yeah, if possible I want to know which are the user visible, most important
<Kamion> (has it? trying to remember)
<jordi> and go down in importance until those that are only console or so
<jordi> if any
<janimo> jordi: ok, got it 
<jordi> ok!
<ogra> we always had this oops during boot that dint do any harm ... probably it just got harmful 
<ogra> *didnt
<jordi> sorry, I thought you had a clear explanation already and I was assuming things :)
<BenC> Kamion: which kernel bug
<infinity> BenC: The last 1000 lines of painful scrollback.
<Keybuk> BenC: the PANIC when you boot the AMD64 Desktop CD
<BenC> squashfs?
<Kamion> yes
<mdz> BenC: apparently, though it's weird
<BenC> is there a bug report?
<Kamion> (apparently)
<mdz> BenC: no, this is real-time
<BenC> ok, let me read
<Riddell> infinity: yes
<Keybuk> everybody hold hands and pray for kubuntu
<infinity> ARGH.   I need to reboot.  My mounted squash is hung on those cats from ages back.
<infinity> Riddell: Context?
<ogra> infinity, he just thinks positive :)
<mdz> Riddell: kubuntu/amd64/desktop: busticated or no?
<ogra> (example-content)
<infinity> Riddell: Oh, that was "do you ship example-content"
<Keybuk> KUBUNTU HAS BOOTED
<mdz> Keybuk: ah, but does it install?
<BenC> about the only thing I can do is download the ISO and see what's up
<mdz> Riddell: have you tested the amd64 desktop CD?
<Keybuk> mdz: I'm just doing a find | cat
<mdz> BenC: what version do you have currently?
<Keybuk> and I got a "Hard link count is wrong for /lib/modules/2.6.15-23-amd64-generic/kernel/net"
<mdz> BenC: both 20060524.1 and 20060525 exhibit the problem
<iwj> I'm going to go and buy a damned spare disk tomorrow.  This is just too flakey.
<mdz> Keybuk: unionfs does that sometimes
<Kamion> iwj: I suggest a blessed one instead
<Riddell> yes we ship example content on kubuntu, no I've not had any hangs on any 6 of the CDs
<mdz> Keybuk: find /rofs instead
<mdz> infinity: do you save the livefs in another form?
<BenC> are the CD's using squashfs2 or squashfs3?
<iwj> Malone 93183: Installation fails on cursed -3 disk.
<mdz> infinity: which could be used for the dpkg/mksquashfs experiment without having to get things out of the existing squashfs?
<mdz> infinity: or are you proceeding with the dist-upgrade+mksquashfs experiment?
<mdz> BenC: they're using whatever you ship in the kernel
<mdz> BenC: 3.0prerelease I think?
<BenC> the squashfs in the kernel supports both versions of hte fs
<BenC> it all depends on which mksquashfs program is being called
<mdz> /mnt/casper/filesystem.squashfs: Squashfs filesystem, little endian, version 2.1, 631275173 bytes, 81923 inodes, blocksize: 65536 bytes, created: Thu May 25 16:58:35 2006
<mdz> BenC: ^^
<Keybuk> mdz: which is that?  that's not 25
<BenC> any chance of testing a version 3 filesystem?
<ogra> Keybuk,  created: Thu May 25 ?
<Keybuk> the size is wrong
<Keybuk> AMD64 #25 was 621,375,520
<BenC> damnit...squashfs-tools only contains the v2 creator
<mdz> Keybuk: really?
<Keybuk> mdz: yes
<BenC> I though Mith or someone was going to shove mksquashfs3 into the package too
<Keybuk> (Kubuntu passed find|cat ... so it's unique to Ubuntu)
<mdz> BenC: we are so not changing that right now
<BenC> must be a variance in mksquashfs
<Kamion> perhaps we should have mksquashfs3 in there as well so that at least we *can* experiment ...
<BenC> yeah, that's what I'm saying
<ogra> but the same mksquashfs is used for all derivatives as well
<ogra> and they work ...
<Kamion> and it's worked for Ubuntu for quite some time as well, but now it doesn't
<BenC> ogra: and amd64 is the only one that is 64-bit userland :/
<mdz> ogra: the same one was used for all the previous amd64 images, too; htat's not the point
<Keybuk> ok
<Keybuk> that's kinda interesting
<mdz> we changed its input
<jcole> if someone has time, kernel build help please -> http://pastebin.com/737508
<Kamion> jcole: this isn't really a good time ...
<ogra> jcole, really not today, not here
<BenC> jcole: #ubuntu-kernel
<jcole> BenC: whew, awesome
<infinity> squashfs-tools in Debian has been at 3.0 for ages, IIRC, we vetoed the version bump in dapper in April.
<infinity> Anyhow, back from my reboot of doom.
<infinity> mdz: Doing the experiment now.
<mdz> infinity: which one?
<BenC> maybe do "touch /lib/modules/2.6.15-23-amd64-generic/kernel/net/fixerup" to see if that varies things enough to work? :)
<infinity> mdz: extract->distupgrade->squash
<mdz> infinity: extract doesn't blow up?
<Keybuk> ah no, the size thing isn't interesting
<infinity> mdz: Err, not there yet.  Just rebooted.
<mdz> Keybuk: I'm not sure what I have; cdimage won't talk to me anymore
<Keybuk> file always thinks that the squashfs size is smaller than the real file size
<Keybuk> I must have typo'd the 621 ... it was 631
<Keybuk> the file is < 512b bigger than the squashfs size
<BenC> anyone have the squashfs for the amd64 that I can simply grab real quick?
<lucasvo> anybody know a kbabel gtk equivalent ?
<BenC> will be much faster then the whole cd
<Kamion> ? the squashfs is only fractionally smaller than the CD
<ogra> lucasvo, wrong channel, wrong time
<infinity> BenC: What Kamion said.  They're nearly the same size.
<BenC> oh, crappy
<mdz> BenC: which version of the CD do you currently have? the rsync delta shouldn't be too large
<BenC> in that case, anyone have a place where I can download it faster then 35k/sec?
<mdz> you can get the pre-oo.o update version
<BenC> mdz: The only amd64 one I have is flight6
<BenC> that one worked fine for when I did the install on my k8
<iwj> I wonder why the d-i installer is so much flakier with this disk than ubiquity was earlier ?  I suppose it might actually be a bug but I dan't really tell.
<Keybuk> hmm
<Keybuk> the problem would appear to be in /var
<mdz> BenC: that's almost two months old
<infinity> Keybuk: How did you deduce this?
<janimo> jordi at ubuntu.com?
<BenC> mdz: yeah, it's useless
<Keybuk> infinity: the last three finds I've done have crashed there
<jordi> janimo: yeah!
<BenC> Keybuk: crashed the computer, or just crashed find?
<ogra> Keybuk, now diff /var of ubuntu with /var of kubuntu/edubuntu ;)
<Keybuk> BenC: PANIC Aiieeee etc.
<infinity> Keybuk: Well, squashfs sorts before it builds, so if we're doing overlong reads, you'd expect stuff near the end to cause more problems than stuff near the beginning.
<infinity> Keybuk: Doesn't mean much...
<BenC> do you have a full panic I can look at?
<Keybuk> BenC: how do I save it?
<BenC> Keybuk: digitial photo would be perfect
<infinity> Okay, extracted the whole 24 livefs without a whisper in dmesg.  Chrooting in to dist-upgrade.
<BenC> and easiest
<Keybuk> BenC: hmm, I'd need to see if I can the video mode to be *really* high res :)
<mdz> these filesystems are so close, it's silly
<BenC> Keybuk: vga=ask
<BenC> see if that gets you something
<Keybuk> BenC: it appears not
<Keybuk> infinity: if the filesystems are odd, I'd expect it to go wrong somewhere else though, no?
<infinity> Keybuk: vga=771
<infinity> Keybuk: Or 791
<Keybuk> infinity: which is higher res?
<infinity> Not sure.
<Kamion> all releases.u.c changes syncing out now
<infinity> Mine is vga=0x343 (1440x1050)
<infinity> That high enough for you?
<mdz> Keybuk: what's your /var hypothesis based on?
<Keybuk> mdz: that's where find crashes, but as infinity says, that could just be sorting
<infinity> Kamion: Is this the part where we rejoice that SOMETHING went out, or continue crying about amd64? :)
<lamont> mdz/kamion: it would be wonderful if we could fix 46496 post-RC
<BenC> find doesn't sort does it?
<Kamion> janimo: xubuntu is good to release, right?
<mdz> lamont: talk to me about it tomorrow please
<Kamion> for RC
<lamont> mdz: will do
<infinity> BenC: The squashfs is sorted.
<lamont> BenC: no
<bddebian> Not a bug but if capslock is hit on gksudo window, it screws up the display of the OK/Cancel buttons
<Kamion> janimo: (urgently - I have to go in about 8 minutes)
<Keybuk> vga=791 will do
* Kamion pushes the button anyway on the basis that it will take a while to publish ...
<jordi> janimo: got it!
<mdz> Kamion: just exclude it
<infinity> Well, aren't we glad I fixed the "vesafb doesn't work without splash onthe command line" bug? :)
<mdz> or not
<Kamion> mdz: it's for cdimage.u.c not releases.u.c
<Kamion> (releases doesn't have room, last I checked ...)
<Keybuk> sweeeeeet
<jordi> janimo: you mean xubuntu-docs is the most important?
<mdz> Kamion: so it only matters for the announcement then, yes?
<Keybuk> cat /mnt/spool/cron/atjobs/.SEQ
<Kamion> mdz: yes, was hoping to get it out pre-announcement so that we didn't need a second one
<Keybuk> SQUASHFS error: zlib_fs returned unexpected result 0xfffffffd
<Kamion> it'll be done in a few minutes
<ogra> eek
<Keybuk> SQUASHFS error: Unable to read fragment cache block [0] 
<Keybuk> SQUASHFS error: Unable to read page, block 0, size 0
<mvo> bddebian: thanks, its reported in lp
<mdz> Keybuk: /mnt/spool? or /mnt/var/spool?
<Kamion> Keybuk: you're going to tell me this is a 1 in 2^32 chance, aren't you
<bddebian> mvo: OK, thx
<Keybuk> mdz: /mnt/var/spool
<mdz> Keybuk: that's probably Z_DATA_ERROR
<Keybuk> Kamion: we wouldn't see it on three cd images if it were
<bddebian> Are only core devs supposed to add info to the Testing/Current page?
<Kamion> Keybuk: we might do, if the relevant region of the filesystem didn't change in there
<mdz> bddebian: test results are welcomed from everyone
<infinity> bddebian: More testing is good, though we want core-dev coverage on each ISO.
<mdz> bddebian: if you saw something which gave you a different impression, fix it ;-)
<infinity> bddebian: Non-core coverage is also really cool. :)
<bddebian> mdz: OK, thx
<Keybuk> Kamion: the file that's particularly upset it (and made it crash) is 
<Keybuk> shockingly
<Keybuk> /var/lib/apt/lists/...
<bddebian> Hmm, maybe I don't have a login for the wiki.kubuntu.com?
<giftnudel> bddebian: take your launchpad login
<giftnudel> ahh missed te k
<bddebian> Is there a Testing page on wiki.ubuntu.com also?
<mdz> Keybuk: what's the best break= to use for fiddling with this?
<giftnudel> yes
<Keybuk> mdz: break=casper-bottom
<jcole> do rejected/closed bugs get deleted after a while? http://tinyurl.com/k7avz
<Keybuk> then you have /root mounted
<Kamion> OK, Xubuntu going out now (http://cdimage.ubuntu.com/xubuntu/releases/dapper/rc/). The rest (stuff like ports) can happen after I get back.
<Kamion> jcole: no
<giftnudel> bddebian: probably not for kubuntu
<mdz> Keybuk: thanks
<LaserJock> bddebian: i thought they were the same wiki, ubuntu, kubuntu and edubuntu
<Kamion> jcole: you might have to use advanced search though
<Keybuk> http://people.ubuntu.com/~scott/crash0.jpg
<Keybuk> http://people.ubuntu.com/~scott/crash1.jpg
<Kamion> mdz: Ubuntu (including server), Kubuntu, and Edubuntu all done too, on releases.ubuntu.com. You might want to check up on mirroring status yourself when you're doing the announcement.
<Keybuk> BenC: ^^
<Kamion> Sweden should be triggered
<Kamion> us.releases seems hopelessly buggered (IIRC out of disk or something)
<bddebian> LaserJock: Maybe they are?
<bddebian> Gah meeting :-(
<Kamion> mdz: and I'm off, please SMS me if the sky falls down and there may be something I can do to get network access
<Keybuk> note that weird ./lib/apt/lists/security.ubuntu.com./lib/apt/lists/security.ubuntu.com path
<BenC> Keybuk: Looks like the real cause is in zlib
<BenC> it's getting bad compressed data, or squashfs is handing it some corrupted data or similar
<BenC> s/cause/crash/
<mdz> BenC: I have a trace for you
<BenC> cause is obviously squashfs
<mdz> a trace with no squashfs code in it though
<mdz> reproduced by mounting the squashfs on an i386 system and doing 'ls' in /var/lib/apt/lists inside the squashfs
<BenC> SQUASFS error: zlib_fs returned unexpected result ...
<BenC> mdz: ok, send it over
<BenC> "Unable able to read page, block 0, size 0"
<BenC> that's interesting too
<mdz> BenC: mailed
<mdz> BenC: (sent you the whole dmesg)
<BenC> ok, thanks
<Keybuk> bluetooth does work nicely now
<Keybuk> it's far easier just to send stuff from phone to computer that way than find the usb cable
<infinity> Uhh, did anyone else get mail from Joerg Bashir <brak@archive.org> in the last two hours?
<Keybuk> http://people.ubuntu.com/~scott/crash2.jpg
<Keybuk> BenC: ^ that's another interesting one
<mdz> Keybuk: that trace is fucked
<Keybuk> mdz: it is?
<Keybuk> I like that it wants to go four times off the end of the squashfs :)
<mdz> it's missing the middle bit
<mdz> the stack
<Keybuk> heh
<mdz> it has the location of the crash and then the Code: line
<Keybuk> so it is
<ogra> infinity, no
<mdz> infinity: how's the experiment going?
<BenC> "attempt to access beyond end of device"
<infinity> mdz: Burning the experiment right now.
<Keybuk> BenC: any other prodding that would be useful to you?
<BenC> I'm thinking that the filesystem is just plain borked and that these crashes are just the result of the kernel module not doing enough sanity checking
<mdz> wow
<BenC> the real problem seems to be in the mksquashfs
<Keybuk> three consecutive filesystems have been borked in this manner
<Keybuk> so it must be some file we added in 24.1
<BenC> anyone tried creating the filesystem on i386 instead of on amd64?
<BenC> I wouldn't be surprised of mksquashfs wasn't 64-bit safe
<sven-tek> Hi devels, just tried to get you latest work. But gnome-btdownload says "Requested download is not authorized for use with this tracker.", is the server overloaded or something?
<mdz> wow
<Keybuk> mdz: ?
<mdz> accessing /var/spool/cron/atjobs/.SEQ in vmware
<mdz> causes vmware to implode
<Keybuk> infinity: no
<mdz> *** Virtual machine kernel stack fault (hardware reset) ***
<BenC> lol
<mdz> "On a real computer, this would amount to a reset of the processor"
<BenC> squashfs rules
<Keybuk> mdz: yeah, I had one of those earlier
<Keybuk> it reset one of the two cores
<mdz> [ ]  Never show this dialog again
* mdz dies laughing
<Keybuk> mdz: has that tickled you?
<BenC> 7 more hours to download this amd64 iso
<infinity> mdz: What a friendly emulator! :)
<mdz> does squashfs have a super duper debug mode?
<bgertzfield> Howdy folks.
<BenC> there has to be a faster way :/
<mdz> bgertzfield: hi, you know much about squashfs?
* BenC resorts to torrent
<bgertzfield> mdz: Nope!
<mdz> damn, was worth a try
<BenC> bah, can't do torrent unless I want to disable uploads
<Keybuk> even Ubugtu has fled in fear
<mdz> somebody get Phillip Lougher's home address
<ogra> mdz, #squashfs is also empty (while we're at trys)
<infinity> He'll just tell us to use 3.0.
<infinity> Which may have been a sane plan... Last month. :)
<infinity> (It may still be saner than debugging this)
<Keybuk> mdz: Wales somewhere
<infinity> mdz: I can drop the debian 3.0 packages in king's livefs-building chroot and respin that fs for kicks.
<mdz> infinity: is there a real RCS somewhere or just the sourceforge CVS?
<mdz> infinity: better to do it locally so you can test faster, no?
<infinity> mdz: I don't know yet if I can reproduce it locally. We know that every build on king in the last 2 days has gone tits-up.
<infinity> But yeah, I should reproduce it locally for sanity's sake.
<infinity> mdz: And I have no idea where upstream source lives.
<Keybuk> squashfs.sourceforge.net ?
<infinity> Well, other than that. :)
<mdz> the log message in the CVS seems to imply there's something else
<mdz> BenC: what's the date of our squashfs prerelease?
<infinity> Okay, extra->dist-upgrade->rebuild blew up in exactly the same way,
<infinity> extract, even.
<infinity> So, I can reproduce it locally.
<janimo> Kamion, yes xubuntu is good for RC
<BenC> mdz: quite a while back
<Keybuk> infinity: how long does an experiment take?
<Keybuk> can you shell script it?
<infinity> (And sitrring in entropy didn't help)
<infinity> Keybuk: Depends on what I'm doing with said experiment, I guess.
<mdz> there are no interesting bug fixes in the past 6 months or so
<Keybuk> well, we have the list of packages that changed between 24 and 24.1
<mdz> in CVS, that is
<Keybuk> so we could make an image for each, which has 24 with just that package upgraded
<Keybuk> and see which one(s) break
<mdz> it seems likely that it's some pattern of file contents/sizes that triggers it
<infinity> mdz: Except that upstream's entire focus is now on 3.0, and we're still using 2.0...
<mdz> infinity: there's only one CVS tree with both in it
<mdz> and there hasn't been anything interesting for a long time
<mdz> 5 days ago there was:
<mdz> Fixed 2.6 kernel code to remove rare race condition when multiply mounted
<mdz> Squashfs filesystems are simulataneously accessed.
<infinity> mdz: Well, yes, but if this bug doesn't exist in 3.0, he's not likely to find it or care about fixing t in 2.0, that was my point.
<mdz> squashfs3 was imported 6 months ago and has hardly changed since then
<infinity> Whack.
<infinity> Kay, he's almost certainly using another RCS,then.
<infinity> Or he just lost interest.  Which seems unlikely with a project like this.
<mdz> the best part is that the bug isn't arch-specific
<mdz> it very well could hit us again elsewhere
<Keybuk> git probably
<ogra> according to murphy it would hit us on release day
<infinity> Well, unless, as BenC surmises, it's a combination of an arch-specific bug in mksquashfs on amd64, and poor error checking in the kernel driver.
<infinity> Which is possible.
<janimo> jordi, I think xubuntu-docs is important but yes, maybe not the most :)
<jordi> janimo: ok. it's the first in the list :)
<janimo> I have no idea what users would rather like to be translated.
<janimo> jordi: well yes I put it there since I tought it was very important
<jordi> janimo: ok
<mdke> janimo, jordi, what's going on with xubuntu-docs?
<jordi> mdke: it won't fit in the CD and I decided to get rid of the docs!
<janimo> mdke, making a prioritiezed list of apps to be translated in rosetta
<jordi> no, raelly, we're discussing translation priorities
<mdke> but isn't it in rosetta already?
<mdke> oh, priorities
<jordi> :)
* mdke slaps himself
<infinity> Keybuk: TBH, I think I'd rather sleep than build a dozen incremental squashfses... But that sounds like a fun project for tomorrow.
<mdz> infinity: that's easy to test
<mdz> infinity: mksquashfs the same data on a different arch
<infinity> Yeah.  Freeing up space on the laptop to do that right now.
<infinity> Damned OOo.  I had 700MB of crap in cache/apt/archives
<mdz> I would try that, but I can't manage to get the data out of the squashfs intact anywhere
<mdz> infinity: do you save a copy on the buildd in another form?
<rddp> I guess you guys know amd64 is fubar'd right? Is i386 ok for d/l + testing?
<mdz> rddp: yes, see the past hour or so of scrollback
<infinity> mdz: No, but it mightn't be a bad plan to do that in the future...
<mdz> rddp: the problem only affects ubuntu/amd64/desktop at the moment
<rddp> ah ok sorry :)
<Keybuk> infinity: fair enough
<mdz> infinity: did you save your dist-upgraded tree by any chance?
<infinity> mdz: Yes.  taring that up and sending it to my laptop.
<ogra> rddp, kubuntu and edubuntu are fine (in case youre hot to test amd64 CDs)
<rddp> just wanted to test for grepping plain text passwords and so forth :-p
<rddp> ogra, will do
<mdz> infinity: I don't suppose there's an un-mksquashfs userland utility
<mdz> infinity: and you don't still build cloops
<infinity> mdz: No, we only build cloop or squasfhs, never both.  Disk usage would be horrendous, and time wasted would be even worse.
<infinity> mdz: "unmksquashfs" is the kernel driver.  Just like "unmkisofs" :)
<infinity> (too bad that doesn't work..)
<mdz> is there a different version of the kernel driver, with different bugs, that we might try just for uncompressing purposes?
<mdz> this filesystem is our only test case and we can't manipulate it :-P
<infinity> I haven't the foggiest.
<mdz> I'm going to see about building a version with tracing enabled
<infinity> BenC: Where are we getting the kernel driver from?
<mdz> actually, that's probably easier for BenC
<mdz> BenC: could you build a 386 squashfs module with SQUASHFS_TRACE?
<BenC> yeah
<BenC> mdz: Since you are on 386, can you rebuild the fs on there and see if it has the same problem?
<mdz> BenC: see above
<mdz> I can't rebuild the FS because the squashfs driver is the only way to extract it, and the driver crashes
<Keybuk> mdz: at least all versions of the filesystem that we create exhibit the bug
<BenC> mdz: mksquashfs /mnt ?
<mdz> BenC: find |xargs cat crashes it
<Keybuk> BenC: the bug would be tripped by mksquashfs reading /mnt
<BenC> oh wait
<BenC> yeah
<Keybuk> mdz: how does mksquashfs get run on lithium
<Keybuk> just "mksquashfs" ?
<mdz> infinity has an uncompressed copy of a filesystem which exhibits the problem
<infinity> Keybuk: It doesn't.  (but yes, on the buildds, it's invoked with no options)
<mdz> Keybuk: it doesn't; it gets run on the buildds
<infinity> Does someone want to buy me a bigger and faster hard drive for my laptop for Christmas?
* infinity waits while it grinds away on a probably horribly fragmented file..
* Keybuk was wondering whether we had any "Holey" files or anything like that
<Keybuk> like did someone accidentally ship a core file
<infinity> sparse files, even?
<Keybuk> yes, those
<infinity> I would hope sparse files would be handled correctly anyway, but that's easy to test with dd.
<Keybuk> dd
<Keybuk> ?
<mdz> mksqashfs would have to try hard to realize it was dealing with a sparse file
<Keybuk> it was just a thought
<mdz> we could binary diff the working and non-working fses
<mdz> then stare really hard at a hex dump
<Keybuk> mdz: I don't especially enjoy reading diffs of gzipped stuff ;)
<mdz> Keybuk: I'm guessing the problem isn't with the compressed data itself but with the filesystem metadata
<infinity> Keybuk: yes, dd.  As in "dd if=/dev/zero bs=1k of=foo seek=25637204 count=0"
<Keybuk> mdz: yet it's definitely being caused by a new or changed file
<Keybuk> infinity: ah, you mean make one
<infinity> Keybuk: A 26252496896 length file tha ttakes 0k of real space.
<infinity> Keybuk: Yeah, make one, mksquashfs it, mount it. see what happens.
<infinity> But I'd be shocked to discover that sparse files break anything..
<infinity> (Although... If it's trusting file lengths, and there was a core from a machine with 2G of RAM, that could account for huge seeks past the end of our 650MB device...)
<infinity> That would be pretty painfully stupid, though.
<Keybuk> infinity: 4*650 > 2GB
<BenC> mdz: -386, right?
<Keybuk> which is where my idea came
<mdz> elmo: can you smack the torrent tracker around?
<mdz> BenC: yes
<Riddell> mdz: separate or joint announcements for kubuntu/ubuntu/edubuntu?
<infinity> Well, the buildds have a mess of RAM, so it's not inconciveable that we're accidentally dropping a core somewhere.
* ogra votes for joint
<mdz> Riddell: joint announcement
<Riddell> ok, good with me
* Keybuk supplies the munchies
<Znarl> mdz : I'll headbutt the torrent tracker for you.
<mdz> Riddell: can you update https://wiki.ubuntu.com/DapperReleaseCandidateAnnouncement accordingly?
<mdz> Keybuk: I can't even do an ls -lR on the filesystem, it crashes
<pitti> hi
<mdz> pitti: welcome to the fire
<Keybuk> mdz: I'll see if I can do a find
<Keybuk> pitti: we've blamed you for all that's happened today
<ogra> pitti, learn all about squashfs, QUICK !
<infinity> Err, wait... The 25.1 Ubuntu livefs was the last one I build on king...
<pitti> ouch, is it that bad?
<infinity> mdz: I do have that chroot still.  Want a tarball of it?
<mdz> infinity: absofuckinglutely
<pitti> my tests from yesterday finally looked quite good after yesterday's fixes
<ogra> pitti amd64 ubuntu live only ...
<pitti> ogra: itz broken?
<ogra> all others are fine 
<mdz> pitti: kernel panics
<mdz> pitti: squashfs related
<Keybuk> mdz: I think I just managed to get a file listing
<Keybuk> by just doing opendir/readdir (no stat)
<mdz> Keybuk: as root or non-root?
<infinity> pitti: You know squashfs inside and out, right?
<Keybuk> mdz: root
<pitti> infinity: of course, I could rewrite it in assembler while sleeping
<mdz> Keybuk: yep, me too
<infinity> mdz: ^^^
<infinity> MAKE PITTI FIX IT.
<Keybuk> mdz: find -ls has pretty much worked
* pitti decides that it was a bad move to look into irc today
<Keybuk> ok, so we have a contents list of 20060524.1
<infinity> pitti: You should know better than to tarnish your VAC with work.
<Keybuk> OH, BUT OF COURSE I CANNOT UNMOUNT IT NOW
<infinity> Keybuk: Cause one of your many cats or lses has hung.
<BenC> mdz: sent
<infinity> Keybuk: lsof will kindly remind you of that.
<Keybuk> infinity: not that I can see
<Keybuk> squashfs just won't let go
<Keybuk> or, possible, HAS let go
<Keybuk> SUB time!
<infinity> mdz: chinstrap:~adconrad/chroot-livecd.tgz
* jdub hulk-smashes sounder.
<tseng> hiya jdub 
<jdub> yo tseng 
<mdz> BenC: what do I put in kernel.printk to get the squashfs messages on the console?
<Keybuk> jdub: are they not obeying your every command and whim?
<jdub> no
<jdub> they're being unruly children
* jdub puts bananas in sounder's exhaust pipe
<mdz> BenC: never mind, got it
<Keybuk> http://people.ubuntu.com/~scott/24.1-ls.txt
<Keybuk> vs.
<Keybuk> http://people.ubuntu.com/~scott/24-ls.txt
<ogra> got a diff as well ? 
<Keybuk> diff it yourself! :)
<Riddell> mdz, ogra: https://wiki.ubuntu.com/DapperReleaseCandidateAnnouncement
<Riddell> the edubuntu homepage is looking very nice these days
<ogra> yep, even its still WIP
<Keybuk> http://people.ubuntu.com/~scott/diff.txt
<ogra> but i can borrow you highvoltage if you want a new css for kubuntu :)
* ogra throws kisses at Keybuk 
<infinity> I blame ttf-arphic-uming
<Keybuk> infinity: with knowledge or without?
<infinity> None whatsoever.
<infinity> Waitaminute.
<infinity> Nah.
* Keybuk tests your hypothesis
<infinity> There's no chance that /usr/share/example-content/Experience\ ubuntu.ogg and /usr/share/example-content/Ubuntu\ Sax.ogg are the only two files in the entire filesystem with spaces in the names, is there?
<infinity> (Cause they're both new in this diff)
<Keybuk> infinity: they are, actually
<Keybuk> actually, no, they're not
<Keybuk> there's some in /usr/share/acpi-support
<infinity> Okay, then that's probably a red herring.
<giftnudel> is it one of the files in /var/lib/dpkg that's where the problem appeared, right?
<infinity> Stuck out like a sore thumb in the diff, though.
<infinity> giftnudel: No.
<ogra> does anybody else find it weird that several directorys changed size without having any changes in them ? 
<Keybuk> so, I'm going to upgrade ttf-arphic-uming in the chroot
<giftnudel> ogra: i did
<Keybuk> ogra: could just be a sideffect of squashfs losing the will to live
<ogra> yes, but still, its quite noticeable
<infinity> Uhm, did libapm1 really stop shipping a postrm in that window, or is this just another "the filesystem is lying" thing? :)
<Keybuk> infinity: oh, that's quite odd, given it allegedly wasn't upgraded
<infinity> Must be the latter.
<mdz> BenC: http://people.ubuntu.com/~mdz/temp/squashfs-dmesg
<mdz> that's a log of a crash with SQUASHFS_TRACE on
<Keybuk> previous.svg ?
<mdz> Keybuk: icons
<Keybuk> mdz: totem?
<Keybuk> ubiq-artwork?
<mdz> Keybuk: Tango / Tangerine
<mdz> ubuntu-artwork
<Keybuk> meh, that wasn't updated :-/
<mdz> Keybuk: are you able to trigger a crash with any of that stuff?
<Keybuk> mdz: I'm trying to build a filesystem that crashes from 20060524
<infinity> I still really want to blame example-content, and those files with the spaces in the names, but that's probably just the UNIX elitist in me talking.
<mdz> Keybuk: I have infinity's tarball
<mdz> Keybuk: so I can get a full file listing from that
<mdz> Keybuk: I want to compare that to 20060524
<Keybuk> mdz: infinity's tarball crashes, yes?
<Keybuk> mdz: http://people.ubuntu.com/~scott/24-ls.txt
<infinity> Keybuk: It's a tarball of the exact chroot that 25.1 was built from.
<Keybuk> that's the content (ish) of 24
<mdz> Keybuk: yes, it does
<BenC> mdz: reading through it
<Keybuk> infinity: e-c is on kubuntu though :-/
<BenC>                                 TRACE("Filldir returned less than 0\n");
<BenC>                                 goto finish;
<BenC> I wonder if that should error out somehow instead
<infinity> Keybuk: And kubuntu was fine?  Poop.
<infinity> Keybuk: I can still dream, can't I?
<infinity> In fact, maybe I should go do that right now.
<infinity> Hit the hay and dream that example content was to blame and we fixed it and then we all went out for ice cream, skipping hand-in-hand.
<ogra> ice cream is good 
<yuriy> poke YokoZar
<Keybuk> infinity: it wasn't ttf-arphic-uming
<Keybuk> sorry
<mdz> Keybuk: your'e going package-by-package?
<Keybuk> mdz: why not?
<mdz> Keybuk: a binary search would be quicker
<Keybuk> binary search of what?
<mdz> the set of packages changed
<mdz> do half, then do the other half, see if it's even going to lead anywhere
<Keybuk> oh, I guess
<Keybuk> there's only 5 of them though
<mdz> sucks to try one by one only to find it fails on the last step, and only upgrading that package doesn't trigger the bug
<mdz> well, ok
<mdz> then later we get to do the same thing with files!
<BenC> mdz: I sent another module
<BenC> I want to see the value that filldir is returning
<fabbione> who was pinging me before??? the nick has been lost in the scrollback
<Keybuk> I like this computer
<Keybuk> it can keep entire ISO filesystems in its page cache
<infinity> 09:02 < sfllaw> fabbione: Ping?
<infinity> fabbione: "/lastlog fabbione" is your friend.
<fabbione> infinity: also on xchat?
<Keybuk> fabbione: yes
<fabbione> so it seems
<fabbione> neat
<fabbione> thanks
<infinity> You use xchat? :)
<fabbione> sfllaw: pong?
<infinity> Console users are dropping like flies...
<fabbione> infinity: i still use BX for other stuff
<mdz> Keybuk: garrr
<Keybuk> mdz: avast!
<mdz> Keybuk: the sizes of directories in squashfs show up differently than the tarball extracted onto ext3
<Keybuk> mdz: yes, I noticed that too :)
<Keybuk> so did ogra
<Keybuk> also there's a postrm missing
<pitti> good luck, guys! /me crosses fingers
<Keybuk> oh, interesting
<Keybuk> ok, now adding just that one package crashed it
<Keybuk> let's try making one without that package
<Keybuk> but with all the others
<mdz> squashfs also doesn't do the hardlink count properly
* mdz excludes more columns
<sfllaw> fabbione: The reason I pinged you has been addressed.
<sfllaw> fabbione: But thanks.
<fabbione> sfllaw: no problem.
<infinity> Keybuk: Which package?
<infinity> Keybuk: The suspense is killing me.
<Keybuk> infinity: I'm not going to tell you until you've slept ;)
<infinity> Keybuk: I'm not going to sleep until you tell me. :)
<Keybuk> besides, I need to double-confirm that it is this package
<Keybuk> oh, alright
<Keybuk> if you must known
<Keybuk> example-content
<infinity> I WIN!
<ogra> infinity, pfft, you said ttf-arphic-uming first
<giftnudel> hehe
<mdz> Keybuk: 17->19?
<Keybuk> mdz: yeah
<mdz> Keybuk: does it crash even if you upgrade only that package?
<Keybuk> mdz: that's what I'm trying now
<Keybuk> I'm making a root with only that package
<Keybuk> and making a root with all the others
<Keybuk> one should crash, the other should not
* infinity can now go to bed.
<Keybuk> I might, for kicks, also make a root with just that package unpacked and no other file s;)
<BenC> mdz: Did you try that new module yet?
<ogra> hmm, either someone cheats or seb128 is secretly testing edubuntu ... there are a bunch of seb128:PASS suddenly in my edubuntu table
<infinity> ogra: Nah, I said example-content when the problem FIRST came up.  Something about "maybe the compression algorithm is choking on the encoding of some file in example-content"
<infinity> ogra: I only hedged my bet on the font thing recently. :)
<Keybuk> infinity: that would be scary
<Keybuk> I wonder why kubuntu works
<infinity> Keybuk: But possible.
<ogra> yeah
<infinity> Keybuk: Block ordering and bad luck could make one work and the other choke.
<infinity> Keybuk: Compression is a very touchy science.
<ogra> infinity, ok, ok you win :)
<Keybuk> infinity: at least this is replicable
<mdz> BenC: not yet
<infinity> Keybuk: Now, what happens if you take the contents of example-content, toss it in a directory, and mksquash that?
<Keybuk> why doesn't mksquashfs have a --go-faster ?
<mdz> BenC: it was luck of the draw that it didn't hang hard that time, but I'll try it again
<Keybuk> infinity: I'm gonna do that in a minute
<infinity> Keybuk: I assume it's fine, and only breaks in the context of the larger filesystem?
<sivang> guys , will we still be open for bug fixes before final release?
<infinity> sivang: Some.  Not many.
<infinity> sivang: And only the most dire.
<sivang> infinity: okay, makes sense.
<Keybuk> sivang: how are you at squashfs?
<sivang> Keybuk: I've probably only used it while booting the live cd ;-) so no bugfixing/development experience.
<BenC> mdz: in your last dmesg, was squashfs module reloaded between these lines:
<BenC> [4294781.238000]  SQUASHFS: Filldir returned less than 0
<BenC> [4294790.122000]  squashfs: version 3.0prerelease (2006/1/24) Phillip Lougher
<BenC> IOW, right before the crash
<mdz> BenC: trying it with your new module now
<mdz> logging over the network
<mdz> we'll see what I get
* sivang reads the squashfs howto to get more familiar
<Keybuk> sivang: Section 1.  RUN AWAY SCREAMING
<sivang> Keybuk: heh
<msikma> So guys, how are the RCs going?
<sivang> hmm, wireless going down, bbl
<Keybuk> msikma: mdz has quit in tears
<mdz> har har
<mdke> they seem to be published on releases.u.c
<Keybuk> we're not going to release dapper now, and we're skipping straight to edgy
<msikma> Great to hear :)
<Keybuk> (how long until _that_ ends up on Slashdot?)
<sivang> Keybuk: hehe
<ogra> and we'll probably baxkport 2.6.16 and call it 2.6.15-23 to fix squashfs 
<ogra> :P
<fabbione> ogra: we already have -23
<BenC> 2.6.15.99-pre0-78.34
<ogra> -23.1 then :)
<Keybuk> ogra: that would rely somewhat on squashfs being in the kernel mainline
<kiko> -ubuntu666
<kiko> is what this voodoo is sounding like
<fabbione> hmmm rsync still hangs
<BenC> well, 2.6.17.git is building on all arch's, so we can just shove that in dapper real quick
<fabbione> BenC: GO GO GO GO
* BenC uploads now
<zul> hmm?
<Keybuk> why does mksquashfs go faster in the final 300MB than in the first?
<mdz> BenC: froze hard
<ogra> zul, btw we'll need grub2 alongside with 2.6.17.git indeed ;)
<BenC> mdz: any trace?
<zul> ogra: you are evil
<ogra> zul, only on thursdays
<mdz> BenC: http://people.ubuntu.com/~mdz/temp/squashfs-trace-2.gz
<zul> oh yeah it is thursday..
<mdz> BenC: that's all I was able to get; not sure how close to the end it goes
<BenC> Keybuk: first part is probably the all the metadata
<Keybuk> right
<Keybuk> so
<Keybuk> Door #1, #2 or #3 ?
<giftnudel_> 2
<Keybuk> 2 it is ... testing
<mdz> BenC: any joy in that trace?
<BenC> zcat: squashfs-trace-2.gz: unexpected end of file
<mdz> Keybuk: testing what?
<BenC> sure it's all there?
<Keybuk> #2 WORKED
<Keybuk> and that was 20060524.1 with everything except example-content upgraded
<Keybuk> so... next choice
<Keybuk> Door #1 or #3 ?
<zul> 1
<mdz> BenC: my pipeline got killed
<mdz> BenC: that is in fact all I have; can try again if it's no good
<BenC> is there a file/dir called "no" in there somewhere...that's the last thing it shows
<Keybuk> #1 also WORKED ... that was just example-content unpacked on its own
<Keybuk> so #3 is last
<BenC> nothing really sticks out in the trace though
<Keybuk> which is 20060524 with only example-content upgraded
<BenC> filldir() returning < 0 also seems irrelvant
<Keybuk> (you watch this one work too)
<Keybuk> oh thank the gods
<Keybuk> it CRASHED
<mdz> BenC: that's an xkb file
<mdz> Keybuk: !!!
<Keybuk> mdz: so, if all else fails, we just upgrade everything except example-content and ship it :)
<mdz> Keybuk: mark will shit himself
<BenC> crazy
<mdz> I need to step out for a moment
<mdz> back in a few
<BenC> see, and people said "example content never hurt anything"
<ogra> but why the heck does kubuntu work then ? 
<giftnudel_> can you change something in example-content so that it's different?
<Keybuk> ogra: it must be the block offset in the entire image it ends up at
<Keybuk> or something equally kooky
<_ion> What happened today in Lost probably causes the problem.
<ogra> strange strange
<Keybuk> _ion: what did happen today in Lost?
<Keybuk> did they try and release Island 2.0 and it broke?
<heno> eh, ok so I just stepped back in. Did my example-content stuff break the RC ? :-/
<Keybuk> heno: yes, mdz is calling in the hit squad now
<heno> ok, fair cop
<Keybuk> it seems that upgrading the amd64 desktop images to e-c 19 causes them to fail to boot
<Keybuk> due to a bug somewhere in squashfs
<Keybuk> (or, most likely, mksquashfs and insufficient changing in squashfs)
<Keybuk> but only the amd64 ubuntu image
<elmo> java build systems... unreliable out-of-tree filesystems...
<elmo> we have the best infrastructure EVAR
<Keybuk> kubuntu appears fine, and i386/powerpc are fune
<Keybuk> ...sysadmins who take down cdimage servers on release candidate day...
<heno> hm perhaps the super-compressed PNGs are causing the second layer of compression to get corrupted
<heno> perhaps it doesn't cope with really uncompressable stuff
<dholbach> the strange thing is that kubuntu/amd64 seems to be happy
<LaserJock> dholbach: you are here?
<Keybuk> dholbach: I suspect we'll be testing that one CLOSELY
<heno> not that strange if we've hit upon a rare squashfs bug
<Keybuk> heno: the strange thing is that we can replicate it every damned time
<infinity> Keybuk: Just to test one crackpot theory, can you take the chroot that breaks, rename those two files with spaces in them, and re-compress it?
<heno> any other random change might make it go away again
<dholbach> LaserJock: it seems so
<infinity> Keybuk: I'm assuming it's not that, but I'm curious.
<Keybuk> infinity: yes, I'm building some images with bits of the new e-c and stuff atm
<Keybuk> infinity: see which one of them breaks
<Keybuk> heno: I don't mind if it goes away
<ogra> infinity, what are you doing here ? 
<dholbach> infinity: maybe just rebuilding e-c fixes it
<LaserJock> dholbach: I have a really quick UVFe question, if you have a sec
<dholbach> LaserJock: which one is it?
<infinity> ogra: I'm sleeping, of course.  Can't you tell?
<mdz> infinity: bear in mind, it had a filename with a space in it before too
* dholbach hugs infinity, gives him his teddy bear and tells him a good night story
<infinity> mdz: Yeah, like I said, "crackpot theory".  Doesn't stop the curiosity.
<ogra> infinity, oh, youre dreaming us, right ?
<LaserJock> dholbach: it isn't one yet. that is my question. pybliographer could use a UVFe IMO, but it would need an new upstream python-bibtex.
<Keybuk> infinity: could you dream us up a patch
<ogra> yeah
<infinity> Keybuk: I've dreamed a lot of code in my life, unfortunately, I always forget the good bits when I wake up.
<dholbach> LaserJock: write all the stuff we need in a bug report and file it
<heno> but e-c-18 was before I compressed the book PNGs right?
<Keybuk> heno: e-c-17 is the "known good"
<LaserJock> dholbach: but you would consider a UVFe for something that is just needed for another UVFe?
<ogra> heno, with pngcrush ? 
<elmo> Keybuk: except we didn't, but otherwise good point :-P
<mdz> RC announcement is away
<dholbach> LaserJock: i can't say that without knowing what's going on
<heno> ogra: yes and some manual gimp-foo
<LaserJock> dholbach: fair enough, I'll write it up
<LaserJock> dholbach: and leave you alone for a bit ;-)
<Keybuk> if pngcrush broke it, there's going to be an archive accident, and it's going to be called releasecrush
<ogra> heno, hwdb and update-manager had that as well and didnt cause failures
<dholbach> LaserJock: ping slomo_ and siretart - if I'm away or something
<heno> ogra: no but intermittent failures do that sort of thing by nature
<ogra> LaserJock, and put some bucks in your pocket to pay a beer for dholbach in paris
<LaserJock> ogra: yikes, I spent all my beer money on getting an expadited passport
<ulaas> hi what happened to f-stop?
<ulaas> i cannot find it in the dapper repo
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Release preparation in progress: https://wiki.ubuntu.com/DapperReleaseRadar
<tseng> its f-spot
<tseng> and it's right -> there
<ulaas> i am on medication :)
<ulaas> ok how about a beagle frontend for gnome
<tseng> how about beagle-search
<Amaranth> uh
<tseng> can you please take these questions to #ubuntu in the future
<tseng> it is release crunch time
<Amaranth> ulaas: when you have beagle installed go to Places->Search
<ulaas> tseng: ok/
<tseng> thanks.
<ulaas> Amaranth: done
<mdz> BenC: what's the next step in tracking the kernel side of this?
<BenC> mdz: Me getting this iso so I can do some tests myself, adding in some printk's
<BenC> which should be in about 2 hours
<mdz> ok; I turn into a pumpkin in about that long
<mdz> so please update me via email
* mdke remembers mdz using the "pumpkin" line about this time 6 months ago
<Keybuk> mdz: to add insult to it all
<Keybuk> it's no particular file of example-content
<Keybuk> if you split the package in half, both halves work
<Keybuk> if you put both halves together, *boom*
<kiko> it must be RC week. we never have this sort of problem on regular weeks.
<fabbione> kiko: we didn't have LP for RC before.. that must be it
<Keybuk> mdz: if you take infinity's tarball, downgrade e-c to 17, then squash and mount -- does it work?
<mdz> BenC: I'm doing another trace to the console in vmware in hopes of getting a screenshot
<mdz> gah, it just gave me that hardware reset dialog
<mdz> trashes the console
* Keybuk heads for a bath
<mdz> kiko: we've built over 1000 of these and this is the first one known to have a problem
<Keybuk> mdz: another option may be to not "pngcrush" e-c, and see whether it goes away
<mdz> Keybuk: we also have a batch of new stuff coming into the archive which might ruffle its feathers enough to work again
<Keybuk> the "MAXIMUM ZLIB" may be breaking it
<mdz> Keybuk: if you care to upload a new example-content, now would be a good time
<Keybuk> mdz: we can hope, aye
<kiko> so something inside example-content is making squashfs blow up?
<mdz> kiko: yes
<Keybuk> mdz: I don't have a new example-c
<mdz> directly or indirectly, it's unclear
<kiko> new icons perhaps?
<Keybuk> ontent to upload
<Keybuk> kiko: it's not a direct file, sadly
<kiko> yeah, I picked that up
<Keybuk> or it's a specific file-appearing-at-a-specific-block problem
<kiko> Keybuk, can you reorder the files during generation?
<kiko> to see if it makes any difference?
<Keybuk> kiko: seems to, yes
<kiko> enough to bandaid the problem for tonight? matt will need to sleep at some point
<kiko> Keybuk, or do we really want to chase down the bug at this point?
<elmo> kiko: not that I'm volunteering to help, but the alternative to not chasing it down, is trying to release with a 'desktop CD' that might explode on any change
<kiko> elmo, yeah, I realize, but it could also be that this bug has always been in there. I guess that's wishful thinking though
<mdz> kiko: we've already released a known-good build for RC
<mdz> but we still need to solve this problem for final
<kiko> mdz, it is deterministic at least, right?
<mdz> kiko: not exactly
<mdz> it fairly reliably breaks, but in different ways
<mdz> it seems like it must be corrupting some state which later brings it down
<kiko> which means it'll be hard to debug, garr
<jordi> mdz, did my ubuntu-announce post go through at all this morning?
<BenC> wow, now that I'm 85% done with the download, it speeds up to 250k/s
<mdke> jordi: it didn't go through, afaics
<jordi> sigh
<BenC> mdz: I should have an image shortly...I'll begin working on it to see if I can narrow this down quickly
<mdke> jordi: you might need jdub/majo
<mdke> k*
<jordi> I'm trying
<KaiL> just grabbing for last critical bugs, found this one: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/41061
<Ubugtu> Malone bug 41061 in linux-source-2.6.15 "aic7xxx fails to load" [Major,Confirmed]  
<FliesLikeABrick> who is in charge of the torrents for the RC?
<ogra> mdz, hmm, you didnt use the announcement wikipage text ? 
<FliesLikeABrick> the ubuntu-6.06-rc-desktop-i386.iso.torrent  appears to be broken, the tracker rejects requests for it
<elmo> I've kicked the torrent server
<elmo> which is the best software evar.  beating out even oo.o's build system and unionfs
<thom> heh
<FliesLikeABrick> I was attempting to mirror the latest torrents on one of my 100mbit colocated machines (like I usually do around release time) but that one torrent was giving me a hard time, I'm gonna try it again
<elmo> yeah baby, WARTY'S torrent server.  feel the CUTTING EDGE.
<mdke> lol
<elmo> FliesLikeABrick: give it a couple of minutes to settle
<thom> dude, don't be dissing my 5am hack job
<thom> :-)
<FliesLikeABrick> elmo what do you mean?
<FliesLikeABrick> I get a specific rejected message from the tracker:  ERROR:
<FliesLikeABrick> rejected by tracker - Requested download is not authorized for use with this tracker.
<FliesLikeABrick> only for that one RC torrent
<elmo> FliesLikeABrick: there are a lot of files for the tracker and seeder to work through, it takes a couple of minutes for them to settle after I restart it
<FliesLikeABrick> alright elkbuntu 
<FliesLikeABrick> elmo *
<FliesLikeABrick> didn't know for sure if you were involved in the torrents or whether you were just speculating ;)
<elmo> I thought "I've kicked the torrent server" was pretty explicitly not speculation, but I'm slow that way
<ogra> elmo, dont say anything against warty, it still runs my old sony laptop fine :)
<elmo> ogra: dude, I don't want to know about you running distros that aren't security supported
<zyga> elmo: LOL :)
<FliesLikeABrick> elmo I thought so too, but it has been a long day and it slipped from my memory about 15 seconds after reading it ;)
<mdke> yeah, who cares about the torrents, as long as ogra's laptop has security updates
<ogra> elmo, pfft security ... 
<elmo> pfft accounts in the DC ...
<elmo> :-P
* ogra better shuts up now 
<sivang> heh
<dholbach> ogra: do the upgrade! to hoary! now! :)
<zyga> warty seems so long time ago :)
<zyga> even thought it's just a second away really :)
<zyga> have you guys ever thought about that?
<ogra> dholbach, i doubt that 500MHz/128Mb/3G machine would survive that
<spacey> warty is less old then winxp, and everyone still uses that :p
<ogra> i keep it for historical reasons :)
<zyga> ogra: bah, I run dapper on p2 199Mhz laptop :)
<heno> my father installed warty about two weeks ago, because he came across an old CD I had sent him. And he was very pleased :)
<KaiL> ogra, the disk should be the only problem ;)
<zyga> but I bought 2x128 :)
* dholbach should get some sleep
<ogra> KaiL, yep, especially on upgrades ...
<KaiL> Celeron 433, 128MB - currently on hoary, should get dapper after release.. my K6-2/500 was even faster with dapper
<dholbach> I read "128" and thought "Oh, Sb's there - finally..."
<zyga> :)
<zyga> 2x128 - double the seb power :D
<ogra> dholbach, someone added some PASS tags aside his name in the edubuntu table ...
<dholbach> was that me?
<ogra> so either someone is cheating or he did test today
<ogra> dholbach, dunno, didnt check, just noted it when i added my PASS :)
* dholbach only tested Ubuntu today
<dholbach> ogra: sfllaw is the Testing/Current master
<Keybuk> oh, well, that's good news
<Keybuk> mdz: so I got a little hacky userland squashfs reader going
<Keybuk> it works with everything but the broken image
<Keybuk> where it core dumps
<Keybuk> this is good
* KaiL can't find any bugs - I need more Hardware ;)
<dholbach> KaiL: fix bugs
<FliesLikeABrick> I've got some older boxes I'll be hooking up for bug testing 
<KaiL> I'm to stupid for coding
<FliesLikeABrick> a couple quad 200 boxes
<KaiL> oh, wait, there was one... good old Asus A7V133 seams to dislike the SMP code in -k7 kernel
<KaiL> at least with the -22 version
<heno> Keybuk: which image is broken?
<ogra> sigh ... still 1h to go for the DVD download
<ogra> heno, 20060625 amd64 desktop
<ogra> (ubuntu indeed)
<heno> oh, you mean CD image not picture
<ogra> yes
<ogra> unless there are .squashfs pictures nowadays :)
<zyga> bah, sun's download servers are down just today as I need them!
<ogra> zyga, download something else then ... ubuntu for example ;)
<sfllaw> dholbach: Thanks for testing!
* sfllaw hugs dholbach.
<FliesLikeABrick> I'm gonna spend the night trying to organize my torrents and seed most or all of the RC images, I've got 1000 TB of bandwidth to burn in the next couple days
<FliesLikeABrick> er
<FliesLikeABrick> GB
<zyga> ogra: I want java card technical spec, for 2.2.0
<sfllaw> FliesLikeABrick: That would be good.
<thom> you have a petabyte of bandwidth? score.
<ogra> zyga, well, we *have* sun java in dapper :)
<dholbach> de rien, sfllaw
<FliesLikeABrick> sfllaw it is what I tend to do towards the end of every month and during every release of a flight or stable release
<sfllaw> fabbione: Have you had a chance to run the Release Candidate images against your Niagara box?
<FliesLikeABrick> once some thing in my life calm down, I'm going to set  up a box for an official mirror
<crimsun> zyga: it's up for me. Do you need 2.2.0 specifically, or can your app be forward-ported to 2.2.1?
<BenC> mdz: Done downloading, I'll start checking into it now
<tseng> FliesLikeABrick: located where?
<zyga> crimsun: I just want the spec and enought info to code a vm emulator
<zyga> s/enought/enough/
<FliesLikeABrick> tseng 100mbit in the XO Communications datacenter in Chicago
<zyga> crimsun: I digg virtual machnies :)
<tseng> FliesLikeABrick: cool, i am in DE
<zyga> crimsun: if you have the spec I'd love to ask you for a copy :)
<FliesLikeABrick> the most I can do now is seed torrents at different parts throughout the month, I can't do anything permanent just yet
<zyga> crimsun: the download server is working for you?
<crimsun> zyga: 403 atm
<heno> Keybuk: I've put the original book images up here http://people.ubuntu.com/~henrik/examplecontent/book/original/
<zyga> same here
<heno> It might be interesting to roll an image with those
<heno> and then pngcrush them and try again
<heno> to see if that triggers it
<Keybuk> heno: at this point, I suspect it would be time better spent debugging squashfs
<FliesLikeABrick> because of the fact that I can't do anything permanent [as in mirroring]  just yet, is there anything I can do to help at the time of the actual dapper release, aside from seeding torrents?
<heno> Keybuk: true
<mdke> heno: did you use the latest version of pngcrush? It got a UVF a couple of days ago
<mdke> the old one was apparently quite broken, no idea if it could be related to your problem
<Keybuk> can somebody explain to me why kernel people do
<Keybuk> #define macro(...) do { ... } while (0)
<ogra> mdke, the versions before didnt run on dapper
<Keybuk> rather than just #define macro(...) ...
<Keybuk> BenC: do you know?
<mdke> ogra: ah, "quite broken" then :D
<zyga> Keybuk: to support if macro() else ..
<ogra> mdke, it segfaulted before doing anything
<mdke> right
<zyga> Keybuk: basically the only way to make macro behave like a block of code
<zyga> Keybuk: (when the macro is more than one statement)
<heno> mdke: v1.6.2-1
<Keybuk> zyga: I don't see why that wouldn't work anyway
<Keybuk> they do this when it _is_ only one statement
<Keybuk> which is what confuses me
<FliesLikeABrick> elmo may I PM you for a minute or two?
<heno> instaled a few days ago
<Keybuk> there's a patch here which explicitly adds the do/while around a single printf()
<zyga> Keybuk: hmm, then I don't know - consistency maybe?
<mdke> heno: ok, looks like the latest one
<Keybuk> BenC: for you to narrow your search -- if you mksquashfs -no-duplicates ... it works
<Keybuk> and the core dump I made was in duplicate processing
<Keybuk> ogra: heh, the reason the directory counts are all off is because squashfs is missing . and ..
<ogra> oh
<crimsun> Keybuk: probably for uniformity, but yeah, for just one statement it seems daft
<jcole> one of my dapper systems keep crashing on certain random screensavers, how do i disable the problem ones in dapper? with breezy, i could do that... looks like xscreesaver in breezy, gnome-screensaver in dapper... should users just install xscreensaver as workaround?
<ogra> sudo apt-get remove xscreensaver-gl
<Keybuk> BenC: your problem will be the lack of bounds checking
<Keybuk> BenC: most likely in the checksum checking code
<Keybuk> BenC: it just eats bytes, way past the end of the loop device
<dieman> heh, wow
<dieman> new release has the mirror humming already
<FliesLikeABrick> I expect my seed of the alternate-i386 to be uploading quite a bit once it is done
<dieman> | ubuntu-6.06-rc-alternate-i386.iso             688.6 MB   0    B/s   1.6 MB/s |
<FliesLikeABrick> dieman who manages the mirrors?
<dieman> depends on which mirror
<dieman> <-- mirror.cs.umn.edu
<FliesLikeABrick> I mean the overall list and such
<dieman> thats more via the wiki
<dieman> and then they pick out which hosts
<FliesLikeABrick> ah
<dieman> so whomever writes the release information,e tc.
<dieman> i thik
<dieman> think
<FliesLikeABrick> I hope to be running a mirror in the near future, all I can do for now is lots of torrent seeding
<FliesLikeABrick> I'm trying to get my school's ACM chapter to start a ubuntu mirror (rpi.edu), I'll probably donate some hardware to the cause
<dieman> yah
<dieman> you should try mirror.cs
<dieman> it should be obscenely fast for you
<FliesLikeABrick> I don't live on campus ;)
<dieman> ahh
<dieman> another argument to live in the dorms :)
<FliesLikeABrick> I've got a couple extra 1U servers that I've retired that I'm going to hand to the ACM
<FliesLikeABrick> I work at RPI's computing helpdesk, so I can do my updates when I'm on shift there.  we've got a couple 100mbit hubs there that go right downstairs to our datacenter
<dieman> yah
<FliesLikeABrick> (about 15 feet away)
<Burgwork> FliesLikeABrick, dieman can you guys move to another channel and keep the chatter down in this one?
<jcole> ogra: some of the non-gl ones crash the system too.. i think it has to do with 16-bit color
<FliesLikeABrick> yes Burgwork will do
<Burgwork> FliesLikeABrick, thanks
<jcole> ogra: all the opengl ones actually work fine, lol
<FliesLikeABrick> jcole if you're looking for help with using dapper, #ubuntu+1 is the right place for you
<ogra> jcole, sudo apt-get remove xscreensaver-data ;)
<ogra> and keep -gl
<sivang> Keybuk: okay, howto is a bit too userish in nature, but where can I help with squashfs ?
<FliesLikeABrick> elmo the torrent for alternate-i386 is still grumpy
<Keybuk> sivang: heh, is ok :)
<Keybuk> this is clearly a deep bug :(
<Keybuk> mdz: 3.0 doesn't fix it
<mdz> Keybuk: I'm unsure as to whether that's a good thing
<mdz> BenC: any luck?
<FliesLikeABrick> er elmo I meant desktop-i386
<ogra> mdz, was it intentional that you dropped the edubuntu ltsp upgrade link i added to the wiki from the real announcement ?
<Keybuk> mdz: if you don't mind adding ~30MB to the current images, I can "cure" it with keeping example-content :)
<Keybuk> (assuming it doesn't go away by itself)
<mdz> ogra: I don't recall doing that
<ogra> ok
<mdz> Keybuk: keeping how?
<ogra> was just wondering ...
<Keybuk> mdz: mksquashfs -no-duplicates
<mdz> ogra: perhaps you added it after I copied the announcement to email
<mdz> Keybuk: mumblemumble
<Keybuk> mdz: that's where the bug is
<ogra> mdz, i added it after Riddell added his stuff
<Keybuk> I've been able to narrow it down that much so far
<ogra> shortly after you poked me to look at it
<ogra> anyway, its not in, nobody injured, all fine, i just wanted to know if i did something wrong or my grammar was to bad :)
<sivang> Keybuk: could you just toss me the malone report # for refrence and reading what solution invovled once you guys fix it? :) (couldn't find it on the radar)
<Keybuk> sivang: there is no malone report
<Keybuk> mdz: the interesting thing I've noted about this image is that the number of duplicates happens to be a power of 2
<Keybuk> (8192)
<Seveas> the real freaky thing about that is that Keybuk realized it's a power of 2 without thinking ;)
<Keybuk> Seveas: anyone who spends much time around computers and can't to base 2 in their head is more freaky :)
<Seveas> hehe
<Keybuk> the even more interesting thing is that it allocates the table in 32,768 chunks
<Keybuk> and that the size of the structure is 4 bytes
<Keybuk> which co-incidentally means that 8192 entries would fall exactly on this boundary
<ptlo> pygi: ping
<pygi> ptlo, pong
<ptlo> pygi: please drop by on #ubuntu-hr, thanks
<dholbach> good night fellas
<pygi> night dholbach 
<kiko> <jdahlin> supported_versions: WARNING: Unknown Ubuntu release: 6.06LTS
<kiko> <jdahlin> while running apt-get upgrade
<kiko> weird.
<dholbach> he should use the upgrsade tool
<dholbach> upgrade
<zyga> what is LTS? long term support?
<Keybuk> zyga: Late to Ship
<Keybuk> (yes, long term support)
<BenC> mdz,Keybuk: what's the find command that triggers the oops
<Keybuk> BenC: find / -type f -print0 | xargs -0 cat
<BenC> boom
<Keybuk> BenC: I still think bytes is getting -1 stuffed into it somehow
<Keybuk> happily, the author doesn't appear to mind us using 2.2r2
<sivang> Keybuk: this bug is an kernel oops when using the live cd basically?
<Keybuk> sivang: yup
<Keybuk> damn, I wish I hadn't eaten that chocolate earlier
<Keybuk> could really do with the brainsugar now
* ogra hands Keybuk a huge bowl with warm chocolat pidding
<ogra> *pudding too
<Keybuk> BenC: I can't see anything suspicious in the inode table or the fragment table
<Keybuk> all the numbers are "sane"
<BenC> I think I see a fix in the latest source that would possibly be related to this
<Keybuk> BenC: latest (3.0) still breaks
<BenC> this is in the kernel driver
<Keybuk> oh right, what's the kernel drive do?
<Keybuk> this looks very much like mksquashfs has produced a busted filesystem
<Keybuk> all the kernel driver can do is guard against that and reject it rather than panic, no?
<BenC> -               unsigned int fragment;
<BenC> +               long long fragment;
<Keybuk> BenC: that's just the 3.0 change
<Keybuk> he added support for >2GB files
<BenC> I'm going to atleast try the latest driver and see if it does anything...you did try recreating the filesystem with the latest 3.0 final mksquashfs?
<Keybuk> BenC: yes
<Keybuk> 3.0 final unsquashfs cannot read it
<BenC> crazy, then that does sound like userspace
<Keybuk> and I made a 2.2r2 unsquashfs myself, which cannot read the 2.2r2-produced one either
<infinity> Keybuk: You're still tooling away at this?
<Keybuk> infinity: yes
<BenC> where is unsquashfs 2.2?
<Keybuk> BenC: hang on, will paste it
<BenC> unsquashing is a quicker way to find this than crashing my kernel over and over
<Keybuk> hmm, why can I not copy/paste into vnc?
<Keybuk> *sulk*
<Keybuk> mksquashfs: write_fragment_table: fragment 6077, start_block 21d8e1d3, size 16814844
<Keybuk> that's an _awfully_ large fragment
<Keybuk> given they're limited to 32768 :)
* sivang hits the sack after trying to understand where to patch to fix malone #39482. dnd is a bit more involved :-)
<Ubugtu> Malone bug 39482 in nautilus "nautilus tries to move when dragging and dropping from read-only folders, instead of copying" [Normal,Confirmed]  http://launchpad.net/bugs/39482
<Keybuk> BenC: http://people.ubuntu.com/~scott/unsquashfs.c
<Keybuk> build it in the squashfs-tools dir by just stealing the mksquashfs link line
<BenC> Keybuk: thanks
<HiddenWolf> sivang: there have been a couple of fixes regarding DnD upstream, there are also bugs when copying to/from the burn:// uri and others.
<Keybuk> hmm
<Keybuk> though I still think that fragment size is suspicious ... they exist in the working version too
<BenC> you got sigsegv from unsquashfs, right?
<Keybuk> right
<Keybuk> mksquashfs: Writing fragment 3456, uncompressed size 63833, compressed size 63833
<Keybuk> mksquashfs: write_fragment_table: fragment 3456, start_block 1498e6f2, size 16841049
<Keybuk> ^ what's wrong with this picture? :)
<zul> un the size?
<Keybuk> the size jumped a few bytes
<BenC> compressed and uncompressed are the same
<Keybuk> BenC: yeah
<Keybuk> note the size in the second line too
<BenC> yeah, odd
<Keybuk> that's got 1 << 24 |d into it ... which appears to be SQUASHFS_COMPRESSED_BIT_BLOCK
<Keybuk> while all these things are a bit odd, without knowing the format properly
<Keybuk> there's nothing that yet stands out that's not also present in the same log for the working one
<Keybuk> there's more blocks of 1 << 24 | 65536
<infinity> Riddell: Not still around, are you?
<ogra> morning infinity 
<infinity> ogra: Or evening..
<ogra> ohoel, right :)
<ogra> heh
<^ohoel> ogra: you're a good reminder I should checkin to see if any of my pet issues/features are discussed though :)
<Keybuk> BenC: apparently my hunch is right
<Keybuk> those should not be >65535
<BenC> Keybuk: I've almost isolated exactly where it is crashing...down to 3 lines of code
<Keybuk> oh, I see what's happening here
<Keybuk> it's not handling gzip returning a larger piece of data properly
<Keybuk> I can see what he's _trying_ to do
<Keybuk> (not compress it)
<BenC> that would explain the zlib_fs errors in the kernel traces
<BenC> and yes, the crash is occuring on blocks marked uncompressed, I can confirm that
<BenC> fragments I mean
<Keybuk> yeah, they're marked uncompressed, but still have the COMPRESSED flag in the size, so are about 16MB too big :p
<BenC> wow, that would explain a lot :)
<BenC> so the size field has flags encoded into it?
<Keybuk> look at mangle() in mksquashfs.c
<Keybuk> it appears to have, yes
<Keybuk> if (uncompressed || c_byte >= size)
<Keybuk> what it does here is odd
<Keybuk> it undoes compress2 by memcpy()ing back over the uncompressed data
<Keybuk> then returns the uncompressed size or'd with 1<<24
<Keybuk> I think he really means to REMOVE that flag ;)
<Keybuk> if I change | to &~ ...
<BenC> so: size = size & ~(SQUASHFS_COMPRESSED_BIT_BLOCK | SQUASHFS_COMPRESSED_BIT);
<Keybuk> oh, no
<Keybuk> "bit is set if block is uncompressed"
<BenC> that's counterintuitive
<Keybuk> yeah, it's kooky
<Keybuk> you have the fragment reading code there
<Keybuk> what's the matching equivalent ... does it ever try and check for or remove 1<<15 or 1<<24 from the fragment size?
<Keybuk> how does it know that the fragment is compressed or uncompressed?
<Keybuk> (in the kernel)
<BenC> the kernel driver doesn't use it very intuitively either
<BenC> it or's SQUASHFS_COMPRESSED_BIT_BLOCK with a few values like...
<BenC> sizeof(struct squashfs_super_block) | SQUASHFS_COMPRESSED_BIT_BLOCK
<BenC> passing that value to some other function
<BenC> it doesn't ever seem to reference it in the code for actual data
<BenC> wait, I forgot to check the headers...lots of macros in this code
<BenC> yeah, if the flag is not there SQUASHFS_COMPRESSED() is true
<BenC> so no flag == compressed
* Keybuk wonders what he means by the fragments not being written correctly then
<BenC> I think that was our misunderstanding of the flag :)
<BenC> I wonder if it's possible for a valid compressed block/fragment to have a size that has that bit set
<Keybuk> no, I don't think it's supposed to be
<Keybuk> the max is 64K or so
<BenC> it's crashing in duplicate() in unsquashfs
<BenC> on an uncompressed fragment
<Keybuk> hmm
<Keybuk> get_checksum is called with l==0 where it crashes for me
<Keybuk> or is that gdb just being unhelpful
<Keybuk> I suspect the latter, actually
<Keybuk> hmm
<Keybuk> frg->index is WAYYYY to high
<Keybuk> oh, that's odd
<Keybuk> $7 = {inode_type = 2, mode = 493, uid = 0, guid = 255, mtime = 1145660290,
<Keybuk>   start_block = 63, fragment = 4294967295, offset = 0, file_size = 791104,
<Keybuk>   block_list = 0x7ffffffa37d8}
<Keybuk> perfectly
<Keybuk> plausible, until the fragment
<kagou> great work men on RC :) first installation OK on my pc with desktop version, and now go for installation on notebook :)
<Keybuk> or is that -1 ?
<BenC> ah, yes, I get the same thing
<BenC>         unsigned short fragment_checksum = get_checksum(read_from_buffer, &handle, frag_bytes);
<BenC> from that call
<BenC> in duplicate()
<Keybuk> hmm
<Keybuk> where it cores, is it fragment 7168 ?
<Keybuk> (go up to add_file)
<BenC> if l=0, how does it even get in the loop
<HrdwrBoB> laps do not fly
<HrdwrBoB> just so you know
<Keybuk> BenC: gdb is being annoying and showing you the value on the stack, which was decremented within the function
<Keybuk> (gdb) p fragment_table[7150] 
<Keybuk> $33 = {start_block = 592072330, size = 9773}
<Keybuk> (gdb) p fragment_table[7160] 
<Keybuk> $34 = {start_block = 592237509, size = 8786}
<Keybuk> (gdb) p fragment_table[7165] 
<Keybuk> $39 = {start_block = 592281075, size = 8523}
<Keybuk> (gdb) p fragment_table[7166] 
<Keybuk> $40 = {start_block = 592289598, size = 8523}
<Keybuk> (gdb) p fragment_table[7167] 
<Keybuk> $41 = {start_block = 592298121, size = 8305}
<Keybuk> (gdb) p fragment_table[7168] 
<Keybuk> $42 = {start_block = 252536, size = 16777216}
<Keybuk> (gdb) p fragment_table[7169] 
<Keybuk> $43 = {start_block = 2842967835, size = 436639668}
<Keybuk> (gdb) p fragment_table[7170] 
<Keybuk> $35 = {start_block = 1396757455, size = 2895456946}
<Keybuk> ...
<Keybuk> hello table corruption
<BenC> but that's the size with an "uncompressed flag"
<BenC> right?
<Keybuk> no, that's just buggered
<BenC> uncompressed fragment, which is 1<<15
<Keybuk> the start_block goes a bit silly
<BenC> oh, yeah, I see that
<Keybuk> it doesn't match what mksquashfs says it wrote
<Keybuk> should be size=8548
<wasabi__> Any awareness of some sort of guide about the steps that debootstrap goes through?
<BenC> mine is way worse than yours
<wasabi__> I'm needing to do them manually.
<wasabi__> crossarch even
<FliesLikeALap> [laps do not fly]  thanks for that tidbit HrdwrBoB, wasn't aware of that ;)
<Keybuk> BenC: so, fragments are split amongst fragment indexes, which each hold 1024 fragments, right
<Keybuk> 7168 happens to be the start of the 8th fragment
<Keybuk> this image happens to have 8192 fragments
<Keybuk> HELLO!
<BenC> sounds like you are going somewhere with this :)
<rpedro> of course, if I do 'umount -f <samba_mountpoint>' the problem goes away, but still is it possible to fix it in dapper?
<Keybuk> BenC: the road to hell is paved with hardcoded array sizes
<Keybuk> or, worse, hardcoded structure sizes
<Keybuk> BenC: I have no idea, I'm just following a core dump to it's frightening conclusion
<rpedro> hi, you didn't see my last 5 messages?
<rpedro> I think I got disconnected...
<Keybuk> BenC: why is SQUASHFS_METADATA_SIZE also 8192
<BenC> Keybuk: have you tried mksquashfs -no-fragments ?
<BenC> I wonder if that makes things worse
<BenC> worse size wise that is
<Keybuk> BenC: I tried -no-dups and the problem went away
<Keybuk> but I think that just adjusted the number of fragments
<BenC> that would make sense, since this occurs in duplicate()
<BenC> -no-fragments probably fixes it too
<Keybuk> yeah
<Keybuk> wow this is a complicated bit of math
<BenC> #2  0x00000000004070d9 in add_file (start=592596341, file_bytes=0, block_listp=0x7fff077030d0,
<BenC>     blocks=0, fragment=7168, offset=0, bytes=37730) at unsquashfs.c:1038
<Keybuk> (((8192 * sizeof (struct squashfs_fragment_entry)) + 8192 - 1) / 8192) * sizeof (unsigned int)
<BenC> ok, now that I'm on amd64 instead of ppc, I am getting the same backtrace as you :)
<Keybuk> that struct is 8 in size, int is 4
<BenC> which == 32
<BenC> not sure why that whole bit is there
<Keybuk> really?  it doesn't divide evenly for me
<BenC> passing it into C produces 32
<Keybuk> you end up with "multiple of 8192 minus 1 divided by 8192"
<BenC> (gdb) p fragment_table[7165] 
<BenC> $1 = {start_block = 3359632458, size = 112323933}
<BenC> (gdb) p fragment_table[7160] 
<BenC> $2 = {start_block = 3617790435, size = 317460625}
<BenC> (gdb) p fragment_table[7000] 
<BenC> $3 = {start_block = 213051399, size = 668592203}
<BenC> (gdb) p fragment_table[1] 
<BenC> $4 = {start_block = 2197881567, size = 856138937}
<BenC> (gdb) p fragment_table[0] 
<BenC> $5 = {start_block = 2122878085, size = 663237347}
<BenC> int main() { printf("%d\n", (((8192 * 8) + 8192 -1) / 8192) * 4); }
<BenC> just did that
<Keybuk> I think the bug is that the file format is busted if you have any multiple of 8192 fragments
<Keybuk> BenC: right, do it in Python
<Keybuk> >>> ((float)((8192 * 8) + 8192 - 1) / 8192) * 4
<Keybuk> 35.99951171875
<Keybuk> it's supposed to be 36 I think ;)
<BenC> where is that anyway?
<Keybuk> where's which?
<Keybuk> oh, that
<Keybuk> read_fragment_table in read_fs.c
<Keybuk> the kernel has the same macros
<Keybuk> hmm, no, maybe it is supposed to be 32
<Keybuk> yeah, 32 = indexes of 8 tables of 1024 8-byte structs each
<BenC> #define SQUASHFS_FRAGMENT_BYTES(A)      (A * sizeof(struct squashfs_fragment_entry))
<BenC> #define SQUASHFS_FRAGMENT_INDEX(A)      (SQUASHFS_FRAGMENT_BYTES(A) / \
<BenC>                                         SQUASHFS_METADATA_SIZE)
<BenC> so does this make it rollover to a second table?
<BenC> e.g. 0-8191 is in one table, 8192... is in a second, ...
<BenC> aha
<Keybuk> 0-1023 in one, 1024-etc.
<Keybuk> 7168 is the 0th of the 8th table
<Keybuk> and it looks like the entire 8th table is corrupted
<BenC> nm, yeah
<Keybuk> so that's kinda interesting
<Keybuk> the last table wasn't right
<Keybuk> it was "uncompressed and zero bytes" according to the header
<BenC> at block 0, size 0, according to the kernel oops
<Keybuk> so, I think I'm content *why* this crashes when we try and read the filesystem now
<Keybuk> the fragment table is divided into chunks of 1024 entries each
<Keybuk> with the location of each of these chunks (sequential, really, but just in case, I guess) in the headers
<BenC> I wonder if we can increase the size of the metadata
<Keybuk> each chunk is preceeded by a 2-byte size, which also indicates whether or not it is compressed
<Keybuk> on tables 0 thru 6, the chunk of the table is uncompressed and the size is valid
<Keybuk> uh, compressed
<Keybuk> sorry
<Keybuk> on table 7, the size is 32768, which we know to mean uncompressed and size of 0
<Keybuk> which is clearly wrong
<Keybuk> so the kernel reads no bytes for table 7 (fragments 7168..8191)
<BenC> yeah, I'm guessing that the "uncompressed" bit is not really being set, just that the size is corrupt
<Keybuk> thus there's junk in the fragment index
<BenC> 32768 happens to be FRAG_ZIE
<Keybuk> so whenever you try and read anything in the last 8th of the disk, it explodes
<BenC> FRAG_SIZE
<Keybuk> right, I'
<Keybuk> I'm wondering whether the final table failed to compress :)
<Keybuk> so I think we'
<Keybuk> re done looking at uncompress, and now need to look at squash
<BenC> maybe that's why you see the last part of mksquashfs fly by :)
<BenC> I don't have a way to do any testing with mksquashfs...no valid data to compress as a test case
<Keybuk> I have no idea what kind of data is valid
<Keybuk> at the moment I have to theories
<Keybuk> 1) mksquashfs is unable to correctly write any image with multiples of 8192 fragments
<Keybuk> or
<Keybuk> 2) squashfs in general is unable to deal with a fragment table not being compressable
<Keybuk> aha
<Keybuk> and gdb has just reached my break point in write_fragment_table
<Keybuk> remind me, can I dump core here so I can resume at any point/
<Keybuk> yes, I can
<Keybuk> it's "gcore"
<Keybuk> right
<Keybuk> I'll just go for more tea I think
<Riddell> infinity: morning
<Keybuk> right, I have reinforcements
<Keybuk> man this does some strange things
<Keybuk> it just copied, one by one, an array into another identical array
<bddebian> Howdy
<Keybuk> int avail_bytes = i == meta_blocks - 1 ? frag_bytes % SQUASHFS_METADATA_SIZE : SQUASHFS_METADATA_SIZE;
<Keybuk> ...
<Keybuk> right
<bddebian> Heya Keybuk
<Keybuk> so the bytes available to the table is 8192, unless you're the last entry
<Keybuk> ?!
<Keybuk> what's that all about
<Keybuk> in fact, frag_bytes is a multiple of metadata_size
<Keybuk> so you have ZERO BYTES AVAILABLE TO YOU
<Keybuk>    _   _  _   _   _
<Keybuk>   /_\ | || | /_\ | |
<Keybuk>  / _ \| __ |/ _ \|_|
<Keybuk> /_/ \_\_||_/_/ \_(_)
* bddebian is frightened
<Keybuk> which means whatever compress2 returns is automatically bigger than 0 (8 bytes)
<Keybuk> which means it sticks the UNCOMPRESSED tag on the front
<Keybuk> and ors it with zero bytes
<lifeless> isn't that a little redundant ?
<Keybuk> lifeless: it leaves the files in the latter 8th of the disk somewhat redundant, yes
<Keybuk> because the fragment table that tells you where they all are is AWOL
<bddebian> Hi lifeless
<lifeless> hiya
* Keybuk waits for mksquashfs to get back to that line of code
<Keybuk> then I shall do evil things with it in gdb
<Keybuk> this explains why it's "cat" that triggers it, and not just plain find
<lifeless> gotta read the content
<lifeless> hnn put a dir in the last 8th and find would balk too I presume
<ajmitch> like /var was earlier
<Keybuk> lifeless: no, dirs are stored differently in the filesystem
<lifeless> ah. 
<Keybuk> ajmitch: we're still on that bug ;)
<ajmitch> wonderful :)
<Keybuk> lifeless: dirs are stored as inodes with a list of children inodes, etc.
<Keybuk> there's no "content"
<lifeless> Keybuk: the child list is internal then 
<Keybuk> files are stored as lists of references to shared compressed fragments of files
<Keybuk> and it's that fragment table that's buggered
<lifeless> righto, I see
<Keybuk> aha, at the break point
<Keybuk> now let's wind it forwards to the last entry
<Keybuk> ok
<Keybuk> (gdb) p avail_bytes
<Keybuk> $1 = 0
<Keybuk> we change that to 8192
<Keybuk> cont, and program exited normally
<Keybuk> right, so we have a filesystem image
<Keybuk> now can unsquashfs read it?
<Keybuk> Read existing filesystem, 81918 inodes scanned
<Keybuk> \o/
<Keybuk> let's just gdb it and sanity check the fragment table
<Keybuk> (gdb) p (*fragment_table)[7168] 
<Keybuk> $10 = {start_block = 592306426, size = 8548}
<Keybuk> that's BETTER
<Keybuk> I guess it's now time for the ultimate test
<Keybuk> can the kernel mount it?
<Keybuk> it mounts ... can the kernel read it?
<Keybuk> IT CAN!
<Keybuk> BenC: ok, so the kernel bug here is that when loading the fragment tables, the kernel doesn't check that it loads everything -- the last fragment table index had a zero size, which meant it had a whole series of unpopulated structures
<Keybuk> it should have bailed and said "read 0 bytes, wanted 8192"
<Keybuk> and refused to mount the image
<Lathiat> I have a question - does the LTS allow you to upgrade an existing breezy system?
<Lathiat> err
<Lathiat> s/LTS/desktop cd
<Keybuk> ok, now to ponder the mksquashfs fix
<Keybuk> Lathiat: no, the alternate does though
<BenC> Keybuk: excellent
<Lathiat> Keybuk: righto
<Keybuk> BenC: so it's that ?: that's busted
<Keybuk> I think I can see what it's trying to do
<Lathiat> Something to keep in mind i guess, especially as its called 'alternate'
<Keybuk> int avail_bytes = i == meta_blocks - 1 ? frag_bytes % SQUASHFS_METADATA_SIZE : SQUASHFS_METADATA_SIZE;
<Keybuk> it's trying to say "we have METADATA_SIZE bytes, unless we're the last one, in which case we have maybe less"
<Keybuk> except it doesn't account for having an exact multiple of METADATA_SIZE
<Keybuk> needs a silly +1-1 hack
<bddebian> Break out the hex editor ;-P
<fabbione> sfllaw: i do regullarly install on Niagara.
<Keybuk> fabbione: good morning
<fabbione> morning
<Traveler1> hi
<bddebian> Hello Traveler1
<Traveler1> i'm using espresso from the RC, it does not have REISER as partition fs option
<Traveler1> i'm using espresso from the RC, it does not have REISER as partition fs option
<zul> ok quick question for bug #45976 if we get the patches that fix the CVE that should be enough shouldnt it?
<Ubugtu> Malone bug 45976 in phpmyadmin "Security fixes in phpmyadmin 2.8.1" [Normal,Unconfirmed]  http://launchpad.net/bugs/45976
<fabbione> zul: you only want the patch that fixes that specific CVE
<ajmitch> sigh, yet more holes in phpmyadmin?
<bddebian> heh
<zul> fabbione: yeah thats what i was going to do
<Keybuk> infinity: are you around?
<zul> fabbione, there are two though so ill get 2 patches...tomorrow at least im off to bed later
<fabbione> zul: and coordinate with pitti 
<zul> ok
<bddebian> Later zul
<zul> later
<Keybuk> BenC: oh, wow
<Keybuk> there's a bug
<Keybuk> #32481
<poningru> mako: :( your blog requires cookies
<poningru> I just lost a very large posting...
<poningru> s/posting/comment
<Keybuk> right, all uploaded, etc.
<Keybuk> bed time for me
<Burgundavia> Lathiat, you see that Howl shut down development?
<sfllaw> I am totally prepared for release.
<sfllaw> I have a big carton of blank CDs.
<Burgundavia> sfllaw, lol
<sfllaw> No, no.  It's true.
<sfllaw> Now I just have to find someone with a burner.
<mako> poningru: right, that's the captcha
<mako> poningru: sorry about that :-( but the amount of spam i was getting was overwhelming
<poningru> mako: do what lessig etc. do
<mako> poningru: what does lessig, etc. do?
<poningru> the human turing test
<mako> poningru: that doesn't mean anything to me
<poningru> I'm trying to fight the comment spam bots. Type "human" here:
<poningru> and he gives a small box to write human
<poningru> ofcourse you can do things like
<poningru> dont put anything here:
<mako> poningru: i just went to lessig's blog
<mako> poningru: and clicked on the first link
<mako> poningru: and it was full of spammed comments
<poningru> :)
<poningru> hehe I just realized..
<mako> so, um, the one i have works
<poningru> but...
<mako> i actually invented a new type of catpcha
<mako> it's text-based.. pretty cool and uses commonsense knowledge.. but i wrote it as a mediawiki plugin
<sfllaw> mako: How does it work?
<poningru> code?
<poningru> err link?
<mako> sfllaw: i can send you the paper if you want
<mako> i'm waiting to see if the paper got accepted into an AI conference
<sfllaw> mako: I know that people have been considering challenge-response type catpchas.
<mako> this isn't like that
<mako> it's based around commonsense knowledge
<sfllaw> Does it prevent the pr0n-site attack?
<mako> no
<sfllaw> Sad.
<mako> but i've never actually seen evidence of that actually used
<mako> and neither has the guy who invented the original captcha
<sfllaw> Uhm...
<sfllaw> Neither
<sfllaw> have
<sfllaw> I.
<sfllaw> Yeah.
<mako> i mean, it would concievably work
<sfllaw> ;)
<mako> but there's no evidence its ever actually been done :)
<sfllaw> I should totally do that.
<poningru> the pr0n-site attack?
<sfllaw> But where would I find the porn?
<mako> captchas have been broken
<mako> but not that way
<sfllaw> With handwriting recognition.
<sfllaw> I've seen that.
<mako> well, using a number of techniques to improve the computer vision technology
<mako> apparently, the original captchas used on yahoo and stuff are considered broken by the creators
<mako> mine seems to be more robust
<sfllaw> Yay.
<mako> but it's susceptable to poisoning
<mako> which can be recovered
<mako> but only if you can notice some decent percentage of successful attacks
<mako> so it would work for blogs and wikis where you can revert or mark comments as spam and remove them
<mako> because you can undo a whole lot of poisoning with a single revert
<mako> so it should raise the bar high enough
<mako> but i haven't done a very large scale attack on my system yet so i don't know well it would work
<mako> but yes
<mako> poningru: sorry about the normal captcha
<mako> poningru: but if i replace it, it will be with a better more accessible captcha
<poningru> ok that would be better
<sfllaw> That would be good.
<sfllaw> Especially since shipping captcha-breaking tools for accessibility would only be funny for a short while.
<sfllaw> poningru: The pr0n-site attack is theoretically simple.
<sfllaw> 1. Set up a porn site.
<sfllaw> 2. Advertise.
<sfllaw> 3. Have desperate people want to log in.
<sfllaw> 4. In order to access the porn, they have to answer a captcha.
<poningru> ah ic
<bddebian> heh
<sfllaw> 5. Cull the captchas from the things you want to spam.
<sfllaw> It's like Mechanical Turk.  But for a smaller problem domain.
<poningru> true true
<sfllaw> And from people with more motivation!
<poningru> but you know a lot of people have gotten good results off of the human turing test type...
* jsgotangco just learned from sfllaw the basics of setting up a pr0n biz online
<poningru> I think it was on planet free desktop that a lot of people were talking about it a while ago
<sfllaw> jsgotangco: I'm really helpful.
* poningru rings up sfllaw's sale, jsgotangco please pass $500.00 to sfllaw and a 2% commision to moi
<jsgotangco> i will make sure we will have a private chat in paris
<sfllaw> :)
<sfllaw> jsgotangco: Will you be there?
<jsgotangco> yeah
<sfllaw> Nice.
<sfllaw> We should have a beer or something.
<poningru> mako: forgot to tell you about the link broken thing as well
<poningru> mako: in my post there is a link but it hrefed itself
<mako> ok
<sfllaw> mako: Sorry we missed you at Debconf.
<sfllaw> I heard you were busy getting married or something.
<sfllaw> Congratulations!
<mako> sfllaw: i'm sorry you missed me at debconf
<mako> not yet.. monday
<poningru> nice congrats
<jsgotangco> wow
<sfllaw> Congratulations anyway!
<mako> thanks :)
<neuralis> mako: whoa, dude, this monday?
<sfllaw> I'll buy you a drink in Paris.  I forget, do you abstain from alcohol?
<sfllaw> It's been a few years.
<sfllaw> And I was really drunk the last time I offered to buy you one.
<mako> neuralis: yeah, you gonna be around?
<mako> sfllaw: no, i drink
<neuralis> mako: let me find out when my flight is
<mako> neuralis: heh, cool
<neuralis>  4  LH 421 Q 29MAY 1 BOSFRA HK1  2050 E  2150 1055+1 *1A/E* 
<sfllaw> Wow.  That's like line noise.
<mako> neuralis: yeah, you can come if you want
<mako> neuralis: we'll be at davis sq.. 2.. i'll send you an email
<mako> neuralis: i haven't sent out invites to anyone yet.. we had a last minute change of venue
<neuralis> mako: my dressy clothes are all packed, sadly
<mako> neuralis: um.. you'll fit right in then :)
<neuralis> haha
<mako> neuralis: it's gonna be like 31 degrees :)
<mako> neuralis: and JZ is marrying us :)
<neuralis> are you serious? that's hilarious :)
<neuralis> sounds like i'll have to at least drop by for a bit
<LaserJock> mako: congrats and good luck :-)
<neuralis> mako: although better jz than rms.
* neuralis cracks up at the thought.
<sfllaw> Which JZ?
<sfllaw> jwz?
<mako> neuralis: it's gonna be very laid back.. a few kegs of beer.. bbq. we're saving the painful tradition stuff for a ceremony with the parents and stuff out in seattle in a couple months
<Burgundavia> mako, any idea of that timetable?
<neuralis> sfllaw: http://en.wikipedia.org/wiki/Jonathan_Zittrain
<mako> sfllaw: jonathan zittrain, prof of cyberlaw at harvard/oxford
<sfllaw> mako: Woah.  Wicked.
<fabbione> hey mako!
<mako> Burgundavia: still under negotiations, i'll let you know though
<mako> fabbione: hola
<Burgundavia> mako, I should be able to make it, so give a bit of warning
<mako> Burgundavia: that would be fun :)
<sfllaw> I was just sent spam asking me to someone something.
<sfllaw> Apparently, I'm obviously a supplier of OEM Original HP C6578DN Genuine Tri-Color Inkjet Printhead Cartridges.
* jsgotangco used to think mako is the type of guy who is willing to get married in SecondLife
<mako> jsgotangco: i don't think i'm the kind of guy who is willing to play secondlife
<fabbione> YES YES YES YES YES YES!!!!
<jsgotangco> heh
<neuralis> mako: in other news, it's way creepy that you're getting married. you're not much older than i am.
* fabbione just got the 4 core Niagara to boot properly
<sfllaw> mako: Isn't your first life awesome enough?
<mako> neuralis: tell me about it
<sfllaw> fabbione: Sweet!
* sfllaw hugs fabbione.
<neuralis> fabbione: rock!
<fabbione> sfllaw: now we know how to workaround the issue
<mako> neuralis: if you had told me i would be getting married 3 years ago, i would have freaked out
<sfllaw> fabbione: Good.  I didn't even know there was a problem.
<fabbione> https://wiki.ubuntu.com/sparc/KnownIssues <-
<fabbione> sfllaw: now you do :)
<sfllaw> fabbione: Excellent.
<fabbione> that page still needs itaglish to english translation
<mako> neuralis: but in all fairness, i am getting married by JZ at a keggar in my friends backyard
<neuralis> mako: true, true.
<sfllaw> mako: There aren't enough good keggers in this world.
<mako> sfllaw: dude, we're getting a keg of frambois
<mako> yes, it comes in kegs in this country (apparently)
<sfllaw> mako: Yay!
<sfllaw> mako: I'm trying to organize Debconf in Montral.
<sfllaw> I'm thinking kegs of a different microbrews each night.
<mako> sfllaw: you have my vote
<sfllaw> Also, we can get tasty vegan food here.
<sfllaw> Which I think will draw a large contingent of "yes"es.
<mako> excellent!
<sfllaw> I just have to find a university who wants to put us up for nearly nothing.
<mako> sfllaw: are you vegan?
<sfllaw> No.
<sfllaw> But I am sensitive to these issues.
<mako> i am, if you'll forgive the self-deprecation, merely a lacto-ovo vegetarian ;)
<sfllaw> :)
<sfllaw> If I play my cards right, I think I can fool most people into eating a mostly vegan diet.
<sfllaw> It's cheaper, which is good for budgets.
<jsgotangco> wow
<poningru> sfllaw: you know if you come to florida US there are many uni's that will put you up for cheap
<sfllaw> poningru: But it's not Montral.
<sfllaw> I have a few years to set things up.
<sfllaw> I should try to get a dorm to put about 300 people in.
<sfllaw> And access to an industrial kitchen.
<sfllaw> And some lecture halls.
<sfllaw> And free Internet.
<sfllaw> In the downtown core.
<sfllaw> How difficult could that possibly be?
<poningru> in gainesville florida...not very
<poningru> in montreal 
* poningru shrugs
<sfllaw> I have never been to Gainesville.
<poningru> well its a college town
<poningru> uni of florida
<poningru> http://en.wikipedia.org/wiki/Gainesville,_Florida
<poningru> it has a pretty big lug
<sfllaw> Wow.  It _is_ a University town.
<sfllaw> Less than 100,000 people.
<sfllaw> Does that include students?
<neuralis> sfllaw: there was a strong bid by toronto for the 2006 wikimedia conference
<poningru> sfllaw: no that does not include students
<neuralis> sfllaw: maybe they'd want to do debconf; http://meta.wikimedia.org/wiki/Wikimania_2006/Toronto
<sfllaw> neuralis: Uhm.  Debconf 2 was held in Toronto.
<sfllaw> :)
<neuralis> sfllaw: i had no idea. (as someone who used debian for nine years, it's a bit embarrassing, but i've never been to a debconf.)
<sfllaw> neuralis: You should!
<sfllaw> You're in Cambridge?
<neuralis> yeah. i would've gone to mexico, but i simply didn't have any time :/
<sfllaw> Next year?
<neuralis> very likely.
<neuralis> ufk in the short term, and ubucon if i find time to go down to sf for lwe.
<poningru> sfllaw: also gainesville has really good vegan food culture
<poningru> and UF has tons of dorms
<poningru> which are not used at all during summer
<sfllaw> poningru: Your biggest problem would be that your country is one that not many people would go to.
<poningru> true...
<sfllaw> Debconf is typically held in the Very Free World.
<poningru> :(
<sfllaw> poningru: When are you guys going to elect another FDR?
<poningru> if only
<poningru> baah this entire thing will blow over in couple of years
<poningru> atleast in 2008
<poningru> hopefully
<jsgotangco> ?
<Burgundavia> sfllaw, our guy is shining star either
<Burgundavia> s/is/is no
<sfllaw> Our system of government moderates him.  He either needs the Bloc's support, or the NDP's.
<Burgundavia> sfllaw, yes, but have seen the latest polling numbers in Quebec. I am scared
<poningru> sfllaw: its the same here in the us as well... except congress is filled with the same party members as he is
<sfllaw> poningru: Your system of government is fairly different than ours.
<poningru> yeah... but I was refering to the balance of powre
<poningru> as in the executive still needs the congress' support inorder to do ... anything significant
<sfllaw> poningru: Your administration seems to believe in the Unitary Executive Theory.  Which few people seem to challenge.
<sfllaw> But I believe this is way off topic for #ubuntu-devel
<poningru> #ubuntu-offtopic ?
<nomed> hi all
<yuriy> ping YokoZar
<nomed> sfllaw, bug #46502
<nomed> i know they are just icons .. but if they are not in tango-icon-theme-common xubuntu menu will miss icons on the menu :)
<Ubugtu> Malone bug 46502 in tango-icon-theme-common "new xfce icons" [Major,Confirmed]  http://launchpad.net/bugs/46502
<sfllaw> nomed: That doesn't seem to be a release critical bug to me.
<sfllaw> They certainly aren't part of the human theme.
<sfllaw> You'll have to convince mdz to put them in.
<nomed> sfllaw, there is not just ubuntu 
<nomed> as i told that's critical for xubuntu ..
<nomed> hi janimo 
<sfllaw> nomed: I don't know how xubuntu gets released.
<janimo> hi nomed
<sfllaw> But I have no control over uploads.
<janimo> what is critical for xubuntu?
<nomed> sfllaw, dholbach knows already that issue .. i just do not know how he sorts bugs :)
<nomed> janimo, ex xfburn icon
* janimo notices xubuntu is not mentioned in the announcement :(
<janimo> nomed, there is no upstream icon for that, I know.
<nomed> it's in tango-icon-theme-common
<janimo> I would not call it critical though :)
<nomed> janimo,well ..
<nomed> there is a menu spec entry
<janimo> oh, it does have an icon it just does not fond it you mean?
<nomed> janimo, no
<nomed> i added it to tango-icon-theme-common
<nomed> as all the missing and needed xfce icons
<janimo> nomed, why does xfburn not come with it itself? it;s an app specific icon
<janimo> like thunar's
<nomed> dholbach will just need to  merge it as ge did the last time :)
<sfllaw> nomed: I will leave its priority to dholbach's discretion.
<nomed> janimo, xfburn has not an icon
<janimo> nomed, ok that's why I say we should not add it to the menu
<nomed> but we use the burner icon from tango-icon-theme-common
<janimo> people would associate it with tha ticon, and when upstteam gets an icon it will surely look different
<janimo> if in the next few days we can convince upstream to come up with an icon that's a different story :)
<nomed> janimo, in tango-icon-theme-common there are apps icons
<janimo> nomed, so changing the desktop file would suffice?
<nomed> it's the same for amarok
<nomed> and many others
<nomed> janimo, you do not have to do anything
<nomed> it'll just work once dholbach will find the time to merge my bzr branch
<desrt> woo.
<desrt> built-in elilo
<fabbione> desrt: ?
<desrt> fabbione; my new macbook arrived today
<desrt> i'm trying to install dapper
<desrt> it looks like a lot of people have done some things that will make my life easier
<fabbione> isn't that the i386 junk?
<desrt> not junk
<sfllaw> fabbione: I thought the new Intel chips were amd64.
<fabbione> sfllaw: still x86* junk :)
<sfllaw> fabbione: Stop being an architecture snob.  Not everyone is privileged enough to afford Real computers.
<desrt> what would you prefer?  powerpc?
<fabbione> sfllaw: please stop dude.. you don't know that desrt and I had known each other for a while and that we used to kid about $arch
<sfllaw> Ah.
<sfllaw> :)
<fabbione> sfllaw: desrt still owns me a g5 ;)
<zyga> hello
<zyga> there is a problem with the EU tracker mirror
<zyga> ubuntu-6.06-rc-desktop-i386.iso does not download (requested download is not authorized for use with this tracker)
<zyga> same with -powerpc.iso
<zyga> strange, no one around
<fabbione> ?
<jdub> zyga: calm after the storm
<jsgotangco> :)
<zyga> :)
<zyga> those torrents are still dead 
<zyga> others seem to pull just fine :)
<jdub> "Yes. With this release, madwifi-old is now officially deprecated. The old codebase is no longer supported and won't receive any updates."
<jdub> d'oh
<jdub> *cough*
<fabbione> jdub: were they waiting for us to release?
<jdub> heh
* Lathiat laughs
* hunger still does not have working suspend in dapper:-(
<desrt> is there any way to prevent the install cd from switching video mode just before loading the installer screen?
<desrt> ie: just leave it in 80x25...
<fabbione> desrt: yes...
<fabbione> how.. gimme a sec :)
<desrt> it must be a -- kernel option :p
<fabbione> debian-installer/framebuffer=false
<fabbione> boot with that option
<desrt> k thx.
* desrt installing flight7 onto his new macbook :)
<desrt> worked like a charm!
<desrt> this thing is speedy
<fabbione> no rc?
<desrt> rc?
<fabbione> Releae Candidate
<desrt> oh.  it's out?
<apokryphos> yes
<desrt> since when?
<apokryphos> yesterday; see http://tinyurl.com/ehqdg
<desrt> well
<desrt> no worries
<desrt> i'm sure flight7 dist-upgrades properly
<fabbione> assuming it will not burn your computer..
<fabbione> if you see some smoke coming out, it's not our fault
<desrt> :)
<desrt> with how warm this thing runs i would not be suprised
* desrt has an interesting hybrid setup going on here
<desrt> i have the bootcamp firmware (so i can boot x86 stuff) but i do not have x86 partitioning on the harddrive
<desrt> so i have enough bios to boot linux to the point where it's able to read EFI partitions natively
<dholbach> good morning
<desrt> hello.
<jsgotangco> good morning dholbach
<dholbach> hey desrt, hey jsgotangco
<sivang> morning everybody
<desrt> i wonder if this install process will try to give me grub
<desrt> that might suck
* sivang wonders if the dreadful squashfs bug is now squashed
<Burgundavia> sivang, check ubuntu-changes, it is
<sivang> woo hoo
<jsgotangco> yeah there was an upload earlier
* sivang goes to read about what was required to kill that one
<dholbach> you won't find much in the changelog
<sivang> yeah, I see Scott was at a severe state when he wrote that changlog entry
<fabbione> there has been worst :)
<sivang> at least it was only in the fs creation tool, not in the kernel driver itself
<sivang> fabbione: heh
<sivang> fabbione: you sould have offered him your miracle drug :p
* sivang lols at what Scott wrote :-)
* sivang notes irssi is just getting crazier by the minute
<sivang> HiddenWolf: do you know if this specific bug I mentioned last night was also addressed? that is, DnD from a readonly location should not trigger a move?
<sivang> hmm, squashfs is in universe??
<pbor> is there a channel for ubuntu soc projects?
<dholbach> pbor: I think not.
<sivang> pbor ! 
<sivang> pbor: how are you?
<pbor> hey sivang, dholbach 
<dholbach> Ciao Paolo by the way. :-)
<pbor> I just found out that there is a gedit soc project :)
<pbor> http://code.google.com/soc/ubuntu/appinfo.html?csaid=4D72DEB990CEB28D
<desrt> hum
* sivang looks
<desrt> it tried to install elilo, failed.
<pbor> so I thought that I could get in touch with the student and mentor
<dholbach> nice
<dholbach> pbor: JaneW might be able to help you there.
<sivang> pbor: the mentor is Pygi
<sivang> pbor: better co-operate with the bzr-gui SoC to integrate bzr as well :)
<pbor> sivang: well, the project is primarily about integrating bzr, yes
<pbor> which channel/timezone can I find Pygi in?
<Lure> pbor: here, UTC+2
<pbor> thank, I'll hang ariund
<pbor> +s
<JaneW> pbor: lemme check...
<sivang> pbor: try to find the bzr-gui project, could just as well turn it into one of the new plugins in the RCS plugin system
<JaneW> pbor: Title 	Source Control Plugin for Gedit
<JaneW> Student 	Brian Davis
<JaneW> Mentor 	Mario ani
<JaneW> pbor: you looking for e-mail addresses?
<pbor> JaneW: no, more of an irc nick :)
<JaneW> pbor: pygi is normally in #edubuntu
* pbor joins
<sivang> pbor: http://code.google.com/soc/ubuntu/appinfo.html?csaid=6A6B14E2FE896903
<pbor> sivang: yep, I saw that... since they assigned two different soc projects I guess they should be a bit different though :)
<sivang> pbor: hmm, probably.
<moberg> hi, i've been accepted to SoC at Ubuntu. My project is "Applications to improve Ubuntu", but I don't know who is my mentor yet. (in the summary i received yesterday is only stated TBC)
* hunger wonders what kind of apps that might be.
<lmanul> moberg: what is your full name ?
<moberg> Peter Moberg
<lmanul> Weird, can't find you on the SoC Ubuntu list, maybe your mentor hasn't yet been approved into the program
<lmanul> moberg: were there any comments on your application ?
<moberg> yes, i should rewrote some of it. But I don't know where to send it
<moberg> "Very optimistic, each project would take somewhat longer to develop and test fully.
<moberg> Perhaps you should redraft your application to just focus on the one project that takes your fancy the most."
<G0SUB> JaneW: hello!
<jsgotangco> G0SUB: congratulations
<G0SUB> jsgotangco: heh, thanks!
<G0SUB> jsgotangco: can I PM you?
<JaneW> hi G0SUB 
<G0SUB> JaneW: Can we talk in private for a moment?
<JaneW> moberg: it may be Vincent Untz, but I am hoping t resolve all mentor issues today
<jsgotangco> G0SUB: sure
<JaneW> moberg: we had some duplication issues just before the announcements were made, so there was some frantic shuffling, BUT the mentor assignment function is currently frozen, so I am waiting for google to give me access again
<JaneW> G0SUB: sure
<moberg> JaneW: ok
<moberg> should I conntact him now and give him my redrafted version of my proposal, or should I wait until the mentor issues are resolved?
<JaneW> moberg: can you wait a short while (hour or so)? I'll try to discuss with mentors and see who will be taking it officially
<moberg> JaneW: ok
<dholbach> heya seb128
* dholbach hugs seb128
<seb128> hi dholbach
* seb128 hugs dholbach
<G0SUB> ah, there goes the hugging contest ...
<G0SUB> is it a hug day today?
* desrt (successfully) speaks some 915resolution magic into his macbook's ear
<fabbione> FYI: launchpad is down
<fabbione> it is a known issue. kthxbye
<sladen> desrt: does that actually work?  There's no BIOS to *patch* on a MacBook
<sladen> desrt: ...unless you're running in BootCamp mode
<desrt> i booted with quasi-bootcamp
<desrt> i'd like to find out how to not do this but it doesn't seem too easy
<desrt> fabbione; does this mean the archive is down too?
<fabbione> nope
<fabbione> only LP web interface or so it seems
<sladen> desrt: currently the kernel/etc on the i386 CD work, but there's no [Free]  code to generate an HFS+ image to boot from... I suspected there will be a hand-patched CD available after release built with the aid of a MacOSX box and that will/should boot natively
<desrt> i have this refit thing installed
<desrt> it's very nice
<desrt> hum.  atheros seems to be broken with nm-applet
<seb128> grumpf, rsync on the edubuntu CD seems to redownload the CD for every update, I'm wondering why
<ptlo> pygi: ping
<pygi> ptlo, I am asleep :)
<ptlo> pygi: have you translated anything? i don't want to freeze the others, i've revised everything last night. so if you want you can translate starting at offset 600, 's that ok with you?
<pbor> oh pygi joined... pygi ping too :)
<pbor> (when you wake up obviously)
<pygi> ptlo, ok, send me url at mail?
<pygi> pbor, how may I help? :)
<ptlo> pygi: sure. sleep well :)
<pygi> ptlo, thanks :)
<pbor> pygi: I am on of the upstream devs of gedit... I discovered you are mentoring a gedit soc...
<pbor> pygi: just wanted to get in touch
<pygi> pbor, ah, nice :)
<pbor> pygi: feel free to tell your student to join #gedit on gimpnet... in fact there are other people which are/were working on a 'project management' plugin
<pygi> pbor, I ofcourse will...I'll come also so we could discuss this project in detail
<pbor> sure
<pygi> if you remember we were already discussing about that?
<pbor> heh
<pygi> :)
* pbor has short memory
<pygi> yes, you said that also :-P
<pbor> :)
<pygi> pbor, can we talk later please if you don't have anymore questions now? :)
<pygi> I gotta run, and then later on do the translation or ptlo will eat me :)
<pbor> pygi: yes, I don't have any particular question, as I said I just wanted to get in touch
<pygi> thanks for that pbor :)
<pbor> np
<pygi> enjoy :)
<dholbach> Kamion, mdz_: ok to upload ubuntu-artwork (added some icons which didn't show up until now)
<desrt>  k.  elilo installs fine now, but locks on startup
<desrt> hrmph.
<sladen> desrt: you need to use elilo in EFI, or lilo with Boot-Camp
<desrt> i am trying to use elilo in efi
<desrt> it loads the kernel and initrd
<desrt> but then locks
<desrt> i get
<sladen> desrt: remind me again how you /installed/ the machine using EFI?
<desrt> Loading file \EFI\ubuntu\initrd.img...done[newline] 
<desrt> then lockup
<desrt> i didn't.  i used bootcamp for install.
<desrt> but i have efi-only partitioning
<sladen> desrt: right, then you need to use lilo.  not elilo.  elilo is for EFI machines.  The Mactels are *not* EFI machines when booted from Bootcamp.
<desrt> i'm _not_ booting from bootcamp
<sladen> desrt: "<desrt> i used bootcamp for install" ?  I'm confused
<desrt> you're able to have bootcamp installed without using it to boot
<infinity> mdz_: Around?
<desrt> for example, macosx still starts using EFI even on a machine with bootcamp
<desrt> and elilo is loading quite nicely
<desrt> it's just crashing after reading the kernel image from disk
<sladen> desrt: how did you write to the EFI nvram to tell EFI to load elilo?
<desrt> i didn't.  i'm using rEFIt
<zyga_> hmm
<desrt> which i blessed using a macos installer cd
<desrt> it's a fantastic program
<desrt> gets a big thumbs-up from me
<sladen> desrt: oh right... okay.
<zyga_> does dapper work with itanium efi?
<sladen> zyga_: yes, elilo+EFI on ia64
<zyga_> great, thanks :)
<desrt> woh
<desrt> it sleeps!
<sladen> zyga_: the only thing $special about the Mactels is that they don't boot FAT, or iso9660, from removalable media
<desrt> it does not, however, wake up
<desrt> sladen; unless you have bootcamp :)
<sladen> desrt: in which case it's not a Mactel, but a poor imitation of a PC
<desrt> true story
<desrt> apple's BIOS is actually not too bad
<desrt> maybe i should call it pseudobios
<Kamion> sfllaw: could you please leave bug 46520 on grub-installer? There's no indication that it's a ubiquity bug, and even if it were I'd probably assign it to grub-installer on the basis that that's the piece of the installer that does the relevant work.
<Ubugtu> Malone bug 46520 in grub-installer "Grub installes to wring drives MBR in defualt install. No way to change in standard installer." [Normal,Unconfirmed]  http://launchpad.net/bugs/46520
<\sh> BenC: ping could you elaborate on "Areca SCSI Raid Controller in ubuntu linux kernel 2.6.15 not enabled by default"
<infinity> Kamion: If you try to fix that bug, can you ping me to test your fix?  (I'll subscribe to it right now)
<fabbione> \sh: bug num?
<zyga> 
<infinity> Kamion: I ask because grub-installer used to (in pre-breezy days) mess up with Zofia's SATA/PATA combination, but it now works correctly, so I'd prefer if it didn't regress. :)
<\sh> fabbione: no bug...just for my information...I'm thinking to propose this company here to switch from sles9 to ubuntu server with support contract :)
<mdke> seb128: this page is obsolete now right? https://wiki.ubuntu.com/DesktopTranslations
<\sh> fabbione: and as I told you last time...I have until the 12th july 1000 machines with areca controller, which are not working on sles9 but with ubuntu kernel (and enabled areca driver) they're running fine
<fabbione> \sh: so it's only missing the option in the config?
<\sh> fabbione: yeah..not enabled by default
* fabbione checks
<\sh> fabbione: but I think someone had some reasons to do so
<infinity> Man, I'm loving all the server errors on LP right now.
<fabbione> \sh: ok i am checking the code.. just give me a few minutes please
<\sh> fabbione: thx :)
<seb128> mdke: yep, for 6 months or something like that
<seb128> mdke: Desktop are translated by rosetta now
<mdke> seb128: right, I'll bin it... people are still contributing :)
<rob67> may i ask a question for the next release?
<Kamion> infinity: it's so far up my list of "do not touch at this stage" ...
<mdke> rob67: you can try it
<infinity> Kamion: Right, I assumed it was a "don't touch for dapper" bug.  Still, if you poke at this stuff in edgy, I'd like to make sure it doesn't explode.  I was pleasantly surprised when it magically started working. :)
<rob67> ok, thanks.  can i please put in a request to have xchat installed like the last version please?
<rob67> i love Dapper, but i had to install an irc client before i could get on here
<mdke> rob67: it's too late to change it now :) 
<rob67> i mean for the next one after Dapper
<mdke> you can use gaim to get here, for next time
<\sh> rob67: konversation is still default in kubuntu-desktop >;-)
<infinity> rob67: It may not be all that intuitive, but irssi is installed by default still.
<mdke> rob67: have a look at bug #38694
<Ubugtu> Malone bug 38694 in ubuntu-meta "No XChat in Dapper" [Normal,Rejected]  http://launchpad.net/bugs/38694
<mdke> infinity: ah, a friend of mine had a problem with grub installing to the wrong disk, i'll dig out the bug number, maybe it's a dupe
<rob67> ok.  ill let you guys decide, after all you are the genesius' :)  thanx again.
<mdke> was bug #45989
<Ubugtu> Malone bug 45989 in grub-installer "Installation to second disk confuses drive numbering" [Normal,Unconfirmed]  http://launchpad.net/bugs/45989
<fabbione> \sh: i don't see anything fancy for that driver...
<Seveas> heh, what did keybuk drink at 2:55 UTC? :0
<\sh> fabbione: so it could be enabled by default as "official" supported driver by Canonical?
<fabbione> \sh: assuming there will be another kernel upload.... and d-i
<fabbione> i need to get some food
<fabbione> later
<\sh> fabbione: who can tell? :) would be the kick suse out of business reason
<infinity> I doubt there's be another round of kernel and d-i uploads.
<infinity> (That would also require an initramfs-tools upload to add the driver to the SCSI module list)
<fabbione> \sh: our support center would tell
<desrt> hmm
<desrt> new version of elilo is out that sounds like it fixes the bug i'm encountering
* desrt takes it for a testdrive
<\sh> fabbione: jbailey is the responsible person for the support center?
<jsgotangco> wow the kubuntu splash is beautiful
* Riddell hugs jsgotangco 
<tepsipakki> is it intentional that if I install both gdm and kdm, both also run (two X servers)?
<tepsipakki> before there was /etc/X11/default-display-manager, but not anymore
<apokryphos> nope, there should only be one running, which one to be run is configure from sudo dpkg-reconfigure kdm/gdm, and that should be run on new install of gdm/kdm
<jsgotangco> holy
* jsgotangco looks at the glory of wireless assistant
<tepsipakki> apokryphos: yes, manually running that creates /etc/X11/default-display-manager, but it isn't created on install
<fabbione> \sh: yes
<dholbach> heno: did that fix bug 46713?
<Ubugtu> Malone bug 46713 in example-content "Examples in "oo-about-these-files.odt" out of date." [Normal,Unconfirmed]  http://launchpad.net/bugs/46713
<heno> dholbach: yes, and the stuff in the comment too
<dholbach> super
* dholbach adds to changelog
<infinity> \sh: Err, wait.  Doesn't the arcmsr module work with your controller?
<infinity> (base)adconrad@cthulhu:~$ modinfo arcmsr | grep description
<infinity> description:    ARECA (ARC11xx/12xx) SATA RAID HOST Adapter
<infinity> \sh: That's been in our default kernels for a while, though initramfs-tools only learned about it on May 16th (maybe that was your issue?)
<Mithrandir> Keybuk: where's the published bzr branch of your casper upload?
<Keybuk> Mithrandir: there isn't one
<Keybuk> because I keep forgetting that such things exist
<Mithrandir> I should make the casper source build fail unless you put "Yes, I've published the branch" into the changelog or something. :-P
<Keybuk> Mithrandir: that would not be unreasonable I guess
<Keybuk> though you don't need to publish the branch anywhere
<Keybuk> as the branch is in the source package
<Keybuk> certainly having the binary step fail if it's uncommitted might be sweet
<Mithrandir> I want it published so I can pull from it; bzr can't do bzr merge lp://casper/latest
<\sh> infinity: can be, I'm using still kernel 2.6.15-22
<\sh> infinity: and no...initramfs is not the issue...the driver wasn't enabled in ubuntu .config :=)
<Kamion> whoa, vim 7 automatically folds debian/changelog
<Kamion> +-- 11 lines: debian-installer-utils (1.30) UNRELEASED; urgency=low -- Colin Watson  -----------------------------------------------------------------------------------------------------------------------------
<Kamion> +--  6 lines: debian-installer-utils (1.29) unstable; urgency=low -- Frans Pop  ----------------------------------------------------------------------------------------------------------------------------------
<Kamion> I wonder if I'll ever get used to that or if I should just turn it off
<Keybuk> Mithrandir: you can apt-get source and merge from that though
<Mithrandir> Keybuk: yes, but I'm lazy.
<Keybuk> Mithrandir: so I think requiring people to explicitly publish it somewhere is unreasonable
<Keybuk> Mithrandir: so are other people, like me
<Keybuk> I'd just bypass the check :)
<Kamion> has anyone confirmed the current amd64 desktop CD?
<Kamion> or do the buildds still need to be upgraded for that?
<Keybuk> Kamion: dunno, I've only just woken up
<infinity> \sh: Oh, well, we've been including arcmsr in the default kernels for a long time, so... Hrm.
* Kamion would just like to say:
<Kamion> Listing ubuntu/dapper (NEW) 0/0
<fabbione> missing from the udeb?
<Kamion> infinity: ^--
<Kamion> infinity: squashfs-tools on king?
<\sh> infinity: ah in linux-source of 2.6.15-22 it's enabled by default...thx :)
<infinity> Kamion: I'm checking now.  The cronjob wasn't re-enabled anyway, so unless you've triggered manual builds, there's no new livefs.
<Mithrandir> \sh: -22 is old.
<\sh> Mithrandir: I was using 2.6.15-19 as FAI install kernel for these machines and in 2.6.15-19 it wasn't enabled by default
<jsgotangco> ciao
<\sh> Anyways...thx for your help...I need to write an report now, to tell my manager that it would be a good idea, to use ubuntu server 6.06 LTS as replacement to sles9
<infinity> Kamion: Updating all the chroots now.  We can do a quick amd64 manual test run to make sure it's okay after that.
<infinity> Keybuk: If we build a new amd64/desktop, can you rsync it and test?  Zofia's doing homework on her machine, so I can't appropriate it right now. :)
<Keybuk> infinity: certainly
<Kamion> I can too
<Keybuk> we should probably test that ALL of the LiveFSs work, on general principal
<infinity> Okay.
<Keybuk> though the upstream author confirms the fix
<infinity> Kamion: I'll poke you when the livefs builds are all done.  (I'll do one for each of ppc/i386/amd64)
<infinity> Keybuk: Speaking of "the fix"... I noted a very clever changelog entry, but actual mention of what the bug was or how it was fixed. :)
<Keybuk> infinity: heh
<Keybuk> that's because it was too complicated to explain in a ChangeLog
<Keybuk> so, right
<Keybuk> a squashfs consists of a whole bunch of inodes
<Keybuk> directory inodes just link to children, etc.
<Keybuk> file inodes have a list of "fragments" that need to be joined together to make the file
<Keybuk> each fragment is a compressed or uncompressed block of data, that may be shared amongst multiple files
<Keybuk> and at the end of the squashfs is the fragment table, that lists all of the fragments (the inodes contain indexes, rather than in-data pointers)
<Keybuk> the fragment table isn't just <len><entries ...> though
<Keybuk> it too is compressed
<Keybuk> in fact, the fragments are compressed blocked, and then the table itself is also stored in multiple compressed blocks
<Keybuk> the table is in 8192K chunks, each chunk holding 1024 entries (each one is 8 bytes each)
<Keybuk> uh, 8192 byte entries, sorry
<mdz_> dholbach: ubuntu-artwork OK
<mdz_> infinity: yes
<Keybuk> when writing this table out, squashfs had a calculating error for "how much space is left" ... it used %, so if there was a complete chunk remaining, it thought there was 0 bytes not 8192
<Keybuk> so, this meant that it called compress2() with destLen=0
<Keybuk> zlib whenever asked to compress 0 bytes returns 8 bytes of header
<Keybuk> because the "compressed size" was greater than the uncompressed size (8>0) it decided that the last fragment table chunk would be uncompressed, so marked it as such by ORing the size with 1<<15 
<Keybuk> the net effect was that the last chunk of the fragment table was not read properly
<Kinnison> urgh
<Keybuk> so accessing any file in the last 8th of the disk would have been accessing random data
<Keybuk> the reason this affected the amd64 CD only, was that it had EXACTLY 8,192 fragments
<Keybuk> (there was enough duplicate blocks in those shiny new oggs to give this number even if other packages were changed for a bit)
<Kinnison> erk
<Keybuk> it actually turns out that it would affect any squashfs image with multiples of 1,024 fragments
<Keybuk> the last fragment would always be busted
<Keybuk> uh, last 1,024 fragments, sorry
<infinity> mdz: Do we want to get some hideous strace-during-build hack into OOo for my pending (final) upload, or shall we just bury our heads in the sand on this one, knowing that security updates will build fine anyway, since terranova is our secrity buildd right now (and when security moves to LP, elmo can give us a new CPU or other such things to mask the bug)?
<mdz> infinity: I think strace was a red herring, so no
<Keybuk> obviously, the fix was to correct the "available space in the fragment table" calculation
<infinity> Keybuk: That's so awesome it hurts.
<mdz> Keybuk: goodness me
<Keybuk> I NOW KNOW MORE ABOUT SQUASHFS THAN I EVER WANTED TO!
<StevenK> Keybuk: Your poor eyes are burning? :-)
<Keybuk> it would have gone away, eventually, but we'd have to stir in some SERIOUS entropy -- basically a 64KB block of data that does not exist anywhere else on the filesystem
<Keybuk> and it would have bitten us on another CD too, eventually
<Keybuk> in fact, I looked through Malone, and found a bug that sounded identical -- so we clearly did have a CD pop before
<mdz> ternary conditional operator abuse!
* mdz shields his eyes
<mdz> Keybuk: nice work
<giftnudel> Keybuk: really!
* mvo hugs Keybuk for fixing this
<infinity> Keybuk: Your sleeplessness on this one won't go unrewarded.  Remind me that I owe you a beer or three in Paris.
<Keybuk> yeah, right, who here could sleep once they've got their teeth into a bug like that? :p
<dholbach> Gloubiboulga: you guys will have to rebuild tango-icon-theme and tango-icon-theme-common to benefit from the icon-naming-utils changes
<desrt> well
<desrt> i've learned a lot about the new macs tonight
<desrt> mostly i've learned that they're absolutely insane
<Keybuk> http://people.ubuntu.com/~scott/unsquashfs.c
<Keybuk> ^ we should stuff that in the source package
<Keybuk> well, after it's less hacky
<desrt> running the upgraded firmware on them turns them into some strange sort of hybrid beast
<infinity> Keybuk: Oh, can you be a dear and push your patch to Debian, so we don't have to worry about merging it when we bump to 3.0 in edgy?
<Gloubiboulga> dholbach, ok, thanks
<sladen> Keybuk: NMU it as release-critical...  (and ignore which OS it's release-critical for, fnarr).
<Keybuk> infinity: yeah, will report it to them
<Keybuk> it'll be interesting to see how quickly upstream applies the patch
<infinity> sladen: No need to NMU it, the Debian squashfs maintainer is quite responsive, and takes patches.
<infinity> (He took Tollef's progress output patch, for instance)
<dholbach> mdz: uploading example-content
<mdz> dholbach: ok
<mdz> Keybuk: how did you track it down in the end?
<infinity> Kamion: livefs builds ready, BTW.
<mdz> Znarl: do you know anything about the transparent proxy here in the office?
<infinity> Keybuk: Hrm.  To trip the bug, mksquashfs needs to report "Number of fragments: 8192", doesn't it?
<infinity> Keybuk: If so, this test is worthless anyway, since archive churn appears to have given the amd64 livefs 8196 fragments now.
<mdz> infinity: all the better
<mdz> FIX ME HARDER
<mdz> I assume I'm the only one seeing MD5Sum mismatches on main and universe Sources in current Dapper
* mdz points at squid and curses
<fabbione> mdz: the publisher is still running 
<infinity> Which means nothing.
<fabbione> i get them often between XX:30 and XX:45
<infinity> The publisher only moves the new archive in place when it's done.
<fabbione> infinity: s/publisher/rsync
<infinity> A slow rsync could do it, yes.
<Guard] [an> hello, i just tested dapper drake RC, it's fine but isn't xgl+compiz supposed to be activated ?
<infinity> Guard] [an: Heavens no.
<infinity> Guard] [an: XGL is seriously experimental tech, and pretty much guaranteed to break, just cause it feels like it.
<Guard] [an> infinity : so i have to follow the usual steps to have it ? or is there some simplified procedure ?
<Kamion> infinity: cron.daily-live running on lithium
<Keybuk> infinity: right, if you rebuild 20060525 with it, it boots (I tried that)
<Keybuk> mdz: well, being able to produce "broken" and "working" o
<Keybuk> images on demand kinda helped
<karim> can I ask something about apt-build here ?
<Guard] [an> infinity : thx
<Keybuk> I noticed the mksquashfs code could actually read its own generated filesystems (so it can append to them), so I hacked up an "unsquashfs" that only read a filesystem image and would report whether it was ok or not
<Keybuk> that worked on the "working" images and core dumped on the "broken" ones
<karim> I was wondering why it was downloading libdevel from binary source instead of building them
<Keybuk> at that point, it was just a matter of gdb on unsquashfs until I understood why it core dumped -- which I tracked to the fragment table being boll
<Keybuk> ocksed for the last 1024 entries
<Keybuk> and then tracing mksquashfs as it wrote the fragment table and realising what was broken
<infinity> karim: Because that's what apt-build does.  It doesn't re-bootstrap your whole system, it just builds the package you asked it to.
<Keybuk> I'd gathered lots of debug logs while making the images, and I'd noticed there that all of the broken ones had 8192 fragments -- and that the fragment chunk size also happened to be 8192
<karim> infinity, may ask you more about that ?
<infinity> karim: Not really on topic here.
<karim> infinity, apt-build is in perl, I am looking forward how to build deps he wants to install recursively
<karim> infinity, yes, but I though people experienced with  it might be here
<karim> thanks
<mdz> infinity: did you have a look at those oo.o LP URLs?
<infinity> mdz: Doing that one right now.
<infinity> mdz: Should be uploaded and building on terranova when my bandwidth says it's okay.
<karim> infinity, I am thinking of adding an option that would do more
<infinity> karim: You may want to discuss it with the Debian maintainer (acid@debian.org), then.  I suspect almost no one here has ever used apt-build.
<karim> infinity, by the way there was a package called apt-fu. I can't find a trace of it on the internet or debian. since it sopped in 2003 and wasn't included in debian at all
<karim> infinity, ok thanks
<mdz> infinity: is your bandwidth misbehaving?
<infinity> mdz: No, I just live in Australia, and OOo has a 73MB diff.gz :)
<mdz> infinity: would be faster to apply it on chinstrap and upload from there :-)
<infinity> (Too late now)
<iwj> This kubuntu install (alternative cd) is showing me a strange black screen with two white character cells.
<iwj> While it rattles the disk gently.
<mdz> iwj: almost soothingly?
<mdz> infinity: are we clear to build new desktop CDs all around?
<infinity> mdz: We just built new Ubuntu ones.
<infinity> mdz: We can certainly do the other 3 as well.
<mdz> infinity: do they have new livefses ready?
<infinity> Nope, I'll spin 'em right now. :)
<infinity> Grinding.
<Kamion> Ubuntu desktop is already rebuilt
<iwj> If it wasn't spinning up the cd occasionally I'd think it had crashed.
<Kamion> iwj: can it switch tty?
<infinity> Whoa, I just typed my GPG passphrase correctly, TWICE IN A ROW.
<infinity> This is going to be a good day.
<ogra> heh
<kiko> infinity, choose one which doesn't have 98 characters in it?
<iwj> Kamion: apparently not.  I'm trying it again with breezy to see if it worked then (this is the disk I bought this morning).
<iwj> But I think I blame the installer because I saw something similar yesterday and blamed it on the old broken disk I was using.
<infinity> kiko: That's not fair.. It's only about 32... They're just hard to get right with shift drift.
<Kamion> iwj: I'd blame the kernel, not the installer, if you can't switch tty. The installer is an ordinary userspace process.
<Kamion> Well, not perhaps entirely "ordinary", but in the relevant senses ...
<infinity> iwj: Is this the same machine that exhibits the sketchy usplash behaviour?  If so, you may want to try booting with debian-installer/framebuffer=false
<iwj> infinity: Yes, it's the same machine.
<iwj> I'll give that a go when I've seen what breezy makes of it.
<Keybuk> how long does it take to get a reply from bugs.debian.org now?
<Kinnison> Keybuk: supposedly no more than 15 minutes or so
<Keybuk> hmm
<Keybuk> has been half an hour
<ogra> Kamion, i had some complaints from testers that the new text "install in textmode" would be confusing (since they looked for a edubuntu server option) would that be hard to change for final ? (seems most translations still say "install to harddisk" anyway, could we revert that for edubuntu ) ?
<ogra> s/revert that/revert to that/
<infinity> Keybuk: It's been slow in the last day or two.  Not sure why.
<Kamion> ogra: mdz explicitly asked me to change that to "install in text mode"
<Kamion> ogra: oh, for Edubuntu? maybe, I guess
<ogra> yep
<mdz> fine with me
<Kamion> I'd need to upload gfxboot-theme-ubuntu to get the translations for "install to hard disk" back, though
<infinity> Kamion: I'm running kubuntu cron.daily-live on lithium right now, BTW.
<Kamion> infinity: thanks
<ogra> Kamion, i'm personally fine with both, so only do it if time permits
<Kamion> I think it should be changed back to "Install to the hard disk" for the server CD as well, personally
<ogra> yes, makes sense
<ogra> dapper-dvd-i386.iso
<ogra>   1957521269  58%   10.70kB/s   36:35:26
<ogra> bah
<Traveler1> .
<looksaus> iwj, dholbach referred me to you here for https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Confirmed]  
<looksaus> I'm a bit caught between a stone and a hard place: afraid to bother you good people in such a busy period with something that might turn out of little importance
<looksaus> and on the other side, a potentially showstopper firefox problem on ppc
<looksaus> is there anything I can/should do to help you determine the seriousness of this problem?
<sladen> looksaus: if it recovers after a few seconds, it's not a show-stopper
<looksaus> sladen, it doesn't
<sladen> looksaus: if it wipes your hard-drive, it's a showstopper
<looksaus> if it makes firefox entirely unusable, is it a showstopper?
<sladen> looksaus: okay, I read that as 'freezes for', sorry
<sladen> looksaus: it's just been confirmed by mdke, hopefully iwj will get to it soon enough
<ogra> he tried to already, but nobody in here could reproduce it yet
<looksaus> ogra, this is an upgrade from breezy
<looksaus> should I reinstall and try to see if the problem persists, or is there no value in that?
<ogra> well, my ppc has never seen breezy, might be the cause, yes
<infinity> looksaus: If you move your profile out of the way, does the problem persist?
<looksaus> no
<looksaus> err, I mean
<looksaus> yes
<looksaus> I'll add that info
<mdke> sladen: not me, I don't think
<HiddenWolf> sivang: re nautilus dnd: I think so, but I don't know for sure, no, sorry.
<mdz> infinity: thanks for oo.o; is Mithrandir taking care of -amd64 or are you?
<infinity> mdz: I'll roll it when the i386 build on terranova is done.
<iwj> looksaus: Ah.  Hmm.
<iwj> I don't think doing a fresh install is likely to be very informative.
<Lathiat> anyone aware of a bug for the network monitor with wireless wasting lots of whitespace?
<Kinnison> Lathiat: whitespace where?
<iwj> looksaus: I think I'd like you to strace it.  So, strace -ttvfot /usr/bin/firefox and this will generate a file `t'.  Don't attach it to the bug report; it'll be huge.
<Lathiat> between the normal network monitor
<Lathiat> and the wireless signal part
<Lathiat> and then on the right hand side of the signal part
<Kinnison> Sure this isn't panel-packing issues? (I.E. is the whitespace sensitive and is it part of the applet?
<Kinnison> )
* Kinnison spanks his enter key for being too close to the shift key
<Lathiat> yes becuase its part of the same applet
<iwj> looksaus: Err, do you start it from a terminal, and if so do you see the glibc message referred to in the bug report ?
<Kinnison> Lathiat: Odd. Perhaps seb128 or dholback will have an idea
<Lathiat> http://bur.st/~lathiat/rc.png
<Lathiat> between the "moinitors" the "signal bar" and the volume control
<Lathiat> is all part of the network applet
<infinity> Lathiat: dholbach's latest ubuntu-artwork upload has "shuffled netstatus icons around" in the changelog.
<infinity> Lathiat: Can you try upgrading and see if that fixes it?
<Lathiat> ok
<Lathiat> also that new partition size slider seems useless
<infinity> (version 25)
<Lathiat> either option doesnt sensitize it
<Lathiat> so at a guess theres another option but it should be hidden if its not displayed ?
<infinity> Lathiat: Yeah, that bug is hardly release critical, but can you file it on ubiquity?
* Lathiat nods
* mdz pummels flashplugin-nonfree
<Kinnison> mdz: What's it doing to you now?
<mdz> there is no need for it to ask me that question for every trivial change
<Keybuk> infinity: which cd images have been built with the new mksplashfs
<mdz> it asks a debconf question on every upgrade, regardless of whether it is relevant
<infinity> Keybuk: ubuntu and kubuntu so far, edubuntu is on the way.
<Keybuk> infinity: 20060526 are "new" then?
<infinity> Keybuk: Check the timestamps?
<Kinnison> mdz: question priority fucked?
<ogra> oh, why do i get new builds ?
<Keybuk> infinity: good point
<Kinnison> ogra: because we love you
<_ion> Of course i freaking want it to download the plugin from teh Internets. :-)
<infinity> ogra: Just cause.
<ogra> :P
<Keybuk> infinity: according to the timestamps, edubuntu is done
<infinity> Oh, so it is. :)
<infinity> So, just waiting on Xubuntu then, for kicks, and all the desklivetop images are re-done and ready.
* Keybuk fires up rsync
<ogra> hrm, i'm just rsyncing the dvd ... :/
<iwj> Hmm.  It's not offering me auto-resize.
<bluefoxicy> gotta go to a mock interview, I'll bug this on launchpad when I get back; this is kinda dumb, but I tried to print in Firefox before actually installing a printer
<Keybuk> iwj: the trick to that is to do an erase install, and then run the installer again
<bluefoxicy> Firefox kinda... hanged... and didn't come back.
<mdz> Kinnison: I think it's intentional and the maintainer is just crack-addled
<Keybuk> if there's >3GB free after the erase install, you'll be offered auto-resize
<Kinnison> mdz: yeesh
<bluefoxicy> Anyways out *runs very fast*
<iwj> Keybuk: I did a manual partitioning install and there ought to be plenty of space.
<Kinnison> mdz: you want me to set it to medium and upload?
<mdz> Kinnison: one needs to try hard to get debconf to ask the question again and again on every upgrade
<Kinnison> mdz: Or do you have a fix done already?
<Kamion> iwj: send me /var/log/partman and I'll look into why
<Lathiat> hrm why does the default sources.list list multiverse for dapper-updates but not for dapper or dapper-security
<Lathiat> it seems even if we dont want to recommend multiverse it should at least be included in security if its in updates unless the inclusion in udpates is a mistake?
<mdz> Kinnison: it should only ask the question when there is a new upstream version available for it to fetch
<mdz> Kinnison: no, I haven't touched it
<Kamion> Lathiat: I think it's a bug that it's included for updates
<Kamion> mdz: ^-- can I fix that?
<Lathiat> (has been for a long time)
<Kinnison> mdz: unfortunately I think there's only install/uninstall for the script, there's no "check"
<Lathiat> so is it a policy not to list multiverse by default?
<Lathiat> also - does ubiquity download the latest updates from the internet automatically?
<Kamion> Lathiat: yes
<Lathiat> i seem to have no updates upon reboot
<Kamion> Lathiat: yes it's a policy not to list multiverse by default
<Kamion> Lathiat: no, ubiquity doesn't download updates
<Kamion> nor does the regular installer
<Lathiat> hrm ah i guess ftp.uwa = au.archive must be out of date a bit
<Kinnison> mdz: In fact, this whole package looks crack addled
<Kinnison> mdz: but at least it's not ruby any more
<infinity> I'd really like to resurrect the license-scary flashplayer-mozilla (which I still have installed), but that would require us getting a distribution license from Macromedia.
<mdz> Kamion: commented or uncommented?
<seb128> Kinnison, Lathiat: icon issues are for dholbach
<Kinnison> seb128: thanks
<seb128> np
<Lathiat> seb128: cheers
<mdz> infinity: I think there's a reasonable chance that they would grant one
* Kinnison ponders what to do for lunch
<mdz> s/would/will/
<Kinnison> Then it could just go into multiverse properly?
<infinity> mdz: I'm fairly sure they would, but I never got around to asking them. :/
<infinity> Fell WAY off the bottom of my TODO.
<Kamion> mdz: at present it is there uncommented for backports
<infinity> s/backports/updates/?
<Kamion> I can't actually see what would make it be there uncommented for updates
<Kamion> but I'd like to fix the backports thing anyway
<infinity> Err, we ship a backports line uncommented?
<Kamion> oh, sorry, that one's commented
<mdz> Kamion: happy to discuss whether to fix it once we can agree what the problem is ;-)
<Kamion> hmm, how about I go look at an actual test install rather than zenning it from the code
<iwj> Kamion: YHM.  It occurs to me that it may want to create a DOS Extended partition as well as a boot partition and I haven't left it enough primary slots for that.
<kiko> can somebody with a kubuntu livecd reproduce iwj's bug 46404?
<Ubugtu> Malone bug 46404 in qtparted "partitioner locked up" [Normal,Unconfirmed]  http://launchpad.net/bugs/46404
<mdz> Kamion: I'm doing the same
<Lathiat> ok yes wireless icons are much better in the update
<Kamion> iwj: yes it always wants to create a primary for / and a logical for swap
<Lathiat> altho the image changes its offset when it changes to the data receiv icon
<Riddell> kiko: that's next on my todo to look at
<Lathiat> i'll talk to dholbach 
<Lathiat> dholbach: ping?
<kiko> Riddell, cool
<iwj> Kamion: That'll be it then.  (Although there's no reason why it couldn't use my existing swap ...)
<kiko> Riddell, note also bug 46387 with the installer I think
<Ubugtu> Malone bug 46387 in ubiquity "crash going back from advanced partitioner" [Major,Unconfirmed]  http://launchpad.net/bugs/46387
<Kamion> iwj: yeah, partman is not very bright
<kiko> Riddell, is there noone else that is triaging kubuntu bugs this week with you?
<infinity> kiko: Is that the sound of you volunteering?
<Kamion> ok, in a d-i install, I have multiverse commented-out for backport
<Kamion> s
<Kamion> that's probably sort of OK
<kiko> infinity, I have access to a wide network of volunteers! 
<mdz> Kamion: so we ship commented dapper/universe, dapper-backports/{main,restricted,universe,multiverse} and dapper-security/universe
<mdz> Kamion: so dapper and dapper-security are consistent
<Kamion> mdz: d-i or ubiquity?
<Riddell> mdz: I've three things to upload if it's ok, changing guidance init script to 60, adept 2.0 which removes a debugging line that was filling .xsession and removing double menu entry for avahi-utils
<Riddell> kiko: I have my usual helpers in #kubuntu-devel
<infinity> mdz: We don't ship a commented dapper{,-security}/multiverse at all?
<Kamion> infinity: we shouldn't; can't see one here
<mdz> infinity: correct
<Kamion> (I asked about that yonks back, and was told don't)
<infinity> mdz: I mean, I'm not a huge non-free software nut, but do we need to make it that much harder for people who have no clue how to get at it?
<Kamion> infinity: it's hardly difficult with "software properties" anyway
<infinity> mdz: (sun-java, comes to mind, which we're even doing press releases about)
<mdz> infinity: yeah, the example sources.list isn't as relevant these days
<Lathiat> http://bur.st/~lathiat/sources.list.dapper
<mdz> it's a checkbox
<infinity> Kamion: I thought "software properties" only allowed you to enable/disable stuff that's already in the sources.list (ie: commented out)
<Lathiat> also the backports line inconcistently listed main/restircted universe/multivere on the same line
<Kamion> Lathiat: well, that sources.list only has multiverse for backports
<Lathiat> hrm, guess i mis-read
<Kamion> Lathiat: that's kind of intentional really, I don't want to bother with lots of commented blocks for backports
<Lathiat> still, is that what we want?
<Lathiat> Kamion: ah, right
<Lathiat> do we still want multiverse in backports?
<Kamion> I think, in fact, the sources.list you show is OK
<Kamion> I can turn off multiverse there if people think that's better
<seb128> trying edubuntu standard installation on that box, bbl
<Lathiat> im not fussed but i think for consistency it should be removed
<AlinuxOS> Thank You Guys for making Ubuntu so Amasing!  ;)
<Lathiat> would make the lines less annoyingly long too.. :)
<Lathiat> altho not quite to fit in an 8 terminal display unfortunately
<Kamion> iwj: confirmed, you have:
<Kamion> /lib/partman/automatically_partition/10resize_use_free/choices: 3 primary partitions, 0 logical partitions
<Kamion> iwj: which is not enough for a primary and an extended to put the logical in
<iwj> Kamion: Yes.
<Kamion> there are two partman enhancements needed to make this better
<Kamion> (1) make partman-auto able to reuse existing swap (though have to be careful, e.g. existing hibernated images)
<iwj> Swap that might be hibernated into should have a different signature.
<iwj> Then you'd be able to tell.
<Riddell> mdz: can I upload those?
<mjg59> It does
<mjg59> Erm. Or rather, swap that /has/ a hibernated image in does
<Kamion> (2) teach partman-auto that, while it needs to create a primary partition for / if there isn't already one, if there are already primary partitions it can just create a logical
<iwj> mjg59: No, it has the same signature when it's not being a hibernated image.
<Lathiat> swap that has a hibernated image does anyway
<mdz> Riddell: those what?
<mjg59> iwj: Indeed, but the kernel makes no distinction between these
<iwj> And you can't tell whether it might become a hibernated image in the future.
<Riddell> mdz: I've three things to upload if it's ok, changing guidance init script to 60, adept 2.0 which removes a debugging line
<Riddell>                  that was filling .xsession and removing double menu entry for avahi-utils
<Kamion> the existing recipe logic is optimised for blatting an existing disk rather than inserting a new installation into an existing one
<Lathiat> iwj: as such migth be a bad idea to use else you wont have swap if you hibernate and switch os?
<iwj> So if you reuse existing swap because this time the user happened to reboot, then next time when they hibernate the other OS and boot Ubuntu, it will refuse to swap it.
<iwj> Lathiat: Right.
<mdz> Riddell: the timing is not ideal for shuffling init scripts; what's the issue there?
<mdz> Riddell: for the other two I'm happy to review debdiffs
<Riddell> mdz: the script is at 37 and touches /usr, Keybuk tells me it should be at 60
<Kamion> my feeling is that people with multiple Linux installations tend to avoid automatic partition setup programs anyway and will pick manual partitioning, so as long as it doesn't actually destroy data, that's OK
<Riddell> mdz: http://www.ubuntu-zh.org/~freeflying/debdiff/avahi.debdiff
<Lathiat> altho probably not somethign to do now, mimgh tbe worth considering creating swap files when no swap partition is active or something
<Kamion> but I'm not sure. (2) is a more important enhancement and would solve iwj's problem too.
<mdz> Riddell: avahi is fine to upload
<infinity> Okay, just kicked off a Xubuntu destop image build for symmetry, and because janimo gives me warm fuzzies.
<Lathiat> hrm why does the "Movie Player" menu item not prefixed with the program name like every other item in the sound & video menu?
<infinity> Off to have myself a longish lunch, now.
<Lathiat> well except sound recorder, but i dont think tha thas another name
<ogra> Kamion, wow, that was fast, thanks !
<Lathiat> and i bet often people will say "use totem" etc migh tbe less confusing if it was "Totem Movie Player"
<infinity> Lathiat: I tend to agree on that point.
<Lathiat> not just the s&v menu either, most menus are prefixed with program names
<Lathiat> also is the Evolution Mail / Evolution an intentional distinction? 
<Lathiat> (Internet vs Office)
<infinity> Yeah, the one in "Office" should probably be called "Evolution Groupware" or something, though.
<Lathiat> yeh i was thinking that
<infinity> And perhaps not even visible by default.
<infinity> But it's likely too late to be changing these strings.  I'm not sure how our crazy .desktop gettext stuff works.
<Lathiat> hrm also ekiga seems to be complkaining it cant listen on the sip/h323 ports yet i have nothign else running, hrm
<Lathiat> infinity: mm true
<Kamion> ogra: just done the cdimage change too, though not deployed yet
<ogra> thanks again :)
<Nafallo> #j #ubuntu-loco
<Lathiat> i dare say tho dapper is looking really polished overall, im impressed :)
<sivang> HiddenWolf: I'll search nautilus bts upstream, maybe there is something there to just apply a patch and fix this annoying bug
<Nafallo> hmm, does the locoteam have a channel? :-)
* mvo goes for lunch
<mdz> Riddell: ok to move the guidance init script if it's only a rules change, no maintainer script changes
<mdz> Riddell: what other changes in adept 2.0?
<Riddell> mdz: http://muse.19inch.net/~jr/tmp/adept-20.diff
<mdz> Riddell: adept OK to upload
<Riddell> mdz: the guidance change is in postinst
<infinity> mdz: You can't change an init script location without changing maintainer scripts, unless you want very strange undefined behaviour.
<infinity> Riddell: In both postinst and debian/rules, I hope.
<infinity> for i in 2 3 4 5; do if [ -L /etc/rc"$i".d/SNNfoo ] ; then mv oldloc newloc; done
<infinity> Riddell: Like that?  ^^^
<Riddell> infinity: rules just installs it to /etc/init.d/ postinst makes the links with "update-rc.d displayconfig-hwprobe.py start 60 S ."
<Riddell> I just changed s/37/60/  if someone already has it installed to 37 it won't change it
<infinity> Riddell: You mean, you don't use dh_installinit, but do it by hand in postinst?
<infinity> Riddell: Anyhow, if you want it moved, you should move it, not say "some people will have it at 37, some at 60, whee"
<bddebian> Howdy Ubuntu Guru's
<Riddell> it doesn't use dh_installinit no
<Riddell> I can indeed add the for loop infinity gives but it probably won't help with mdz allowing it :)
<infinity> Riddell: Well, not much of a for loop, if you're installing in S... :)
<infinity> Riddell: Just "if [ -L /etc/rcS.d/S37guidance ] ; then mv /etc/rcS.d/S37guidance /etc/rcS.d/S60guidance; done
<infinity> s/done/fi/
<infinity> Go IRC shell.
<infinity> Or whatever the name of the script is.  But you get the idea.
* infinity goes to do that lunch thing now.
<mdz> Riddell: what I meant was that it shouldn't attempt to migrate the old symlink or any fancyness like that
<mdz> Riddell: just changing update-rc.d is OK
<Riddell> mdz: oh right, I'll just ignore infinity then
* infinity grins.
<Riddell> mdz: http://www.kubuntu.org/~jriddell/guidance.debdiff
<mdz> Riddell: 404
<Riddell> mdz: sorry, http://www.kubuntu.org/~jriddell/tmp/guidance.debdiff
<mdz> Riddell: OK to upload
<Riddell> thanks mdz 
<mdke> what does "pn" mean when it appears by the name of a program when listing with dpkg?
<Keybuk> purged, not installed
<mdke> Keybuk: thanks. seems that when you purge sendmail it doesn't remove any of the configuration files, and still tries to start stuff on booting up
<Keybuk> mdke: what does sudo dpkg --purge --pending do?
<mdke> Keybuk: nothing
<ogra> yippie, my dvd is done ...
<Keybuk> mdke: probably sendmail package bug then, hasn't cleaned up after itself
<mdke> Keybuk: yeah, i think it is. It's at #43752
<Keybuk> if they were dpkg conffiles, you'd see either pc or rc as the status
* mdke nods
<mdke> thanks
<iwj> infinity: d-i/fb=false made the install work properly.  But it's a regression from breezy, which installed just fine without.
<Lathiat> infinity: hrm, i take it its also too late to change "Totem Movie Player" ?
<mdke> Lathiat: for the menu? It's currently "Movie Player", isn't it?
<Lathiat> mdke: yes
<mdke> Lathiat: a few months back I suggested changing it in Ubuntu and upstream and got turned down on both occasions
<Lathiat> mdke: hrm
<Lathiat> mdke: to me it makes senmse, because all the other items are similar
<Lathiat> and people e.g. in supprot channels will say "use totem" when people say "what movie player do i use" etc
<Lathiat> did ubuntu/upstream give reasoning?
<mdke> upstream rely on some spurious interpretation of the HIG
<mdke> I'll find the bug
<dholbach> Lathiat: pong
<mdke> http://bugzilla.gnome.org/show_bug.cgi?id=331919 <- Lathiat 
<Ubugtu> Gnome bug 331919 in general "Change Totem's entry in the GNOME menu" [Normal,Resolved: notabug]  
<dholbach> Kinnison: pong
<Kinnison> dholbach: erm I've utterly forgotten what I pinged you about
* Kinnison looks sheepish
<dholbach> Kinnison: something about icons?
<Lathiat> dholbach: let me find the bug i just filed
<Kinnison> dholbach: Erm, oh yeah, the g-p-m icon in the about is apparently wrong
<dholbach> Kinnison: seb128 pointed you and Lathiat to me about icons
<Kinnison> Oh and that, yes, bug lathiat
<dholbach> Kinnison: yes it is, i'll try to make that change happen as well - got a bug about it already - thanks.
<Lathiat> hrm why does the g-p-m icon disappear when the battery is full
<Lathiat> that seems like a silly default
<Kinnison> Lathiat: because you have it set to show the icon only when charging or discharging
<mdke> yes, I don't think that is the default
<Lathiat> https://launchpad.net/distros/ubuntu/+source/ubuntu-artwork/+bug/46752
<Ubugtu> Malone bug 46752 in ubuntu-artwork "network monitor icon changes offset when activity occurs" [Normal,Unconfirmed]  
<Lathiat> i havent touched a thing
<Lathiat> fresh install
<dholbach> Lathiat: that bug is already filed
<mdke> Kinnison: is that still the default?
<Lathiat> dholbach: oh? i couldnt see it
<Lathiat> i have opened the prefs dialog to gpm, but didnt change anything
<dholbach> Lathiat: duplicate of bug 45658
<ogra> Kinnison, dholbach, mind fixing bug 45536 alongside (whoever fixes the icon prob of you two) ?
<Ubugtu> Malone bug 45658 in ubuntu-artwork "Human netstatus icone" [Normal,Confirmed]  http://launchpad.net/bugs/45658
<Ubugtu> Malone bug 45536 in gnome-power-manager "Shutdown, but logoff" [Normal,Fix released]  http://launchpad.net/bugs/45536
<Kinnison> mdke: yes, and no I'm *NOT* talking about it
<Lathiat> eh thats a terrible title :)
<dholbach> Lathiat: i agree
<dholbach> ogra: thanks
<mdke> Kinnison: ok. Is there a bug report which explains the reasons for that choice of default?
<dholbach> Kinnison: mind if I add that dependency?
<Kinnison> ogra: that bug is very odd
<Kinnison> dholbach: Go for it
* Kinnison is amazed it started up at all without hal present
<dholbach> Kinnison: rock on
<ogra> Kinnison, but the dep should be there, seb128 is right :)
<dholbach> of course is seb128 right :-p
<ogra> hehe, yes, indeed i wouldnt doubt that
* dholbach wears the seb128 fanboy T-Shirt
* seb128 hugs dholbach
<dholbach> :-)
<ogra> can you bring soem to paris ? 
<ogra> *some
<sivang> dholbach: I also want one :)
<seb128> edubuntu CD hates me
<seb128> everytime I do a new rsync it seems to download the whole CD again
<pygi> sivang, I need bzr repo for HUB
<ogra> sivang, there is a bug in bzrk, it doesnt show the diff window 
<ogra> sivang, if youre after fixing dapper bugs ;)
<sivang> ogra: hmm, does it crash or something? or just not show it?
<ogra> sivang, you can click on the little icon that should bring up the diff window and get a traceback test yourself :) ... its not merely critical, but youre already in that code so i tought you might be intrested to fix it ;)
<ogra> seb128, but you noted that the isos are not named alternate and desktop ?
<iwj> I take it I'm not mistaken when I think that DapperUpgrades doesn't really apply to kubuntu.  I'll use DapperReleaseNotes/Kubuntu instead.
<moberg> JaneW: how does it go with the mentors?
<pygi> moberg, hm, what do you mean?
<Riddell> iwj: you're right, it doesn't
<moberg> "<JaneW> moberg: we had some duplication issues just before the announcements were made, so there was some frantic shuffling, BUT the mentor assignment function is currently frozen, so I am waiting for google to give me access again"
<seb128> ogra: I do use "rsync -azvP cdimage.ubuntu.com::cdimage/edubuntu/daily/current/dapper-install-amd64.iso dapper-install-edubuntu-amd64.iso"
<sivang> ogra: sure, I will take a look then :)
<ogra> hmm,k
<sivang> pygi: just a sec
<ogra> seb128, works for me 
<seb128> ogra: I just tried an install with the image from the 24th which didn't work (kino not installable)
<moberg> pygi: i have not been assigned any mentor yet :/
<iwj> Riddell: Right.  I've updated Testing/Current's table.
<ogra> seb128, amd64 was oversized until 24th
<seb128> ogra: waiting for the rsync to be done to try again ;)
<sivang> pygi: https://launchpad.net/people/sivan/+branch/hubackup/devel-main
<ogra> dapper-live-amd64.iso
<ogra>    688644096 100%    3.76MB/s    0:02:54  (1, 100.0% of 1)
<ogra> wroks fine here 
<seb128> ogra: BTW why do you use the ugly xorg cursor? to spare the disk space of a nice cursor theme?
<ogra> seb128, the cursor was set in Xorg since warty to jimmac/Human as default, i didnt know we'd move that into the artwork packages
<Riddell> iwj: thanks
<Riddell> ogra: it's never been in xorg
<pygi> simira, thanks :)
<pygi> moberg, pm please
<ogra> Riddell, so why did it work for me without -artwork installed before ? and now i need -artwork ? 
<Riddell> ogra: dunno, but I've always had to ship a kubuntu copy of the cursor theme
<ogra> hmm
<seb128> ogra: maybe you were using a cursor from industrial or xcursor-themes by example?
<ogra> hmm
<ogra> we never used a specific cursor in edubuntu 
<ogra> it was always there by default 
<ogra> i'll look into it 
<theine> Hi, I heard of quite a few reports about Espresso's buggy behaviour. Is there any substance to that? I haven't tried it myself
<Riddell> theine: try it an find out?
<Riddell> theine: it's call ubiquity now
<fabbione> theine: not anymore.
<pygi> moberg, you around still?
<pygi> sivang, just pulling the source
<moberg> pygi: yepp
<pygi> moberg, well, you reading my PM?
<moberg> pygi: yes, and i've replied :)
<pygi> ergh, wait
<pygi> moberg, try responding again :-/
<theine> Riddell: well, in case it works for me, i still don't have very good statistics...
<theine> fabbione: that's nice to know
<fabbione> theine: well like any new development project it had bugs.. also bad ones. Nothing to hide. They have been addressed and fixed.
<fabbione> theine: but there will be always one true test.. your :)
<fabbione> theine: Kamion did an amazing job there to get them sorted and killed.
<fabbione> theine: but rumors are more difficult than bugs to kill
<Kamion> theine: what fabbione said. I've certainly had a lot of bug reports (very many of them duplicates, incidentally), but I only want to hear about real bugs, not rumours of bugs
<theine> Kamion: yes, of course
<Kamion> and yes, it was being done on a very tight schedule so the version in especially the beta release was pretty ropey
<pygi> moberg, just join #socdiss
<theine> Anyway, I'm glad you guys sorted out the ubiquity bugs. Great work, I really appreciate it.
<moberg> pygi: done
<infinity> iwj: It's a known regression on a very small subset of hardware, while we've fixed the framebuffer for a much larger subset of other hardware. :/
<infinity> iwj: I'd like to get it perfect for everyone (and probably can for edgy), but I need access to hardware like yours, and I need to not do it 5 days before release. :)
<sivang> pygi: I just upgraded to knits, so if you branched 30 minutes ago, you might using the old format.
<pygi> sivang, ah,ok
<sivang> pygi: did you have trouble branching from me?
<iwj> infinity: Sure.  I mean, it doesn't hugely bother me but I thought you should know.
<pygi> sivang, it stopped at like 30% or something :P
<moberg> Im in need of a mentor for my SoC project. "Applications to improve Ubuntu", the task that I has in mind is to write an application, "Desktop panel look-and-feel mode changer". But i need a mentor to get started
<sivang> pygi: crap, sorry, this is probably because I upgraded to knits during that time
<sivang> pygi: just rm -rf and bzr branch again
<pygi> sivang, just doing now :)
<neuralis> moberg_: vuntz said he'd be ok with mentoring you.
<iwj> Riddell: Is it really your considered opinion that editing the sources.list with adept is easier than (say) vi, ed, or cat ?
<moberg_> neuralis: great!
<vuntz> moberg_: hi :-)
<moberg_> vuntz: hi there :)
<Riddell> iwj: for GUI type people yes
<iwj> You must be joking.
<moberg_> vuntz: have you read my application?
<vuntz> moberg_: in fact, I'm wondering if seb128 would have more time than me :-)
<vuntz> moberg_: yep
<iwj> It's really freaky and keeps undoing stuff and the instructions on ReleaseNotes are IMO hopeless.
<vuntz> I guess I can help mentoring, but I might be a bit short in time. Maybe co-mentoring with seb128 would be the best solution?
<KaiL> .torrent fie for ubuntu-6.06-rc-desktop-i386.iso broken?
* mvo points iwj to his upgrade tools and runs
<seb128> vuntz: I would be happy by co-mentoring, I'll have a month of June busy
<seb128> vuntz: 1 week of VAC, 1 week of summit and GUADEC ....
<pygi> vuntz, then please do talk with JaneW about assigning you
<iwj> Riddell: `will allow you to change the distribution from breezy to dapper'.  Ie, on each line, click and click again until you get to edit the `distribution' box, and then edit `breezy' into `dapper' and then _press return_ (or it discards your change) and go on to the next line ...
<vuntz> pygi: I have a query opened with JaneW, but she's probably away right now :-)
<iwj> mvo: I'm supposed to be testing what the user is going to do.  The user is going to follow the release notes.
<JaneW> vuntz: hello, ping
<vuntz> well, she's here now :-)
<pygi> vuntz, see? :)
<vuntz> pygi: it's because of your magic!
<JaneW> heh
<iwj> mvo: But, you have upgrade tools for kubuntu ?
<pygi> sivang, is your bzr archive pullable?
<pygi> I got some errors :-/
<JaneW> vuntz:  will you mentor http://code.google.com/soc/ubuntu/app.html?csaid=moberg.peter%40gmail.com%3Af237bdd2%3Aa4b48a6d please? The student is moberg_ , and he wants communicate with his mentor.
<iwj> Oh and don't forget to click `apply' before `close' or it just discards your changes.
<mvo> iwj: *cough* it will work fine on kubuntu - but its not the official and blessed way there
<iwj> mvo: Maybe it should be.
<vuntz> JaneW: looks like seb128 and I just decided to co-mentor moberg_ :-)
<neuralis> mvo: would you be okay with mentoring the zeroconf apt proxy?
<vuntz> JaneW: so you can put either seb128 or me as mentor in the google webapp
<neuralis> mvo: you had expressed interest in the comments.
<pygi> neuralis, he also has one higher priority project
<dieman> https://launchpad.net/distros/ubuntu/+source/manpages/+bug/6416 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348028 are depressing to stare at.
<Ubugtu> Malone bug 6416 in manpages "Symlink to missing manpage is installed." [Minor,Confirmed]  
<mvo> neuralis: I'm certainly interessted, I mentor someone else though. I would still be happy to give input. AFAIK doko voiced some interesst
<infinity> Okay, guys, I'm exhausted from the marathon session yesterday, and working a fair chunk of today.  I'm off to bed.
<JaneW> vuntz: are you happy for me to put you are the 'official' mentor (for admin purposes) since seb128 has one already?
<iwj> infinity: Sleep well.
<sivang> pygi: it is
<JaneW> vuntz: how you actually divide the responsibility is up to you
<neuralis> infinity: 'night, get some sleep.
<sivang> pygi: what errors did you get?
<vuntz> JaneW: it's not important to me (I'm already (co-)mentoring two projects for GNOME)
<JaneW> moberg_: congrats, you have 2 mentors :)
<moberg_> JaneW: :)
<mvo> iwj: I'm not sure if Riddell would be happy about it, it drag in some gtk packages - OTOH the source is designed to make new frontends easy, for edgy we can probably get a qt version
<vuntz> JaneW: so you can take this for a "yes" if it makes your life easier ;-)
<pygi> neuralis, can you find someone else for that?
<pygi> we also need admin for "ubuntu welcome center"
<pygi> sivang, sent you in pm
<mvo> neuralis: this is not your application, is it?
<JaneW> vuntz: excellent thanks, not I just need google to open the interface so I can actually do the assigning
<neuralis> mvo: ha, no. :)
<infinity> Keybuk: Did we ever confirm that all (or some) of the new desktop CDs seem happy?
<seb128> moberg_: probably better to hang on #ubuntu-desktop than here to discuss desktop changes to do ;)
<pygi> sivang, I'll try again :)
<Riddell> a port of the upgrade tool to kubuntu is in my edgy plans
<sivang> pygi: okay, I will try myself from scratch
<neuralis> pygi: mvo mentioned doko, could you ping him about it? if no one can be found, i'm open to the possibility of mentoring it myself, and consulting with mvo as we go along.
<Keybuk> infinity: I'm still rsyncing them
<Keybuk> was going to a burn-them-all-and-test-them-all run
<Keybuk> seeing as I have all three arches in front of me now
<pygi> neuralis, I can surely try
<mvo> neuralis: I'm happy to co-mentor, I like the idea, but I think it needs some serious thought about the design
<Keybuk> about ~1hr I guess
<infinity> Keybuk: Ahh, fair enough.  Yell at me in backscroll if something seems goofy about them, I'm going to go catch a nap longer than 2 hours this time. :/
<pygi> anyone here interested in mentoring "ubuntu welcome center"?
<seb128> vuntz?
<sivang> pygi: I am , what does it invlove?
* seb128 runs :p
* vuntz slaps seb128
<pygi> sivang, you can see it here
<pygi> http://code.google.com/soc/ubuntu/app.html?csaid=ghee22%40gmail.com%3A19ff4490%3Ad5c0903d
* sivang pokes
<seb128> heh
<pygi> btw. sivang it seems that bzr is pulling OK now
<pygi> we'll see tho
<sivang> pygi: cool
<Kamion> moberg_: BTW for your first application, grub-reboot is the tool you want
<neuralis> mvo: yes, agreed. it's very easy to come up with a completely broken design for it.
<Kamion> moberg_: may not quite work in dapper - I don't remember for sure - but it should definitely work once we merge from Debian early edgy
<Kamion> much better than futzing with menu.lst
<pygi> sivang, if you are interested in mentoring that, just poke JaneW about it
<JaneW> sivang: you want Ubuntu Welcome Center  ?
<sfllaw> Kamion: Of course.
<fabbione> zakame: ping?
<sivang> JaneW: well, if nobody else want to love it, I will, but having a co-mentor in fallback mode when I require specific things could be good.
<sivang> JaneW: but I am interested, yes.
* Kamion scratches his head furiously at bug 46743
<Ubugtu> Malone bug 46743 in ubiquity "Installer crashed during language pack installation" [Normal,Unconfirmed]  http://launchpad.net/bugs/46743
<sivang> JaneW: also, I'm short of some t-shirts :p
<JaneW> sivang: we may have another plan
<JaneW> we have an unallocated official mentor...
<pygi> sivang, I'll get three...need one? :)
<sivang> heh
<sivang> JaneW: no prob
<sivang> pygi: nah, 'sokay , was joking.
<sivang> pygi: if I don't help a SoC applicant I would not feel comfortable to wear one :p
<Kamion> OH
<pygi> sivang, :)
<Kamion> mdz: bug 46743 is because g-s-t offers an option to install NTP, which just uses synaptic to install them on the spot - but that fails because the debconf db is locked
<Ubugtu> Malone bug 46743 in ubiquity "Installer crashed during language pack installation" [Normal,Unconfirmed]  http://launchpad.net/bugs/46743
<Kamion> (by ubiquity)
<pygi> sivang, you'll be "mentoring" that Annant guy anyway :)
<mdz> Kamion: I don't see what we can do about it
<mdz> they could also open Synaptic separately and then try to run Ubiquity; I assume that'd fail too
<Kamion> yeah, but this is an option presented (indirectly) by ubiquity
<Kamion> actually it might be possible to make the installation work if file descriptors were connected up properly, but not really for dapper
<Kamion> my other thought is to somehow catch the invocation of synaptic by g-s-t (e.g. by munging its $PATH and installing a little wrapper script) and queue the packages for installation instead
<Kamion> I would ignore it for dapper if it wasn't that it fucks up ubiquity later
<Kamion> in a highly non-intuitively-obvious way
<mdz> sfllaw: how is the fire hose tasting today?
<mdz> Kamion: I'd say we should invoke g-s-t in a way which causes it not to offer the option
<sfllaw> mdz: The water is foul.
<doko> neuralis: I did talk with JaneW about mentoring apt-proxy
<mvo> Kamion: what about adding a option to time-admin "--installer-mode" and that will hide the install-ntp button?
<Kamion> mdz: I've been trying to figure out how to do that. It apparently chooses whether to offer the option based on whether synaptic is on $PATH.
<Kamion> mvo: that would work, although an environment variable might be simpler
<Kamion> (in patch volume, if nothing else)
<mvo> Kamion: yeah, even better
<mdz> sfllaw: anything I should know about?
<mvo> Kamion: I can do that quickly if you want
<Kamion> perhaps $NO_INSTALL_NTP?
<nuzzy> any talk of getting CUPS 1.2.1 in?
<seb128> no
<Kamion> mvo: yes, please
<mvo> Kamion: GST_NO_INSTALL_NTP ?
<mdz> Kamion: are the current amd64 DVDs built with fixed squashfses?
<Kamion> mvo: works for me
<\sh> did anybody work with SE Linux Kernel feature and ubuntu server?
<Kamion> mdz: No. I'll trigger a build now.
<mdz> Kamion: thanks
<Kamion> mvo: I've assigned half of 46743 to you, then
<infinity> \sh: We didn't concentrate on any SELinux stuff for this release, no.  I suspect it'll get looked at a bit more in edgy.
<mvo> Kamion: done, testing it now 
<\sh> infinity: ok..then you get some testresults next week....our security guy is testing now ubuntu server kernel with se linux and the utilities :)
<\sh> our suse consultant is getting nervous right now
<infinity> \sh: Err, we don't enable SEL in the Ubuntu kernels at all...
<Keybuk> I thought we did
<tseng> we did, once
<\sh>  [*]    NSA SELinux Support    
<mdz> infinity: we certainly do
<\sh> -23
<Keybuk> quest scott% grep SELINUX /boot/config-2.6.15-23-amd64-k8
<Keybuk> CONFIG_SECURITY_SELINUX=y
<mdz> that is, we build in the support but don't turn it on by default
<tseng> it is totally passive by default.
<Keybuk> you just have to boot with selinux=on or something, right?
<mdz> yes
<Keybuk> tseng: like infinity then ;)
<tseng> the kernel command line can give you various levels of enforcement
<infinity> mdz: Oh, so we do.  I just never noticed until I grepped the config.
<infinity> (Could have something to do with it being disabled by default)
<tseng> the policies for debian have never really been worked on enough
<\sh> at least we can enable it from the boot loader which is enough for us right now...
<tseng> \sh: you should help flesh out the base policies :)
<iwj> Ah, lovely, themes turning up now, after the last moment of course.
<mdz> iwj: you have no idea how deep that particular swamp goes
<\sh> tseng: if we can push ubuntu for this company ubuntu will get more SEL love 
<ajmitch> the policies are being worked on for debian, and I was hoping to do something about it for edgy..
<ajmitch> since it just wasn't useful working on the reference policy for dapper
* hunger sees lots of "Use of uninitialized value in print at /var/lib/defome/scripts/gs.defoma line 108" when upgrading from breezy to dapper.
<infinity> hunger: We know.
<hunger> Is that known? Well, it is not releasecritical anyway.
<infinity> iwj: I guess you never dug to the bottom of that one?
* sivang got used to ignoring these.
<infinity> hunger: It's harmless, just ugly.
<infinity> hunger: And has been happening for eons.
<iwj> infinity: No.
<\sh> ok..travelling home now...cu later this night :)
<hunger> infinity: Strange... I have not noticed it in a long time. Must have gotten used to it:-)
<iwj> infinity: It's ages ago now but it was quite deep (and not always reproducible) and since it's really just cosmetic I thought I'd leave it.
<infinity> iwj: Yeah, at this point, it's too late, but cosmetic counts for a lot, so I would like to see it solved for edgy, maybe.
* bddebian will "fix" it ;-)
<hunger> infinity: The messed up shutdown graphics in kubuntu are really ugly and way more visible:-( I assume people are looking into that though.
<infinity> iwj: Cosmetic counts for A) people wanting Ubuntu to be as shiny as possible, but also B) the 8000 people who report this bug in both Debian and Ubuntu becuase OMG, MY SYSTEM MUST BE BROKEN!
<infinity> hunger: I've not even booted a kubuntu CD, but I've heard talk of this, yes.  I should check it out after I sleep.
<Riddell> hunger: on which CD?
<hunger> Riddell: I have a current dapper updated all the way from breezy.
<bddebian> I have a kubuntu install CD I can try if you want?
<iwj> mdz: Oh, it turns out I was wrong.  I've just found the .upload file.  But the package isn't in the archive.
<hunger> Riddell: I have had this problem (either messed up graphics or blue text) ever since you introduced the graphical shutdown.
<mdz> iwj: it's not in the queue either
<hunger> Riddell: Actually I saw the proper graphics a couple of times, but mostly it is a huge mess.
<Kamion> iwj: what was the package name? I'll check the logs
<hunger> Riddell: It does work perfectly once the splash-thingy is restarted during the shutdown process.
<Kamion> iwj: (and date of upload, if you can)
<iwj> ubuntu-php-firefox-human_0.4.1_source.changes
<iwj> upload.ubuntu.com Thu May 18 16:15:02 2006
<Keybuk> ok
<Keybuk> some wise guy changed the behaviour of snprintf
<mdz> Keybuk: eh?
<Keybuk> mdz: snprintf used to return -1 if size wasn't big enough
<Keybuk> now it seems to return "the length of the string you need to allocate"
<Kamion> iwj: I think you forgot to sign it, and a known LP bug meant that you didn't get told.
<Kamion> 15:15:06 DEBUG   Verifying signature on ubuntu-php-firefox-human_0.4.1_source.changes
<Kamion> 15:15:06 DEBUG   UploadError made it out of .process()
<Kamion>  -> http://librarian.launchpad.net/2732104/xNqik8vaaoIanbEQPuBHrMqWhqz.txt (GPG verification of ubuntu-php-firefox-human_0.4.1_source.changes failed: No data)
<mdz> Keybuk: I think it's always been that way in glibc
<mdz> though it varies elsewhere
<Kamion> iwj: can you sign and reupload?
<Keybuk> mdz: glibc 2.1 it changed, apparently
<iwj> Uh, so I didn't.  I blame cvs-buildpackage.
<mdz> Keybuk: i.e. before the dawn of time
<desrt> mjg59; i want to be elite like you
<desrt> mjg59; how are you so cool?
<iwj> I need to get the latest version anyway.
<Keybuk> mdz: hey, I started on Linux in the days before shadow passwords and when we still had the BSD libc ;)
<Keybuk> iwj still has the BSD libc on this laptop, iirc ;)
<desrt> mjg59; specifically, know any good techniques for finding out what is happening in the wee moments after my macbook wakes up?
<mvo> Kamion: ok to upload g-s-t now? "export GST_NO_INSTALL_NTP=1" will work now
<iwj> Keybuk: SuSv3 specifies the new (sane) behaviour.  http://www.opengroup.org/onlinepubs/009695399/functions/snprintf.html
<iwj> Urr, actually, no.
<Keybuk> iwj: C99 does
<iwj> They fail to specify what happens if your buffer is too small but nonzero.
<Keybuk> C99 has nice things actually
<Keybuk> "If n is zero, nothing is written, and s may be a null pointer."
<mdz> mvo: ping?
<mvo> mdz: pong
<Kamion> mvo: yes please
<Kamion> +        time_admin_env['GST_NO_INSTALL_NTP']  = '1'
<mjg59> desrt: What are you running?
<desrt> mjg59; dapper on a spiffy new white macbook
<sivang> ogra: I have a patch :)
<mjg59> Using boot camp?
<sivang> ogra: re: bzrk
<desrt> using the legacy booting capability of the new firmware
<mjg59> Right
<mjg59> Erm
<mjg59> What currently happens?
<desrt> i've tried the usual suspects
<desrt> ie: close down X, remove drivers, echo 3 into the sleep file manually
<ogra> sivang, great
<desrt> basically, it sleeps just fine
<desrt> but when it wakes up it's dead
<mjg59> acpi_sleep=s3_bios and removing the "quiet" boot option may result in some output on resume
<sivang> ogra: will upload shortly
<ogra> thanks :)
<sivang> ogra: you're welcome!
<desrt> screen fails to come back and even the capslock is screwed
<desrt> k.  lemme try that.
* desrt needs to install grub >:|
<mjg59> desrt: Given that grub won't work, I wouldn't recommend it
<desrt> oh.  what's wrong with it?
<mjg59> Uses unimplemented BIOS functions
<desrt> ah
<desrt> i can just toss that acpi_sleep argument at the end of the lilo line, right?
<desrt> like 'dapper acpi_sleep=s3_bios'
<mjg59> Yeah
<mjg59> But you need to remove "quiet" as well
* mjg59 goes for a meeting
<desrt> thx for the tip.
<hunger> mjg59: Do you know of any progress on the shutdown-after-resume issue on some thinkpads?
* mvo needs more RAM
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.0.8.diff <- OK to upload?
<Kamion> glade changes are tiny and tested, rest should be obvious
<mvo> urgh, I just uploaded without puting a debdiff up (looked at the diff beforehand of course)
<iwj> Oh, bloody hell, Frank Schoep's crazy box has vanished entirely now.
<highvoltage> mvo: who doesn't? :)
<Kamion> mvo: I'd have expected a one- or two-liner anyway
<Kamion> just add getenv("GST_NO_INSTALL_NTP") to the relevant if
<mvo> Kamion: yes, that is what I did
<Kamion> good
<desrt> bah.  no love.
<pitti> hi
<desrt> good morning
<pitti> congrats to the RC! So you guys could fix the amd64 sqashfs issue?
<pitti> hi desrt 
<pygi> hello pitti, and congrats on mentoring :)
<seb128> hey pitti
<mdz> Kamion: did we find any safe workaround for the button sensitivity/focus issue?
<pitti> seb128: greetings from Switzerland!
* desrt wonders if the -imac kernel can sleep
<sivang> pitti: you in swiss ? :)
<thom> pitti: read scott's changelog for squashfs . it's pretty funny
<pitti> sivang: yes, visiting a friend of mine and Zurich
<seb128> pitti: how is Switzerland? enjoying it? ;)
* mvo waves to pitti
<sivang> pitti: oh cool!
* sivang hugs pitti 
<mvo> pitti: don't forget to buy some chocolate 
<mvo> and cheese
* mvo ponders what else switzerland is famous for
<pygi> mvo, watches :)
<thom> mountains, but they're tricky to buy
<pygi> clocks :-P
<pygi> thom, lol :)
<pitti> thom: lol :) not that it would tell me what the bug was, but it's nice to read
<pitti> mvo: Cheese, mountains, Victorinox Swiss Army Knifes
<seb128> thom: if you can go to space you can probably buy a mountain too :p
<thom> seb128: true true. although taking it home in one piece might be entertaining
<mdz> Kamion: OK to upload
<seb128> thom: right ;)
<iwj> Woohoo.  I upgraded kubuntu breezy -> dapper and now it's completely hosed.
<iwj> I'll see if it's any better after a reboot.
<seb128> mdz: did you read that mail about poppler issue?
<seb128> opinion on it?
<mdz> seb128: no
<pitti> Keybuk: *hug*
<mdz> seb128: where?
<seb128> mdz: the mail is on ubuntu-devel
<seb128> patch from bug #24970 is an ABI change it looks like
<Ubugtu> Malone bug 24970 in poppler "evince crashes when highlighting text at line end" [Normal,Fix released]  http://launchpad.net/bugs/24970
<seb128> https://launchpad.net/distros/ubuntu/+source/tetex-base/+bug/42075
<Ubugtu> Malone bug 42075 in tetex-base "includegraphics fails" [Normal,Confirmed]  
<seb128> is due to it
<Riddell> iwj: you'll need to restart kde
* mvo gets the impression that iwj is not a big fan of modern gui environments
<pitti> seb128: argh, did you see this poppler shlibs bump email?
<seb128> pitti: cf what I'm saying on that chan
<pitti> seb128: oh, right, you are discussing it right now
<pitti> sorry
<seb128> np
<mdz> seb128: looks like it should probably be reverted, but this can wait until after release
<pitti> seb128: revert patch or rebuild packages?
<iwj> Riddell: Why do the instructions not say to do so ?
<seb128> pitti: revert patch and then rebuild packages?
<pitti> seb128: why both?
<iwj> Riddell: And I quickly figured out I needed to restart it but when I tried I got a semiinfinite series of dialogue boxes telling me that various crap was hopelessed buggered.  Segfaults all round.
<mdz> pitti: if packages were built with the changed libpoppler they might need to be rebuilt
<seb128> pitti: because if the ABI change we probably want to revert it, no?
<pitti> seb128: TBH, rebuilding the rdepends seems safer to me
<pitti> hm, as you wish
<pitti> mdz: right, that
<iwj> How can I file an RC bug against the upgrade instructions ?
<seb128> I don't really wish anything, I'm not sure of what is the best
<pitti> 's why I favor rebuilding rdepends
<seb128> but as pointed by mdz we need to rebuild either way
<zul> pitti: there is a security fix for the phpmyadmin ill attach a debdiff with the patches to the bug is that ok or should i just upload it?
<mdz> pitti: how many packages are affected in each case?
<seb128> pitti: but we make us binary incompatible with rest of the world then?
<iwj> I mean, has anyone actually _tried_ these upgrade instructions ?  Because new users who get a bit queasy because of lots of warnings from defoma are going to be completely freaked by the kubuntu breezy->dapper experiences I've just had.
<seb128> mdz: to main, probably like 4 or 5
<mdz> seb128: in both cases?
<seb128> mdz: no, if we don't roll the patch out it looks like only tetex-bin needs a rebuild
<pitti> seb128: is that an issue? if so, well, then we can revert the bug fix, too, but I wouldn't be so happy about reintroducing a bug
<seb128> right
<pitti> mdz: around 6
<ogra> iwj, i have some upgrade tests on my todo (at least for edubuntu) since i'm listed for them in sfllaw's table on Testing/Current
<seb128> I would just rebuild tetex-bin then
<mdz> seb128: everything else has already been built with the new lib?
<seb128> <iegary> seb128: all the packages except tetex-bin (not sure about kdegraphics) have been built since the change
<mdz> ah
<iwj> mvo: I'm not particularly a fan of the modern GUI for myself but I can see why some people would like it.  What I'm really not a fan of is broken stuff !
<iwj> ogra: Right.  Err, do you mean `I haven't tried it so it may be rough' which is fine or `I would like you to try it and rant at me about the bugs' ? :-)(
<pitti> zul: go ahead, I'll be away again soonish, and I can't do much here anyway
<iwj> s/\($//
<seb128> mdz: should we do a rebuild upload for tetex-bin now?
<zul> pitti: ok ill do an upload tonight when i get home
<ogra> iwj, that meant "i'll try them as well and i can tell you later if it works for ubuntu or edubuntu"
<iwj> ogra: Ah, right.
<iwj> I was trying the kubuntu thing because my name was in the box saying I should try it :-).
<ogra> yeah :)
<Kamion> mdz: I haven't revisited the button sensitivity/focus issue since yesterday
<Kamion> mdz: I'd like to sort it out if possible, though. sabdfl wants me to upload on Monday with updated translations ...
<iwj> mdz: That theme package is FTBFS :-(.  Do you want me to upload it anyway so it's in the archive where we can edit it ?
<iwj> (I'm looking into it to try to see if there's an obvious quick fix.)
<Kamion> Riddell: I'm also expecting a patch from you at some point to turn off the KDE media notifier while running ubiquity; given that Monday's a bank holiday, are you going to be able to get that to me before then?
<pitti> bye!
<iwj> ogra: I've just been doing _k_ubuntu.  I'll probably try a few others at some point but perhaps not today.
<ogra> yup
<KaiL> eeks - afaik killed Partitions with graphical installer?!
<mjg59> KaiL: In English?
<KaiL> mjg59, on heise.de somebody writes about a destroyed NTRFS partition with the graphical installer - not beta1, RC :(
<iwj> mdz: No, I don't see a quick fix for this themes thing but I don't really know what's been going on.  Obviously some stuff has moved.
<KaiL> http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=10498744&forum_id=98195 - not really that much details...
<ogra> KaiL, i dont have a heise account anymore, if you have one, please ask him to file a bug
<desrt> mjg59; no love on the commandline option
<mjg59> desrt: No debug love for you, then
<desrt> sucks, huh?
<mjg59> Yup
<desrt> i have another sad story
<desrt> elilo loads and says 'Loading initrd.img...done'[newline]  and then locks up
<desrt> not insanely important since legacy booting is fine but still sort of weird
<desrt> this one should be easier to diagnose, though
<KaiL> ogra, got blocked for too much trolling? ;)
<ogra> KaiL, nope, stopped posting ~2 years ago because that forum is simply pointless
<KaiL> today it's better that pro-linux (where they only have anti-gnome-rant)
<desrt> mjg59; any suggestions for next step with sleep?
<desrt> mjg59; oh... one thing i should mention... with the s3_bios option, i have to echo 3 into the sleep file twice... the first time, it gets ignored
<_ion> http://johan.kiviniemi.name/pictures/screenshots/amarok-tool
<_ion> :-)
<mdz> iwj: not much point in uploading it if it doesn't build
<mdz> iwj: is the failure in Frank's PHP magic or in the packaging?
<mdz> iwj: if the former, please ask him to see if he can get it building again
<iwj> mdz: The failure is that it can't find some icons that it's trying to slurp from the input themes.  Presumably those input themes have stopped shipping those files for some reason.
<iwj> Apparently this happened once before.
<iwj> Who is responsible for packages like ubuntu-artwork, tangerine-icon-theme, tango-icon-theme and where can I find the discussions where they decide to change things ?
<Burgwork> mvo, you around?
<seb128> iwj: dholbach
<jsgotangco> dholbach
<iwj> I've been trying to keep track of ubuntu-art but it's very noisy if you don't much like discussing the merits of icons :-).
<jsgotangco> heh
<iwj> seb128, jsgotangco: ta.
<seb128> np
<iwj> dholbach: ping?
<dholbach> iwj: pong
<iwj> Hello.  We're discussing (^) the FTBFS of the new ff theme package from Frank Schoep.
<iwj> It seems some files have moved or been removed.  Eg, /usr/share/icons/Human/scalable/actions/dialog-apply.svg (not sure if that one was the one it found before, but some file like that).
<dholbach> iwj: do you have a buildlog somewhere?
<mvo> Burgwork: yes
<dholbach> /usr/share/icons/Human/scalable/actions/dialog-apply.svg has never existed to the best of my knowledge
<iwj> dholbach: Yes, just a mo ...
<dholbach> only /usr/share/icons/Human/scalable/{filesystems,devices}/* yes, everything else, no
<dholbach> (that's for scalable ones)
<iwj> http://www.chiark.greenend.org.uk/~ian/d/buildlog
<dholbach> merci, looking
<dholbach> and 21x21 never existed as well
<dholbach> 16x16, 24x24, 32x32, 48x48 for Human, yes
<iwj> dholbach: It tries various things for each icon and picks the first one that exists.
<dholbach> (oh well and add scalable)
<iwj> If you look at the bottom of that log, you see the files it tries [0] ..[7] .  At least one of those files must have existed previously, I think.
<dholbach> tango-icon-theme-common: /usr/share/icons/Tango/scalable/actions/dialog-apply.svg
<dholbach> and I'll make sure there's a Human variant as well
<iwj> Oh, has tango-icon-theme been split ?
<dholbach> in fact it's a split off of tangerine-icon-theme
<sfllaw> So... wvdial tickles a problem in the ltmodem driver.
<sfllaw> Which hardlocks the machine.
<iwj> I've got  Build-Depends: ubuntu-artwork, tangerine-icon-theme, tango-icon-theme, [image processing software] 
<dholbach> to have icons that are common to both: tango-icon-theme and tangerine-icon-theme
<dholbach> Human does not have an icon for that metaphor
<dholbach> and the checks for 21x21 should be either 22x22 (tango*-icons) or 24x24 (Human)
<iwj> Is there somewhere where this kind of thing is discussed that Frank and I should be watching ?
<iwj> dholbach: I think he's trying to make 21x21 icons.  I don't know why.
<iwj> Is that wrong ?
<dholbach> then he has to rescale them, that's fine with me - I'm just saying that he won't find any of those in the icon themes we ship
<iwj> I know nothing about icons; I got involved via firefox and made Frank's thing into a Debian-format source package.
<dholbach> there are bzr branches for tangerine and tango-common
<dholbach> but that's the most I can offer
<iwj> dholbach: IC.  I don't think that matters.
<dholbach> I merely packaged them.
<iwj> His script is indeed set up to rescale things if it doesn't find the size it wanted.
<iwj> That's why it looks for .png first and then .svg for each one.
<dholbach> Right.
<iwj> OK.  That seems to have built.  I'll add the build-dependency on tango-icon-theme-common and upload it.
<dholbach> Excellent.
<iwj> Thanks muchly.
<dholbach> If there are other breakages, please tell me.
<dholbach> I'm happy to double check that none of the icons went AWOL.
<dholbach> (which wouldn't surprise me given the fluctuation)
<iwj> dholbach: OK.  I'll have a .deb shortly and you can check it for me ?
<dholbach> I can try.
<iwj> dholbach: http://www.chiark.greenend.org.uk/~ian/d/firefox-themes-ubuntu_0.4.2_all.deb
<iwj> mdz: dholbach helpfully told me what the problem was and it's uploading now.
<iwj> mdz: now in NEW
<sfllaw> BenC: Ping.
<dholbach> mdz: looks good so far.
<dholbach> iwj: looks good so far.
<iwj> Thanks.
<Kamion> iwj: what a weird source stanza in debian/control. I'm not sure I've ever seen one only three lines long before.
<Kamion> (no Section, Priority, or Standards-Version)
<iwj> Oh, I should have put in a Standards-Version.
<iwj> Do we use Section and Priority ?
<Kamion> iwj: and the Depends is duplicated
<Kamion> they provide hints to soyuz in much the same way they provide hints to dinstall/dak
<Kamion> they're overridden, but usually trivially; dselect users will see the results
<iwj> Kamion: IC.
<mvo> what bribe would it take to get someone to work on bug 45267 for me?
<Ubugtu> Malone bug 45267 in libnotify "Notification with an image half hidden" [Normal,Fix released]  http://launchpad.net/bugs/45267
<Kamion> there should be an actual debian/copyright in the source, per policy
<Kamion> (I realise it's generated, but the output should be in the source)
<iwj> Kamion: the duplicated Depends is very strange.  I think I must have been in a hurry.  Thinking about it I shouldn't be treating this as `I did this ages ago'; I should be treating it as `new thing I've just invented' like it looks from your pov ...
<sfllaw> OK.  Lunch time.
<iwj> And it was pretty freaky when I started so a 2nd round of review a week or three later is probably a good idea anyway.
<iwj> If you reject it I'll furtle it and upload again in a bit.
<Kamion> no, I'll not stall the work on that, as I don't see anything that should actually be harmful - please just incorporate the above into the next upload
<Kamion> I've overridden the source to Section: web
<iwj> OK.  Thanks.
<BenC> sfllaw: pong
<sivang> elmo: around?
<doko> anybody seen this with new installations? http://people.ubuntu.com/~doko/Terminal-Buttons.png -> the background of buttons has a wrong color until you move the mouse over it
<dholbach> doko: ati driver?
<doko> dholbach: yes
<doko> Radeon 9200
<dholbach> doko: there should be a bug about it
<dholbach> doko: I suppose changing the Theme makes it work again?
<Burgwork> iwj, one comment: you might want to avoid the use of "php" in a package name that has nothing to do with PHP, so as to avoid confusion
<sfllaw> BenC: Bug 41991
<Ubugtu> Malone bug 41991 in linux-restricted-modules-2.6.15 "ltmodem use hangs 686 kernel" [Major,Confirmed]  http://launchpad.net/bugs/41991
<sfllaw> It's not something we can fix, is it?
<doko> dholbach: if I change back, I see the wrong color again
<dholbach> doko: that might be another ati <-> cairo related breakage
<iwj> Burgwork: not my choice of package name.  You are of course entirely correct.  The binary package name is more sane.
<seb128> doko: that's an ati driver issue, there is a zillion of dups already
<Burgwork> iwj, yep, I see that
<iwj> Gah, this package is a pile of crap still.
<ogra> why does it have php in its name ?
<iwj> Because it's named after the CVS module in Frank's repo, which he decided to call `yada-php-yada' because he was going to write it in php.
<dholbach> what is the package name? i-dont-like-php or what?
<ogra> dholbach, the one you were discussing with iwj the last half hour 
<ogra> ubuntu-php-firefox-human
<dholbach> I downloaded a firefox-themes-ubuntu deb
<ogra> thats the binary
<iwj> Yes, the source and binary have different names.  Do catch up at the back.
<ogra> i'm just wondering what php means there
<iwj> It means `this is a pile of php'.  This is silly, I know.  See above.
<sivang> php in firefox theme??
<iwj> Or are you asking `why don't I rename it' ?
<ogra> ah, sorry i'm blind
<iwj> Obviously I don't want to go around renaming source packages; that's just makework.
<iwj> Kamion: re debian/copyright> `A copy of the file which will be installed in /usr/share/doc/package/copyright should be in debian/copyright in the source package' (policy 3.7.2.0 s12.5), you mean ?
<iwj> I'm afraid I can't comply with that because the copyright information for the binary package is generated at build-time.
<Kamion> iwj: you build-depend on the relevant packages, which means that you can generate debian/copyright from your package's clean rule.
<Kamion> you might have to *re*generate it at build time too, but it will generally be pretty close. The purpose of having debian/copyright in the source package is so that ftpmaster can extract it in a scriptable way.
<iwj> Kamion: Hmm.
<iwj> ftpmaster wants the copyright of the _source_ package, not of the binary one.
<iwj> (And policy should say `must' if it's a technical requirement of the archive system, surely?)
<BenC> sfllaw: ok, checking on it
<Kamion> In that case it's reasonable enough for debian/copyright in the source to be a straight copy of debian/copyright.in, and you can regenerate it for the binary packages later.
<iwj> I suppose the binary package copyright will include the source package one.
<Kamion> iwj: yes, well, I don't control Debian policy ...
<Kamion> It's not *quite* a technical requirement - katie would put up big flashing warnings for the ftpmaster operating the tools if it's missing who would generally reject on that, though
<iwj> Is this a feature of Debian ftpmaster as well as Ubuntu ?
<iwj> Right, so the policy is wrong.
<Kamion> more than of Ubuntu, I'd say, given that soyuz doesn't yet do automatic copyright extraction
<Kamion> AFAIK the reason that requirement is in policy was because Debian's ftpmasters wanted it to be.
<Kamion> though interestingly http://release.debian.org/etch_rc_policy.txt is a bit ambiguous on that
<Kamion> it just talks about the binary requirement
<Kamion> iwj: Hmm, perhaps I need to take back my words. I've just looked through katie's source and can't find the check for debian/copyright that I could have always sworn was there. Oh well.
<Kamion> so whatever, I guess ...
* sladen wishes people would file separate bugs and not go hunting for duplicates...
<Kamion> sladen: amen
<karim> is there a way to get the list of build-deps for a package ?
<Kamion> karim: apt-cache showsrc, or look in debian/control if you have the source package unpacked
<karim> Kamion, my goal is to maje apt-build build the build dependencies
<karim> make
<karim> Kamion, apt-cache showsrc shows the list, but I don't know how to parse it, since it also includes version numbers between braquets
<Kamion> well yes you'll have to learn how to parse that. :-)
<Kamion> the definition is in the Debian policy manual
<karim> definition of what ?
<Kamion> or e.g. /usr/lib/dpkg/controllib.pl (parsedep) or python-apt have functions to parse it
<Kamion> definition of the field format you say you don't know how to parse
<karim> Build-Depends-Indep: gettext (>= 0.13), po-debconf, po4a the line looks like that
<karim> ok
<karim> Kamion, that's horrible man
<karim> Kamion, briefly, how do I use that ?
<jdub> iwj: ubuntu-*php*-firefox-human ... ?
<Kamion> jdub: see scrollback
<jdub> heh
<jdub> bizarre :)
<jsgotangco> jdub: good morning?
<Kamion> karim: I don't have time for detailed technical support I'm afraid. If you're talking about the Perl one (which I believe is probably harder to use, nowadays) then there's an example in ubiquity/d-i/update-control. If you're talking about python-apt then I believe 'import apt_pkg; help(apt_pkg.ParseSrcDepends)' should help. Next time say which you mean ...
<jdub> jsgotangco: evening still ;)
<karim> Kamion, I am not sure how to use that in a perl programm. I have done some perl, but well ...
<karim> karim, perl
<Kamion> karim: don't use the perl one if you aren't comfortable enough with perl, then ...?
<karim> Kamion, in fact anything. I use a system cal from perl, so I just need something that can return a string with the build deps
<karim> perl or not it's fine
<Kamion> mdz: I just noticed an issue in gparted; it emits FORMAT instructions to stdout whether or not it managed to do the partition creation, so ubiquity can be confused into thinking that it needs to create a filesystem when it really shouldn't
<Kamion> mdz: this might be the cause of the heise article ogra referred to earlier, not that it's very clear, and of Billy's comment near the end of bug 45543
<Ubugtu> Malone bug 45543 in ubiquity "Serious Data Loss resizing partitions" [Major,Fix released]  http://launchpad.net/bugs/45543
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/gparted-fix-format-instructions.diff looks promising; could you eyeball it at least in principle?
<Kamion> I haven't set up a test environment yet and I'm about to finish for the week
<sladen> join #ubuntu-bugs
<iwj> Kamion: just uploaded a saner version of that package, I think.  What a mess.
* mvo is off for dinner
<iwj> Me too now.  Thanks everyone for bailing me out of this themes mess.
<haggai> doko: what's happening with apt-proxy? Any changes should be sent to me since there is a new release on the way with lots of changes
<doko> haggai: please look at the spec, it's not yet clear to me, how he wants to do that
<haggai> doko: do you have a link to the spec?
<sfllaw> BenC: It looks like TIOCGSERIAL or TIOCSSERIAL to the ltmodem device makes it pretty unhappy.
<sfllaw> Or even TCGETS.
<sfllaw> Yikes.
<zyga_> hello
<bddebian> Hello zyga
* zyga_ stays late at work :/
<tseng> Kamion: can we throw ifolder3 back out?
<sladen> launchpad is out to lunch.
<ogra> tseng, whats wrong ? 
<tseng> Kamion: it never met the normal NEW review from MOTU/Mono Team which is pretty customary before such an upload
* tseng looks for it in revu archive
<tseng> don't see it at all
<ajmitch> and it's missing build-deps
<tseng> it was definately not up to par the last any of us saw it
<tseng> (ubuntu/debian mono)
<lukaswayne9> Has anyoene else noticed some very strange GTK rendering problems in dapper?
<ajmitch> not to mention that the versoin accepted is a few months old
<ogra> and it seems to not fulfill the "at least two cross reviews" policy
<tseng> right..
<tseng> it was reviewed by several people
<tseng> but never approved
<lukaswayne9> Has anyone else noticed a lot of GTK2 rendering issues in the latest dapper?
<KaiL> might be a problem with the graphics driver?
<ogra> tseng, woah, how did that ever get past NEW ? i just ran lintian on the source
<tseng> ogra: i told you
<tseng> ogra: its bad news
<ogra> yep
<bddebian> What package?
<ogra> ifolder3
<jordi> Riddell?
<ogra> but i just discovered it might be a prob on my side
<ogra> i'm out of diskspace
<BenC> sfllaw: ok, I'll check that code path
<Riddell> jordi: hi
<jordi> Riddell: ok, so I need some help from you. Do you think you can give me a list of kubuntu packages in order of "visibility" importance?
<jordi> ie, which need to be translated first
<jordi> I'm upping kdelibs to max priority first
<jordi> more than packages, I need translation domains
<jordi> because that's what the list is about
<Riddell> jordi: source packages, binary packages or .po files?
<Riddell> yeah, so .po files
<Riddell> jordi: I'd say all the ones in kdelibs that we ship in language packs then all the ones in kdebase that we ship in language packs
<jordi> if we could be a bit more specific, it'd be cool
<jordi> I guess the kdelibs template is a lot more important than... ktexteditor-kdatatool or so
<Riddell> jordi: I don't have a list of all the .po files from kdelibs/kdebase, can you get that for me?
<jordi> https://launchpad.net/distros/ubuntu/dapper/+source/kdelibs/+translations
<Riddell> clever :)
<jordi> I mean, if I would say gnome-panel, gnomesession and gtk are the *most* important files for gnome,w hat does that translate in the kde world?
<jordi> it doesn't need to be three
<jordi> just the stuff that shows more strings in normal usage etc
<jordi> I want to do the must have at one level, then the graphical ones at another, then console stuff
<jdub> jordi: (is this just for translation priorities, or do you want it to impact the translation stats/tables?)
<jordi> it's just the sorting of the templates for now, but I guess there's lots of clever ways of using this data
<Riddell> "kdelibs" is most important, then probably kicker, ksmserver and konqueror
<Riddell> kdesktop too
<jordi> ok
<jordi> sorting this out is going to take a while
<sladen> Kamion: there's a static string in d-i that reads:  "Make sure that you allocate space for a root partition ("/"), with a minimum size of 1.5 GB, and a swap partition of at least 256 MB."  Does that need to be adjusted?
<KaiL> hmm, mostly good comments about the RC - excet quite a lot Sound-Problems and the still not really good WPA support
<KaiL> sladen, 1.5GB for ubuntu dapper?!? I don't think, it'll work below 2.5, maybe 3...
<jordi> Riddell: how about libkicker*. Are those strings visible?
<jordi> visible as the main kicker stuff
<Riddell> jordi: yes, that too please
<jordi> all of them?
<jordi> ie, libkicker-kdeprint
<jordi> doesn't sound *so* improtant :P
<Riddell> jordi: just libkicker is fine
<Riddell> oh and libkickermenu-systemmenu is used by default too
<Riddell> libkonq would be good too
<jordi> ok
<jordi> mdke: ping
<dholbach> mdz: ok to upload a new ubuntu-artwork?
<jordi> Riddell: names of templates related to the help system you can think of?
<mdke> jordi: y0
<dholbach> Kamion: ok to upload new ubuntu-artwork?
<Kamion> tseng: as ftpmaster for several months I'd never heard of any of the review policies you mention, sorry
<Kamion> sladen: it says 2 GB in my source
<Kamion> dholbach: what changes?
<dholbach> Kamion: new icons from the designer
<jordi> mdke: what's the most important doc template, for the 3 flavs?
<dholbach> Kamion: fixes two bugs we have
<jordi> *desktop?
<mdke> jordi: for each three?
<dholbach> bug 45168 and bug 34900
<Ubugtu> Malone bug 45168 in ubuntu-artwork "Todays update: OpenOffice Draw and Math not consistent with the rest of OOo icons" [Minor,Confirmed]  http://launchpad.net/bugs/45168
<Ubugtu> Malone bug 34900 in ubuntu-artwork "desktop icon inconsistency" [Normal,Confirmed]  http://launchpad.net/bugs/34900
<jordi> mdke: well they mostly share names right'
<Kamion> tseng: removed, anyway
<Kamion> dholbach: ok
<dholbach> Kamion: merci
<mdke> jordi: the serverguide and packaging guide which are in kubuntu and ubuntu are both in rosetta under ubuntu-docs... the desktopguides have been better translated so far than the others, but yeah, they are more important, I suppose. xubuntu only has desktop ;)
<mdke> jordi: preface.pot in ubuntu-docs is used for all of them
<mvo> anyone here know if it is save to purge ifrename on a upgrade? keybuk?
<Kamion> tseng: would you mind talking to Mez and finding out what's up? it was uploaded like three months ago or so, I just couldn't quite face the NEW processing since as you say it was a bit broken - then when I came to it the other day I couldn't really see a cast-iron reason to reject
<Kamion> mvo: wanna close bug 46743?
<Ubugtu> Malone bug 46743 in gnome-system-tools "Installer crashed during language pack installation" [Normal,Unconfirmed]  http://launchpad.net/bugs/46743
<mvo> Kamion: thanks
<Kamion> sladen: (Rosetta might not have been updated, but no worries, I'll munge the strings on import if not)
<jordi> mdke: ok I upped those a bit
<mdke> jordi: thanks
<jordi> enough sorting for today
<jordi> I need food and go out a bit
<Riddell> jordi: khelpcenter
<Kamion> iwj: firefox-themes-ubuntu binary accepted now too
<Kamion> will be available in universe from ~1hr from now
<mvo> mdz: ok to upload a new dist-upgrader ?
<bgertzfield> howdy chip!
<ChipX86> hey Ben :)
<mvo> hey ChipX86!
<skateinmars> hi everybody
<skateinmars> I was asking myself, will there be an update for the postegresql-8.1 package? Because the version of this package is 8.3
<pygi> skateinmars, no, not for dapper
<skateinmars> but the latest version is 8.4, wich fixes security issues
<skateinmars> err, ok pygi 
<skateinmars> thank you for the answer
<pygi> skateinmars, if those security bugs are critical fixes might be backported some time in future
<Kamion> our postgresql maintainer also runs our security team; I'm confident he'll backport any security fixes that are needed
<skateinmars> ok, I'm waiting so
<skateinmars> thanks
<ChipX86> hey mvo :)
<tseng> Kamion: I'll talk to him if i see him again
<tseng> Kamion: its been some time
<tseng> Kamion: as for the policy, its a general motu rule to upload all NEW packages to revu.tauware.de and get 2 other current motu's to approve of it
<tseng> Kamion: I am sure ogra can confirm that.
<Kamion> ok but I don't honestly think it's reasonable for ftpmaster to go and check that
<Kamion> the volume is too high
<tseng> no, I agree
<tseng> it should be the job of a MOTU to adhere to it
<tseng> he was definately aware of revu
<Kamion> no problem with you guys coming round to enforce it post-facto, of course
<Kamion> how about libflaim?
<tseng> its like a code of honor kind of thing
<Kamion> that was the other one of the set
<Kamion> it also didn't seem so bad
<tseng> libflaim has no use w/o ifolder3
<tseng> but indeed, its not as bad
<Kamion> I've got no problem with leaving it there to help with locally-packaged versions of ifolder
<tseng> I don't see a problem, either
<Kamion> it wouldn't be the only unused-by-other-packages library in the archive
<tseng> ifolder can come back in edgy on better terms
* Kamion nods
<tseng> perhaps he even meant to upload to revu and horked up his dput
<tseng> Kamion: thanks for your time.
<bgertzfield> anyone familiar with linux-restricted-modules around? I may have some questions later; making a source package like it at the moment
<tseng> bgertzfield: infinity owns it at present
<bgertzfield> tseng: many thanks
<orph-> i hear this is where the action is
<bgertzfield> orph-: well come.
<tseng> orph-: nothing terribly exciting, actually.
<orph-> tseng: lets spice it up then!
<tseng> haha maybe in 2 weeks, after release.
<jdub> morning orph- 
<tseng> I suspect most people have a pounding headache atm
<orph-> jdub: hey man
<Riddell> Kamion, mdz: around to review ubiquity/qtparted changes?
<Riddell> http://www.kubuntu.org/~jriddell/tmp/qtparted.diff
<Riddell> http://www.kubuntu.org/~jriddell/tmp/ubiquity.diff
<Kamion> I'm here for a bit
<Riddell> I couldn't work out a way to turn off the medianotified, kdesu and dcop just don't want to talk to each other
<Kamion> trying to work out how the qtparted change fixes 46404
<Kamion> oh, it was blocking trying to write "0 OK" to stdout or something?
<mdke> Riddell: do you know how to get the menu items for kubuntu docs in khelpcenter translated?
<zyga> is there any way to translate grub help menu?
<Riddell> Kamion: actually I might be getting my bug numbers mixed up there, 46404 was blocking because qtparted wasn't being passed "exit"
<zyga> the one seen after pressing f1 in the boot menu?
<Riddell> mdke: translate the .desktop files
<Kamion> ew, you really need to make qtparted exit when stdin goes away
<Kamion> (in edgy now, I guess, but still)
<mdke> Riddell: maybe we can do that and add them to the package for -updates?
<tseng> mdke: -updates wont go on the release media?
<Kamion> Riddell: ubiquity change looks ok, is it in your branch?
<mdke> tseng: I don't know, I wouldn't have thought so
<Riddell> Kamion: yes
<Riddell> Kamion: I'm yet to work out how to get QSocketNotifier to tell me stdin has gone away, it has an exception signal but that doesn't seem to be it
<Kamion> Riddell: right, merged and uploading, thanks
<Kamion> Riddell: go ahead with the qtparted change
<zyga> can someone besides pitty kick the automatic daily langpack builds?
<Riddell> Kamion: I am right with qtparted being (half the) fix for 46404, it was because it didn't care if it applied the changes or not out just output "0 OK" whatever, now it knows to output "1 Cancel" if it doesn't
<Kamion> zyga: don't think so
<Riddell> Kamion: thanks
<Kamion> Riddell: right, figures
<mvo> Riddell: is kdmtheme manager a application for gnome-app-install? 
<mvo> (or adept_installer)
<Riddell> mvo: kdmtheme or kcontrol-kdmtheme?
<jdub> hrmph
<jdub> dunno why you'd damage a collector's item like this
<jdub> http://www.flickr.com/photos/78122667@N00/153803178/
<Kamion> mdz: I've tried out that gparted patch under normal circumstances (all gparted operations work) and it seems to behave fine and issue the right instructions to ubiquity
<mdke> jdub: lol
<Kamion> mdz: I'm going to be away much of the weekend and I'm not sure I'll have another opportunity, so I'll upload it
<mdke> Riddell: so shall I round up some translators to do that, and get them to send the translations to me so I can upload to svn?
<Riddell> mdke: sure
<mdke> Riddell: do all the translations go in the same file?
<mdke> oh yeah
<mdke> i see it
<mdke> easy
<dholbach> anybody from the croatian guys in here? :)
<mdke> Riddell: maybe there is even some clever scripting someone could do to get the titles out of the xml files? I bet robotgeek or someone could do that?
<Riddell> mdke: worth a shot
<mdke> Riddell: cool, thanks
<Riddell> 22:57 < Riddell> mvo: kdmtheme or kcontrol-kdmtheme?
<mvo> Riddell: kdmtheme
<Riddell> mvo: dunno, never used it
<Riddell> but I suppose it is
<mvo> Riddell: ok, thanks
<Riddell> ah, kdmtheme is a duplicate of kcontrol-kdmtheme
<Riddell> how do I request for removal?
<Kamion> Riddell: file a bug on the package, subscribe ubuntu-archive
<dholbach> Riddell: file a bug for 'ubuntu-archive'
<lamont> mdz: ping
<Kamion> (don't assign ubuntu-archive)
<Kamion> Riddell: if you get the chance, have a look at my gparted patch to output "- FORMAT" only on successful creation of the partition - you might want to do something similar in qtparted if you have the time
<Kamion> I just uploaded it a few minutes ago
<lamont> Kamion: or are you the right guy to get permission from for an upload?
<Kamion> might be marginally less of an issue since apparently qtparted creates the filesystems itself - not sure
<Kamion> lamont: not right now, am off to bed - send mail if you can't get hold of anyone on IRC, mdz might be out enjoying Friday night in London
<Kamion> lamont: better to get permission from mdz at the moment if at all possible
<lamont> ok.  46496 - desktop fails to install on headless hppa boxen... needs an || true in an hppa specific place in postinst
<lamont> Kamion: ok.. will email mdz cc you
<mvo> mdz: I would like to upload a new gnome-app-install (updated desktop files and two bugfixes). is that ok? 
<Kamion> lamont: subscribe ubuntu-release to that bug
<Kamion> that will get our attention
<Kamion> lamont: also preferably attach a patch for review
<lamont> Kamion: will write one
<glick> is there any regulation for nazi channel operators in the main #ubuntu support channel?
<mdke> glick: yes. You talk to them in private, then if you can't resolve the issue happily, you look at the Ubuntu dispute resolution mechanism. But usually, you always can resolve it happily
<lamont> posted
<glick_> mdke: this guy bans people left and right just because i was talking about gnome
<glick_> get that?
<glick_> i was talking about gnome in #ubuntu
<Burgwork> glick_, I would also recommend you use less inflamtory words
<mdke> glick_: not here. in private
<glick_> which uses gnome
* sivang wonders about the word nazi here
<Burgwork> glick_, calling somebody a "nazi" is against the CoC
<glick_> he told me to take it elsewhere and i was just like dude, im just talking about gnome to someone
<glick_> and he banned me?
<glick_> sup with that?
<glick_> i think thats agains CoC
<mdke> glick_: this channel cannot help you, talk to them about it
* mode/#ubuntu-devel [+o lamont]  by ChanServ
<mdke> this is not the channel you have been looking for
<lamont> glick_: this channel is for discussing ongoing development of ubuntu.
<zyga> guys do you think there is any way to make 'Examples' a desktop file + translation?
<zyga> so that non-english users will still have a usefull name on their desktop
* mode/#ubuntu-devel [-o lamont]  by lamont
<zyga> and maybe some 'ABOUT THIS FILES' file that says it's okay to remove them by dragging them to the trash
<jdub> zyga: unfortunately there are all kinds of problems with that - it's best for us not to use .desktop files outside systemmy locations
<dholbach> see you guys - i'm off
<zyga> dholbach: bye
<sivang> night dholbach 
<dholbach> bye zyga, sivang
<zyga> jdub: so no .desktop files as filesystem pointers yet?
* sivang wonders about bzrk upload to universe he had done a couple of hours ago and still don't show on all archs and not apt-gettable.
<LeeJunFan> yay! I figured out why kde can't mount floppies, and made it work!
<LeeJunFan> oops, wrong chan. :p
<mdke> sivang: https://launchpad.net/distros/ubuntu/+source/bzrk
<sivang> mdke: hmm, I wonder why ubuntu4 appears both on the "PendingRemoval" and on "Published"
<zyga> jdub: I really like the thing osx does to directories about localization
<zyga> if there is some .localized.foo file inside them it can override displayable name
<mdke> sivang: I think that means that 4 replaced 3
<zyga> that solves 99% of such issues
* mvo decides he is too tired to do anything useful and heads to bed
<zyga> bye mvo 
<sivang> night mvo 
<mvo> bye zyga sivang
<sivang> mdke: ah, silly me, it's available and published already for i386
<duda_> hello all, i wanna figure out if this is a bug... or a feature :) but i don't know where to look for answers :)
<zyga> duda_: hi, go ahead
<duda_> in dapper, when i select the switch desktop option, clique on the big red button, i can go to another user
<duda_> but when i come back, it throw me to gdm, and at this time, i have to digit my user and pass two times
<zyga> duda_: which 'switch desktop' option?
<duda_> because after gdm, my sessions seems to be locked...
<duda_> switch user, sorry
<zyga> did this happen with rc version?
<zyga> (release candidate)
<duda_> hum i installed dapper a week ago and had made all updates
<duda_> isnt the same?
<duda_> sorry, im newbie+plus and have a bad english :)
<zyga> duda_: after you switch user you should not login agian
<duda_> and also translating to my language, brazilian portuguese :)
<zyga> you should select options+quit (or similar, I don't use english version ATM)
<duda_> in the gdm?
<duda_> at the gdm :P
<zyga> yes
<zyga> yes, exactly
<duda_> hummm. let me try ;)
<zyga> I'll be back in 15 minutes
<duda_> great!
<duda_> sorry to take your time with such a simples thing! :P
<Burgwork> what the heck is landscape-client?
<Kinnison> g'night all
<sivang> Burgwork: ?
<Burgwork> sivang, a placeholder package just got uploaded and then added to ubuntu-desktop
<sivang> Burgwork: hmm, interesting
<sivang> Burgwork: well, the package description says it all no?
<Burgwork>  landscape-client - Placeholder for the Landscape client
<Burgwork> maybe it is the gtk-launchpady thing?
<sivang> don't think so:
<sivang>  Landscape is a web-based tool for managing Ubuntu
<sivang>  systems. Landscape is a web-based tool for managing Ubuntu
<sivang>  systems. Landscape is a web-based tool for managing Ubuntu
<sivang> err,
<sivang> my network is crappy today
<Burgwork> hmm
<Burgwork> wonder if that is the Ubuntu Center, redubbed
<sivang> web interface is even better actually, more universal
<Burgwork> yes, but attendant issues
<Riddell> Burgwork: ssh, it's super sekret
<Burgwork> Riddell, you post to a public mailing list and you claim it is a sekret? :)
<sivang> Riddell: heh
<sivang> Burgwork: which public list?
<Burgwork> ubuntu-changes
<mdke> dapper-changes
<sivang> ah :)
<Burgwork> Riddell, seriously, you have any dirt for us?
<sivang> you see, now we caused mdz to vanish :)
<Riddell> I know nothing
<Burgwork> Riddell, riiggght...
<mdke> you mean "nussing"
<sivang> let's leave it, we'll all see what it is about I assume after dapper is out.
* sivang arghs at malone #39482
<Ubugtu> Malone bug 39482 in nautilus "nautilus tries to move when dragging and dropping from read-only folders, instead of copying" [Normal,Confirmed]  http://launchpad.net/bugs/39482
<sivang> nautlus DND code... man
* sivang notes it's mind twisting
<Riddell> all I know is that they decided not to call the super sekret project Cockfosters
<sivang> ha ha ha
<Riddell> but that's also the case for Ubuntu
<mdke> people find Cockfosters funny, except people who live there
<sivang> there's a place like this?
<zul> heylo
<mdke> sure, you can't make a name like that up
<Burgwork> sivang, it is a stsop on the Underground
<Burgwork> http://en.wikipedia.org/wiki/Cockfosters
<mdke> Burgwork: they named the stop after the place
<mdke> as with most stops
<Burgwork> mdke, yep, but the original joke was about the station
* mdke leaves it at that
<sivang> night all
<tseng> bye sivang 
<tseng> "this train is for cockfosters"
<Burgundavia> whiprush, those of us in #edubuntu were discussing the other day about a "thin client mode" to display the fancy bling
<zakame> hi all
<Burgundavia> salut
<zakame> fabbione: pong
<zakame> fabbione: pong
<zul> he might have gone to bed zakame 
<zakame> er my irssi got stuck :/
<whiprush> Burgundavia: oh really?
<Burgundavia> whiprush, yep. I didn't realize that gnome doc existed
<Burgundavia> we were thinking about memory usage and I was esposing a long term plan to merge Xfce and Gnome
<whiprush> the problem with alot of the upstream gnome docs is tha it's not easy to contribute, vs. say, ubuntu documentation.
<whiprush> I was a "gnome admin" for 6 months before I found that documentation.
<neuralis> which is this?
<whiprush> the gnome system administrator guide.
<Burgundavia> the other side of that is that companies usually hack their own stuff up, like we have
<whiprush> to add to the problem, RH, Novell, and Sun have redundant documentation on the same subject.
<Burgundavia> actually pessulus is a great thing for gnome-love to work on
<whiprush> you have to read all 4 to really figure it out.
<Burgundavia> I think that was because there was no community doc effort
<Burgundavia> it was all lead by the teams for those companies
<Burgundavia> the community effort is only now starting up
<whiprush> yes, all 4 documents are historical artifacts.
<whiprush> ideally it'd all be an upstream gnome document.
<Burgundavia> the other place that has suffered in the same way is the configuration tools
<ghee22> speaking of gnome documentation, I'm working on the welcome center for ubuntu.  this documentation really helps by not "recreating the wheel".  I noticed QuickTourDraft in the ubuntu wiki.  Regarding this, I have a question:  How do I access UbuntuDocumentationTeam svn repo?  Reason I ask is because the latest tour, according to the wiki is here: "The doc is now in the ?UbuntuDocumentationTeam svn repo, in the quicktour dir in the 
<Burgundavia> ghee22, join #ubuntu-doc
<ghee22> thank you Burg
<ghee22> are you Burgundavia on ubuntu forums?  (corey?)
<Burgundavia> ghee22, yep
<ghee22> got it  :o)
<ajmitch> afternoon
<Burgundavia> salut ajmitch 
<bockman> there is a bad security problem in Breezy/Hoary for openvpn (Bug #45827). i emailed the listed maintainer, but he says he doesn't work for ubuntu. how can i get this fixed?
<Ubugtu> Malone bug 45827 in openvpn "openvpn old security problems (Breezy)" [Normal,Unconfirmed]  http://launchpad.net/bugs/45827
<Burgundavia> bockman, you need to ask the MOTUs to look into it. #ubuntu-motu
<bockman> ok, thank you
<jsgotangco> argghh
<ajmitch> hi jsgotangco :)
<janimo> ping
<ploum> pong
<janimo> ploum: saw the silence and was tetsing whether I got disconnected :)
<ploum> janimo: you are disconnected. I'm a poltergeist haunting your computer
<janimo> Kamio,: infinity, xubuntu desktop cd seems to install gnome-session and gnome libs again via gdm. IIRC there was a workaround at the servers to apt-get install xterm gdm for xubuntu, did it go away?
<janimo> ploum: I am scared. Happy :) ?
<seb128> janimo: could you fix thunar to not claim a non-existant mimetype and breaking GNOME?
<janimo> btw can the poltergeist confirm LP is down?
<seb128> or should I?
<seb128> and yeah, launchpad == proxy error
<janimo> seb128: I wanted to link to xfce upstream bug but LP is down
<janimo> a moment
<ploum> indeed, LP is down..
<nomed> seb128, does "open with gvim" work in gnome?
<janimo> seb128: http://bugzilla.xfce.org/show_bug.cgi?id=1854
<Ubugtu> bugzilla.xfce.org bug 1854 in general "thunar taking over from nautilus" [Normal,Assigned]  
<seb128> nomed: why wouldn't it?
<nomed> it doesn't in thunar
<janimo> ploum: btw poltergeists make noise, somewaht in contradiction with my noticing of silence on the channel ;)
<ploum> janimo: haven't you see the chair moving in your room ?  ;-)
<nomed> janimo, did u set orage instead of the clock plugin at the end ?
<seb128> janimo: seems you people are not trying to read what I said on the bug
<janimo> ploum: oh, I tought it was the wind
<seb128> janimo: I'll have to fix that package myself :/
<seb128> janimo: a directory is "x-directory/normal"
<seb128> "x-directory/gnome-default-handler" is not mentionned to /usr/share/mime
<janimo> nomed: no, because I think the clock plugin is simpler and enough. orage is an extra porcess running. So did not think it was important enough to change
<janimo> nomed: are there some really compelling reasons
<nomed> the calendar ..
<nomed> but nothing really important ..
<nomed> i just didn't know if it was a choice .. 
<janimo> seb128: I have read what you said, I just want to make sure we fix it right if it needs a fix
<janimo> seb128:  and I am not convinced it needs a fix yet
<seb128> janimo: I'll not let Ubuntu broken for dapper because you don't want to fix your package
<janimo> nomed: I think the calendar is not that important for most people as to bee in the default panel. (Just noticed recentl;y we do not even build it with iCal support, since libical is not in ubuntu)
<seb128> janimo: if you don't do that change I'm going to do it
<janimo> seb128: please keep it techincal
<seb128> janimo: you have no technical argument to reply to what I explained
<janimo> seb128: I am tired of kneejerk reactions instead of real discussion
<janimo> seb128: my argument is, that installed packages do not themselves set the policy
<seb128> janimo: I explained my point on the bug you could have replied
<janimo> it's the user that does it
<seb128> janimo: not true
<janimo> I found the xfce bugzilla comment convincing
<seb128> it's just wrong
<seb128> "x-directory/gnome-default-handler" is not a mimetype
<janimo> is that not a gnome-independent thing?
<seb128> grep to /usr/share/mime if you are not convinced
<janimo> regardless if it's a mimetype or not. Is it gnome specific?
<seb128> "x-directory/normal" is the mimetype for a directory
<seb128> "x-directory/gnome-default-handler" as the name indicated it is something used internally by GNOME
<janimo> seb128: ok, I am not familiar with the places plugin etc. What does it call actually?
<seb128> not a public interface to play with
<seb128> gnome-open file:....
<janimo> it is supposed to be opened by nautilus?
<nomed> seb128, did u assign that bug to xubuntu-team ?
<seb128> ok, let me explain you how mimetype associations work
<seb128> nomed: I did
<seb128> nomed: is that wrong? that's thunar bug
<nomed> seb128, no no it's not worng .
<nomed> i wanted just to see what that issue is :)
<seb128> janimo: apps ship a .desktop to /usr/share/applications, that .desktop has a MimeType=... list with the mimetypes supported by the app
<nomed> and launchpad is down ...
<seb128> janimo: update-desktop-database does an index
<seb128> ou get something like 
<seb128> $ grep html /usr/share/applications/mimeinfo.cache
<seb128> text/html=epiphany.desktop;bluefish.desktop;firefox.desktop;
<seb128> 
<seb128> ie Mimetype=<list of apps for it>
<seb128> that's the choice suggested for nautilus right click menu by example
<seb128> then you can set a default with /usr/share/applications/defaults.list
<seb128> like
<seb128> $ grep directory /usr/share/applications/defaults.list
<seb128> inode/directory=nautilus-folder-handler.desktop
<seb128> x-directory/normal=nautilus-folder-handler.desktop
<seb128> janimo: that list sets the system default for GNOME
<janimo> seb128: so far I am following
<seb128> (you could make a different defaults-xfce.list if you want)
<seb128> janimo: the mimetype are defined to /usr/share/mime
<janimo> seb128: /etc/xdg/xubuntu/applications/defaults.list already have it for a while
<seb128> $ gnomevfs-info Desktop
<seb128> Name              : Desktop
<seb128> Type              : Directory
<seb128> MIME type         : x-directory/normal
<seb128> Default app       : nautilus-folder-handler.desktop
<seb128> 
<seb128> note
<seb128> "MIME type         : x-directory/normal"
<seb128> 
<seb128> now you will not find "x-directory/gnome-default-handler" to /usr/share/mime
<seb128> that's not a public mimetype
<seb128> and not something you should play with
<seb128> you should just use "x-directory/normal"
<seb128> which would do what you want, associate with a directory
<seb128> and NOT break GNOME
<janimo> seb128: mind you it does NOT break gnome. If users install thunar that is no longer gnome it's a mixed environment
<seb128> janimo: so now your turn to explain why I'm wrong
<seb128> janimo: it plays with some GNOME private time
<seb128> s/time/type
<seb128> k, I give up
<janimo> seb128: first I have so far not said you were wrong, just was not convinced you were right either
<seb128> do whatever you like, I'll fix that myself
<janimo> seb128: I was going to continue 
<seb128> k
<seb128> so please do
<janimo> seb128, please install thunar first
<janimo> see it has not MIME types in it's desktop file
<janimo> I also did not set the gnome-directory in defaults.list as I copied it from usr/share where it is not listed
<janimo> bugzilla comment says firefox uses that x-gnome-direcory handler
<janimo> to call out to a file manager
<janimo> and if thunar does not handle it it cannot be called from firefox
<seb128> I doubt of that
<seb128> <janimo> see it has not MIME types in it's desktop file
<seb128> $ grep MimeType /usr/share/applications/Thunar-folder-handler.desktop
<seb128> MimeType=x-directory/gnome-default-handler;x-directory/normal;inode/directory;
<janimo> the rest of that comment seems very clear to me as well
<janimo> if gnoome panel want to use nautilus it should not call it via an indirection which it would not want
<seb128> hum
<janimo> seb128: ok I looked at Thunar.desktop only, my bad
<seb128> let's start again
<seb128> <seb128> janimo: apps ship a .desktop to /usr/share/applications, that .desktop has a MimeType=... list with the mimetypes supported by the app
<seb128> <seb128> then you can set a default with /usr/share/applications/defaults.list
<janimo> please don't copy paste that I read it already
<seb128> "<janimo> if gnoome panel want to use nautilu" ... that's not true
<nomed> does the OnlyShowIn work just for the menu?
<seb128> panel only calls the default mimetype for "x-directory/normal"
<janimo> seb128: ok besides nautilus who would be an x-d-g handler?
<seb128> which would work fine if you didn't override the mechanism by playing with "x-directory/gnome-default-handler"
<seb128> x-directory/normal=Thunar-folder-handler.desktop;nautilus-folder-handler.desktop;
<seb128> to /usr/share/applications/mimeinfo.cache on my box
<seb128> konqueror probably too but I don't have it installed
<janimo> x/g-d-h I mean
<janimo> seb128: is x-directory (w/o) gnome) enough to make thunar work as a FM called by apps?
<seb128> it should
<seb128> it is for most of apps
<seb128> if firefox uses "x-directory/gnome-default-handler" it would be bugged
<seb128> I've not checked for that
<seb128> but I'm not sure on how it could
<seb128> "x-directory/gnome-default-handler" is not a mimetype (in the sense it's not known by /usr/share/mime)
<seb128> janimo: that comments to the upstream bug makes me think the guy doesn't know how to mimesystem is working
<janimo> so does gnome-default-handler override the 'normal' if declared?
<seb128> janimo: directory is no a special case, that's just a mimetype
<seb128> janimo: looks like, since thunar is always opened to open an "x-directory/normal" whatever the default for it is set
<Lathiat> tmpfs                1013M   19M  995M   2% /lib/modules/2.6.15-23-386/volatile
<Lathiat> tmpfs                1013M   19M  995M   2% /lib/modules/2.6.15-23-k7/volatile
<Lathiat> tmpfs                1013M   19M  995M   2% /lib/modules/2.6.15-22-386/volatile
<Lathiat> tmpfs                1013M   19M  995M   2% /lib/modules/2.6.15-22-k7/volatile
<Lathiat> volatile recreated on kernel postinst?
<Lathiat> i probably havent rebooted for a couple updates
<seb128> janimo: looking to gnome-vfs code they use "x-directory/gnome-default-handler" as a trick to be sure there is a directory handler even if the mimeinfo cache lists none
<seb128> janimo: i.e: if they find no x-directory/normal handler they set x-directory/gnome-default-handler
<janimo> seb128: ok but why does it not use nautilus directly ?
<janimo> what I don;t get is, that since it is aclled via an indirection it was meant to be overridable no?
<janimo> s/aclled/called/
<seb128> janimo: as said the panel used the preferred app associated to "x-directory/normal"
<seb128> janimo: you could be wanting to set Thunar as the default under GNOME
<infinity> Lathiat: yes, postinst has to mount volatile and compile all the modules once, so you get a properly-updated modules.dep
<seb128> janimo: that's just that playing with "x-directory/gnome-default-handler" breaks the mechanism
<janimo> seb128: I would appreciate if you commented on what thunar upstream said (in LP since I assuem you don't have an xfce bugzilla account)
<Lathiat> infinity: cant unmount the old one?
<infinity> Lathiat: Err, what?  Why would it do that?
<janimo> seb128: since I get contradictory opionions from you and thunar upstream I'd really prefer if you could agree on where the bug actually is
<infinity> Lathiat: It's not going to randomly umount filesystems just cause it believes you may not want it anymore.  Reboot if it bugs you.
<infinity> Lathiat: Which you should be doing after kernel updates ANYWAY.
<janimo> and making sure it does not break firefox or other apps
<Lathiat> oh hrm i thought it had doubled-mounted i see there was one of each revision/version
<janimo> seb128: I linked the uptream bug in LP
<infinity> Lathiat: Yeah.  It won't mount it twice.  It checks for that.
<Lathiat> altho, leaving the voltaile mounted for a non-running kernel ?
<janimo> and I'll point upstream to LP back to your response
<janimo> infinity: saw my question about an hour ago regarding the xubuntu desktop CD installing gnome-session?
<infinity> Lathiat: Normally, this wouldn't be a problem.  You're the one who's upgrade *4* kernels without rebooting. :)
<infinity> Lathiat: s/upgrade/upgraded/
<seb128> janimo: I already exprimed myself on the launchpad bug, what else do you want me to say?
<Lathiat> infinity: i just went through 1 update, im running -22 -23 is newest, and i just happen to have both -386 and -k7 installed :)
<ajmitch> Lathiat: don't worry, you're not the only one :)
<Lathiat> :)
<infinity> Lathiat: 2 updates.  You upgraded from -22.33 to -22.34 *and* installed -23.xx
<infinity> Lathiat: Otherwise, you wouldn't have both 22-386 and 22-k7 mounted.
<Lathiat> uh
<Lathiat> how do you figure that
<infinity> Lathiat: Anyhow.  Other than wasting a little bit of RAM on a tmpfs you're not using, there's no real harm.  And since we expect people to reboot somewhere after that postinst runs, I'd prefer to keep the moving parts count low.
<Lathiat> 22.34 came out  7 may and i only have a 6 day uptime so i definiately only went from -22 to -23
<Lathiat> but anyway :)P
<infinity> Lathiat: Youre booted into -22-k7 right now, right?  And you have -22-k7, -22-386, -23-k7, and -23-386 installed.  On boot, -22-k7/volatile was mounted.  When you upgraded from -22.33 to -22.34, -22-386/volatile was mounted.  lather, rince, repeat for -23-{k7,386}/volatile
<Lathiat> ah, i see the logic there
<infinity> Lathiat: When -22.34 came out makes no difference.  When you upgraded does. :)
<infinity> -22.34 only left the archive a short while ago.
<infinity> Anyhow, non-bug, IMO.  Trying to guess what filesystems to unmount to save a tiny bit of RAM is not sane, given that we expect you to reboot anyway.
* Lathiat nods
<janimo> seb128: so if thunar did not set gnome-defa-handler it nautilus/thunar could be chosen as preferred fm in gnome and either be used for places//firefox etc consistently?
<janimo> all across gnome mean?
<janimo> that would indeed solve the original reportes problem
<janimo> but if some apps rely on gnome-default-handler instead of directory-default it does not solve it
<seb128> why would some app do that?
<seb128> gnome-default-handler is not a mimetype
<seb128> i.e: not listed by /usr/share/mime
<janimo> seb128: what does this all have to do with mimetype or not?
<janimo> the question is 'is it settable'?
<janimo> you already said 3 times it's not a mimetype and I got it
<seb128> the opening association is how I described before
<seb128> you open a mimetype
<seb128> and the list of handles and make from the .desktops you have installed
<seb128> and the default from the system default or an user default you set
<infinity> janimo:             LIST="$LIST ubuntu-base xterm xubuntu-desktop"
<infinity> janimo: That's how it's been since you first reported the issue to me.
<janimo> if it is settable it means it can be something else than nautilus
<janimo> if it's not settable what is it there for?
<janimo> can you please comment in LP and point out to thunar upstream why he's wrong?
<seb128> janimo: I don't get your issue. Opening a directory is opening an "x-directory/normal" mimetype and works according to the mechanism I explained 3 times already and you understood
<janimo> seb128: infinity, ok, there's a lag here I just got two full pages after no activity
<janimo> I'll have to reread and see I may have asked soem questions that were already replied to
<janimo> infinity: weird then.thanks
<nomed> janimo, did u add any new pkge on the seeds ?
<nomed> xubuntu-system-tools ex ..
<janimo> seb128: re LP. Since upstream read the bug comments in LP and replied I'd assume you should reply to what he said specifically not what I said earlier
<janimo> he cam with other arguments
<janimo> nomed: I added ubuntu-artwork most recently
<janimo> seb128: and I did not really have arguments in LP, just a few questions and uncertainties, that's why I forwarded it upstrea
<janimo> seb128: since you said upstream author does not know how the mime system works, you may want to set him straight
<janimo> I'd rather he fixes the bug upstream too not just have it in ubuntu
<nomed> janimo, no it's not ubuntu-artwork ...
<nomed> and it's not xubuntu-system-tools ..
<janimo> nomed: is it not gnome-session? do you have liveCD booted?
<nomed> janimo, no ..
<nomed> i'm just checking deps ..
* janimo fires up qemu
<nomed> http://cdimage.ubuntu.com/xubuntu/releases/dapper/rc/xubuntu-6.06-rc-desktop-i386.manifest
<seb128> janimo: commented on the bug
<janimo> seb128: thanks
<seb128> np
<nomed> janimo, i do not see gnome-session there
* seb128 is away, bbl
<janimo> seb128: a moment
<nomed> janimo, and i do not see even on "current" ...
<seb128> janimo: what?
<janimo> where is the comment I don't see it in LP?
<janimo> https://launchpad.net/distros/ubuntu/+source/thunar/+bug/46554
<Ubugtu> Malone bug 46554 in thunar "thunar takes over gnome "places"+"bookmarks" menu in gnome panel" [Unknown,Unknown]  
<seb128> janimo: https://launchpad.net/distros/ubuntu/+source/desktop-file-utils/+bug/35997/ is the bug about that for me
<Ubugtu> Malone bug 35997 in libgnome "Gnome's Places menu starts Konqueror instead of Nautilus" [Unknown,Unconfirmed]  
<janimo> seb128: ah ok, duplicates
<seb128> janimo: that's the one you mentioned on the xfce bug
<janimo> ah sorry, I tought it was the latest one
<seb128> np
<seb128> bbl now :)
<janimo> nomed: I think I found it
<nomed> janimo, is gnome-session in ?
<infinity> No, gnome-session isn't being pulled it.
<janimo> nomed: ubiquity-frontend-gtk
<nomed> yep
<infinity> Err, no.  ubiquity isn't installed until later in the process.
<janimo> gotta see though what
<infinity> You're getting GNOME libs before that.
<nomed> infinity, but ...
<nomed> shouldn't it be listed in manifest file ?
<janimo> infinity: is there a chronologically ordered list?
<infinity> janimo: The build log?
<janimo> how do I see what (and how) it is getting installed?
<infinity> janimo: http://people.ubuntu.com/~cjwatson/livefs-build-logs/dapper/xubuntu/20060527/livecd-20060527-i386.out
<janimo> infinity: thanks
<infinity> janimo: I'm doing a test in a chroot to see what's pulling in libgnome.
<infinity> (You're lucky I have a local mirror..)
<janimo> infinity: I am in a chroot too trying to install xubuntu bits too
<janimo> got down to xubuntu-live (so it's not gdm this time)
<infinity> Err, I just installed xterm and -desktop, and got libgnome pulled in.
<infinity> Or is libgnome expected?
<infinity> (which extra library or libraries are you actually complaining about?)
<janimo> infinity: no libgnome is not expected
<janimo> only libgnomeprint
<infinity> Oh, maybe I just can't read.
<janimo> ah indeed I get that too... :(
<janimo> so not via gdm but somewhere else
<infinity> I'll know for sure in about 2 minutes. :)
<janimo> hm I wonder why firefox-gnome-support is installed
<infinity> It's not.
<nomed> infinity, janimo
<infinity> apt's merely telling you that it's suggested.
<janimo> nomed: yes?
<nomed> why those pkges you're checking are not in the manifest file ?
<nomed> http://cdimage.ubuntu.com/xubuntu/daily-live/current/dapper-desktop-i386.manifest
<janimo> nomed, I know too little about all this to answer that :)
<nomed> i guess that can help ..
<infinity> nomed: What isn't in the manifest?
<nomed> it means it happen after the manifest file is generated
<infinity> nomed: I see everything there...
<nomed> infinity, i do not see any unwanted package there
<janimo> hmm abiword-plugins?
<infinity> libgnome2-0 2.14.1-0ubuntu2
<infinity> libgnome2-common 2.14.1-0ubuntu2
<infinity> At least.
<nomed> ahh k
<janimo> nope not abiword either, just on a fresh install
<nomed> liblaunchpad-integration0
<nomed> i guess
<janimo> infinity: if a package is in the seed is it going to be taken into dep calculations with priority?
<infinity> janimo: I'm not sure I understand the question...
<janimo> infinity: abiword and gnumeric depend on goffice|goffice-gtk
<nomed> janimo, if a package is in the seed 
<janimo> infinity: and I explcitietly seed goffice-gtk to make sure it is chose. Is this right?
<nomed> mainly in xubuntu-desktop
<nomed> and it depends on pkge1|pkge2
<nomed> even if pkge2 is listed in as xubuntu-desktop dep
<infinity> janimo: Well, libgoffice-gtk-1-2 was chosen, so it seems to be working as expected.
<nomed> pkge1 will be installed by "package"
<nomed> i hope you got what i mean
<janimo> ok
<infinity> nomed: No, if pkg1 and pkg2 conflict, and you ask for "install pkg2, and pk3 which depends on pkg1|pkg2", apt only has one choice.
<infinity> It can either do what you ask, or do nothing.
<nomed> what's nice is that this issue is not present in smart-pn
<nomed> pm even
<nomed> infinity, see xterm issue
<infinity> nomed: Yes, that's different.  xterm and gnome-session don't conflict.
<janimo> nomed: lpintegration is ok
<infinity> nomed: The goffice|goffice-gtk stuff should conflict, hence there's only one way to satisfy the dep.
<nomed> infinity, yep
<nomed> but i'm not supposing libgnome is added by an issue like that one
<infinity> The following packages will be REMOVED:
<infinity>   libbonoboui2-0* libgnome2-0* libgnome2-common* libgnomeui-0*
<infinity> That's odd.
<infinity> Nothing's pulling in libbonoboui2-0...
<nomed> infinity, i guess it's because that "pkge2" gets installed as dep by something else ...
<nomed> so those pkges are not needed anymore ..
<infinity> But nothing should have an alternate dependency on libbonoboui2-0.. That would make no sense.
<nomed> i'm sorry for not being clearer .. 
<nomed> true even ..
<janimo> libgnome2-common is installed and depends on bonobo
<infinity> janimo: 
<infinity> The following packages will be REMOVED:
<infinity>   libbonoboui2-0* libbonoboui2-common* libgnome2-0* libgnome2-common* libgnomeui-0*
<infinity>   libgnomeui-common*
<infinity> 0 upgraded, 0 newly installed, 6 to remove and 0 not upgraded.
<infinity> Removing all that doesn't remove anything you've seeded.
<infinity> So, I'm not sure why it's getting installed.
<infinity> mvo: Around?
<janimo> infinity: right...
<nomed> testing that on a pbuild login ...
<infinity> nomed: Same deal.  This is a clean chroot.
<ogra> urgh, mdz your last seed change makes my edubuntu seeds explode ... 
<infinity> I just did "apt-get install xterm xubuntu-desktop", then started trying to remove gnome libs.
<mdz> ogra: how so?
<ogra> mdz, tons of conflicts (server, ship-live etc)
<Diskdoc> Hello. I have a sweet, calm saturday on my hands and I thought I'd help testing the RC. I'm not sure if this is the right channel to ask but I was wondering about the testing matrix.. Under the Testing/Current page there is a point 16 in the Matrix called "DapperUpgrades". So, is it ok for me to upgrade Breezy using the online update procedure and then test, from what step?
<mdz> ogra: that's weird; my only change was to add one package to desktop
<ogra> the log shows a lot more for me
<janimo> does apt not have some logging to tell us how it decided it installs a package? 
<ogra> there is a big tail of other chages (not from you) attached 
<janimo> debugging rather than logging I guess
<ogra> mdz, http://people.ubuntu.com/~ogra/mdz-merge.log
<infinity> janimo: It has the pkgProblemResolver, but that doesn't appear to output anything on install (hence why I pinged mvo)
<ogra> mdz, thats what i get if i do "bzr log -r649 dapper/"
<mdz> ogra: looks right; I merged my branch with mainline and then added that one commit
<ogra> hmm
<mdz> ogra: you can just add landscape-client to desktop and skip the merge if there's a problem
<infinity> janimo: So far, I'm up to this many useless packages:
<infinity>   libbonoboui2-0* libbonoboui2-common* libgnome2-0* libgnome2-common* libgnomeui-0*
<infinity>   libgnomeui-common* libgnomevfs2-0* libgnomevfs2-common* libgsf-gnome-1-113*
<infinity> janimo: Can you spot more in the manifest?
<janimo> infinity: these are what I saw too by grepping  what apt-get would install
<ogra> mdz, yep, thats what i will do, but i suspect i'll get more and more out of sync, at least with server and ship-live i am already
<mvo> infinity: now around (I was having lunch)
<infinity> mvo: Is there any way to get a pkgProblemResolver-style report during "apt-get install" when the install doesn't fail? :)
<infinity> mvo: (ie: to trace why apt is installing packages that are obviously not depdenencies of the final system state)
<mvo> infinity: yeah, it should be: "apt-get -o Debug::pkgProblemResolver=true install lala" <- this should work if the problem resolver is called at all
<mvo> infinity: but it may well be that it is not run because apt thinks its all good
<infinity> mvo: Yeah, then it's not being run at all, cause that's in my config. :)
<mvo> infinity: what package/situtation is this about?
<infinity> mvo: (It runs at other times, like when removing packages with deps, so I know it works)
<mvo> infinity: you always run with the problemResolver enabled? woah!
<infinity> mvo: See above.  If you "install xterm xubuntu-desktop" in a clean chroot, you end up with (at least) these extra packages installed:
<infinity>   libbonoboui2-0* libbonoboui2-common* libgnome2-0* libgnome2-common* libgnomeui-0*
<infinity>   libgnomeui-common* libgnomevfs2-0* libgnomevfs2-common* libgsf-gnome-1-113*
<infinity> mvo: In my chroots, I do.  Not in my base system.
<mvo> infinity: ok, let me check
<tsdgeos> jordi: ping
<infinity> mvo: An option to output the full (I know it will be huge) decision tree, so I can easily track back "why the hell did you install that?" would be nice.
<mvo> infinity: ok, I'm adding it now to see if it brings some light into this 
<mvo> infinity: it seems like abiword is draging the stuff in
<Lathiat> seb128: are you aware of the problem with the "Removable Devices" menu randomly eating and uneating devices?
<seb128> Lathiat: no
<mvo> infinity: my bzr apt has a option: "Debug::pkgDepCache::infinity" now, but I guess "Debug::pkgDepCache::AutoInstall" is more appropriate
<seb128> Lathiat: "eating"? it's supposed to list partitions and mounted removable media, not to list CD drives with no CD mounted by example
<Lathiat> seb128: i have 5 internal disks there all in the places menu
<Lathiat> seb128: if i mount a usb disk, a "Removable Devices" sub-menu appears, bu tall the internal disks move into it
<Lathiat> along with the usb disk
<Lathiat> when i unmount it hey all go back into the main places menu
<seb128> looks fine
<janimo> mvo, abiword itslef or abiword-plugins?
<Lathiat> this is expected behavior?
<mvo> janimo: according to my debug output abiword itself
<seb128> Lathiat: is that the presence of the menu you call "eating"?
<Lathiat> seb128: yes :)
<nomed> janimo, i'm pretty sure it's abiword-plugin ..
<nomed> mvo, really ?
<seb128> Lathiat: after 5 items you get a submenu, same for bookmarks, that's to avoid too long menu
<Lathiat> hrm i thought it happened even when i had less..
* Lathiat tries
<mvo> nomed: libgnomecanvas is a direct dependency of abiword, this brings in libgnomeprint
<janimo> mvo, ah those are ok
<janimo> mvo, print and canvas
<Goshawk> hi
<janimo> only libgnome and libgnomeui are extra
<_ion> gdk_window_shape_combine_mask (win->window, (GdkBitmap *) mask, 0, 0);
<Lathiat> seb128: hrm, indeed
<janimo> and bonobo
<_ion> Sorry, wrong channel.
<mvo> janimo: libgnome itself it because libgoffice brings libbonoboui and that depends on libgnom2 . libgoffice is needed for abiword-plugins
<Lathiat> seb128: did the number change?
<mvo> nomed: so you are right :)
<seb128> Lathiat: not that I know of no
<Lathiat> i've sine added another disk and i used to get the same thing, but oh well
<mvo> nomed: I just misunderstood the issue it seems
<janimo> mvo, we have an alternate dep on libgoffice-gtk which is seeded explcitely
<infinity> mvo: Debug::pkgDepCache::infinity? :)
<seb128> Lathiat: but CD drives used to be listed
<janimo> mvo, Ithought that  would be chosen
<seb128> Lathiat: now we list removable medias only when mounted
<nomed> janimo, it doesn't metter
<nomed> as it's in xubuntu-desktop
<Lathiat> seb128: hm ok - cheers
<seb128> Lathiat: np ;)
<infinity> mvo: That libgoffice isn't actually pulled in.
<Goshawk> is it possible to add userspace-bootsplash in "Provides" field of the package usplash and change the dependece of ubuntu-desktop from usplash to userspace-bootsplash? This will allow other usermode bootsplashes to work with ubuntu-desktop...
<nomed> smart-pm would be able to resolve this .. apt doesn't
<infinity> mvo: Note that when I do the install, then remove the above-mentioned packages, they don't remove anything I asked apt to install previously.
<seb128> Lathiat: is the submenu itself an issue? I think we could have a gconf key for the number of items before displaying it, but not for that cycle anyway
<nomed> infinity, that's because ..
<nomed> libgoffice-gtk-1-2 is seeded ..
<Lathiat> seb128: well the submenu annoys me because - and its very confusing having it appear and disappear
<nomed> i guess
<Lathiat> but i can see th elogic in movign to a submenu when it starts to get a bit long
<seb128> right
<infinity> nomed: Yes, which conflict with the other libgoffice, which means apt will only install one, which means it shouldn't be installing the deps for the other.
<nomed> that's the case "pkge1"|"pkge2" ...
<seb128> the issue is that you just moving around the limit
<infinity> mvo: So, apt is installing deps for packages that it's not actually installing?
<Lathiat> yeh
<nomed> infinity, but abiword-plugins is in xubuntu-desktop
<nomed> infinity, if you try ..
<mvo> infinity: but I get it right, libgnome2-0 is the problem? 
<nomed> probably
<nomed> apt-get install xterm libgoffice-gtk-1.2 xubuntu-desktop
<infinity> mvo: It's one of the problems, yes.  I gave the list above.
<mvo> infinity: yes, it checks abiword-plugins before it comes to libgoffice-gtk-1.2
<nomed> that issue is gone
<infinity> mvo: So there's no reverse checking when it drops a dep, then.
<mvo> infinity: exactly
<infinity> mvo: (ie: it drops libgoffice-1.2, so it should drpo all its deps, then back up and re-resolve)
<nomed> infinity, same as xterm issue ..
<infinity> nomed: Well, no.  Different from the xterm issue.
<infinity> nomed: Honest.
<nomed> infinity, it looks exectly the same issue
<nomed> see gdm 
<mvo> infinity: what it should probably do is, first install all direct deps, then try to resolve that
<infinity> nomed: No, cause the gdm/xterm/gnome-session thing doesn't include any conflicts, so no dependencies get dropped.
<Lathiat> seb128: conceivably, you could implement some smarts to stop it going into a menu when it goes 1 higher if its usually on 5, definitely not for dapper tho i guess and a little complex
<infinity> nomed: Anyhow, I can hack around it with the above rune.
<seb128> Lathiat: right
<Lathiat> and i guess, i dont knwo how many items is too high on 1024x78
<nomed> infinity, k i got what you mean
<Lathiat> and a gconf key would definiately be handy
<infinity> mvo: Would it behave better if I did "apt-get install <all the dependencies of xubuntu-desktop>" instead of "apt-get install xubuntu-desktop"?
<infinity> mvo: Because then everything would be an "install" target, instead of a depency target...
<infinity> dependency, too.
<mvo> infinity: try apt-get install libgoffice-gtk-1-2 xubuntu-desktop
<infinity> mvo: I will, but that's only a bandaid until the same thing happens again.
<infinity> mvo: Hence the question.
<nomed> ehehe
<ogra> gah
* ogra kicks evo
<ogra> i'm cursed
<mvo> infinity: I could write you a python-apt based script that should get it right all the time, would that be ok?
* mvo wonders if he really had written "all the time" 
<ogra> seb128, is there any chance the evo crasher loops i have twice a week will go away before release i'd be happy if i hadnt to delete my mailboxes twice a week ...
<seb128> ogra: no
<nomed> mvo, wouldn't it be the same as to use the germinate output of xubuntu-desktop ?
<ogra> (especially since its hard to search in mails you dont have)
<ogra> :/
<seb128> ogra: we are pretty frozen now, I doubt any change will make it now
<seb128> ogra: especially that you are the only one to get that issue so to debug it ...
<ogra> seb128, you pointed me everytime to upsteam bugs when i showed you the traceback
<infinity> nomed: yeah, I could use the germinate output.  The reason I don't is to test that the -meta packages actually work.
<ogra> seb128, so i had some hope :)
<seb128> ogra: right, but no move from upstream, they have some manys bug and so few people for them :/
<mvo> nomed: I'm not sure about this because I think even then the order may be important
<ogra> yep, understood ...
<mvo> nomed: let me play with my python-apt based idea
<infinity> Anyhow, for now I'm just going to band-aid over it.
<ogra> but i'm not really fond of changing to another mailer, i like evo ...
<nomed> infinity, you could test
<infinity> For edgy, we need to mangle how we do livefs stuff a bit, I think.
<nomed> apt-gte install xubuntu-desktop xterm ?
<nomed> infinity, if for edjy smart-pm will be in main ...
<nomed> that issue is gone
<infinity> Yeah, the bandaid appears to do the right thing for now.
<infinity> nomed: While your enthusiasm is appreciated, I have a hunch that for every apt bug smart fixes, it'll bring a new bug of its own instead.
<infinity> I don't doubt that switching will be a wonderful thing at some point, but I'm in no rush to trade the bugs I know for the unknown either. :)
<nomed> i understand :)
<infinity> janimo: Want me to build you new live images with the reduced package set?
<janimo> infinity: reduced?
<infinity> janimo: Without libgnome and crap. :)
<janimo> ah :) , it can wait till next cron if you think it works :)
<janimo> thanks
<infinity> I'm not positive, but I think so...
<janimo> ok, please build then so we make sure it does not come up tomorrow or on Monday
<infinity> Alright, spinning livefs builds.
<janimo> thanks for debugging it. I still wonder why this is the case since the abiword change is in for about two weeks I think, and noone reported this before
<janimo> and IIRC when it just depended on libgoffice w/o the alternate it brought in >50Mb worth of gnome stuff not jjust these libs
<nomed> janimo, would it be an idea to set the xubuntu gtk theme in gdm ?
<janimo> nomed: which theme would that be?
<janimo> clearlooks?
<nomed> yes
<nomed> well ..
<janimo> I guess we should set it
<nomed> the one that we use 
<janimo> is the theme visible in the gdm screen?
<nomed> yes
<ogra> janimo, btw, how did you work around the fact that ldm depends on a ton of gnome libs ? 
<janimo> ogra, does ldm dep on gnome libs?
<janimo> if so I guess I'll have to revert the LTSP stuff :(
<janimo> did not know I thought it's a simple python script w/o deps
<janimo> I did not check before
<janimo> nomed: so replace GtkTheme=Human right?
<nomed> yes
<ogra> janimo, Depends: openssh-client | ssh, python, python-gtk2, python-gnome2, python-glade2, gtk2-engines-clearlooks, xserver-xorg | xserver-xfree86 | xserver
<janimo> nomed, are you working on gdm icons? If so I can make the change in the same upload
<nomed> janimo, python-gnome2
<nomed> janimo, i can do that 
<janimo> ogra: oh well, I guess then no LTSP/xubuntu :(
<janimo> what is used from python-gnome2? canvas?
<ogra> janimo, we *might* switch to gdm on edgy, seems it has a ssh mode now
<mvo> infinity: http://people.ubuntu.com/~mvo/stable_inst.py <- should give you a stable way to install
<ogra> janimo, yep, ldm is 95% gnome-canvas and 5% magic
<infinity> mvo: And if I want to use it in a chroot?  Can I point it at another apt root?
<janimo> ogra, I wish gnome-python did not bind the whole gnome libs in one binary package :(
<mvo> infinity: do you currently run with lots of "-o Dir::State=/chroot" etc options?
<ogra> janimo, well, nothing we can change now
<janimo> ogra, true
<infinity> mvo: No, right now I just cheat and do "chroot target/ apt-get install ..."
<infinity> mvo: But since I don't want your python script or python-apt in the chroot. :)
<mvo> infinity: run the script outside the chroot and just use the package names it spits out :)
<infinity> mvo: Oh, it'll give me the "correct" install order?
<infinity> mvo: Cool.
<infinity> mvo: (Obviously, I hadn't actually run it yet)
<mvo> infinity: that reminds me, I should probably get rid of the ugly progress message
<mvo> infinity: it first goes over all dependencies and marks them for install *without* letting the autoInstaller or the fixer do anything. then it runs the fixer and let it deal with it. should be fine for the metapackages and cases like this
<mvo> I think it should bprobably be done in apt in a similar way
<infinity> mvo: Err, no.  Running it outside the chroot won't help, since it needs to use the available/status from the target. :)
<infinity> mvo: So, yeah, I need a bunch of -o parsing, which I don't see it doing.
<mvo> infinity: ok, we can point it via apt_pkg.Config.Set("Dir::" to the right location. or you just install the very usefull python-apt in the chroot ;) 
<infinity> I don't feel the urge to install python-apt in the livefs target and them remove it again at the end. :)
<infinity> Ideally, this should all be done from the base system.
<infinity> mvo: However, Dir:: is a constant, so it doesn't need to be done from the command-line.  I can just hardcode it and wrap this into the livecd-rootfs package for future use.
<mvo> just kidding, I see the point
<infinity> (All for edgy, of course... I'm not changing anything this drastic at this point)
<infinity> Right now, I'm "happy" with hackish workarounds.
<infinity> And by "happy", I mean "miserable".  :)
<mvo> infinity: try the updated version http://people.ubuntu.com/~mvo/stable_inst.py
<infinity> +# first argument is the chroot
<infinity> That's a complete lie.
<infinity> You don't parse it as an argument at all. :)
<infinity> (Not that you need to, I'm fine with the hardcoded version)
<mvo> infinity: I intended to at first ,)
* mvo makes a mental note to not write comments again
* infinity grins.
* mvo updated the comment in his source and updated
<infinity> The only thing worse than uncommented code is commented code where the code and comments don't match. :)
<mvo> infinity: that is totally true!
<lifeless> infinity: that can be usefulu actually :)
<infinity> Well, now, that comment isn't very nice at all.
<infinity> JERK.
<lifeless> because it can signal something needs fixing :)
<mvo> infinity: fixed again, now you can pick what project this one belongs to
<jordi> tsdgeos: pong
<nomed> janimo, ping
<infinity> Man, the comment keeps changing, but the code never does.  ENTERTAINMENT.
<janimo> nomed: pong
<nomed> janimo, that theme is absurd ...
<nomed> icon-shutdown-active.png
<nomed> icon-shutdown.png
<nomed> icon-shutdown-prelight.png
<nomed> ?
<nomed> what's that ?
<janimo> different icons for different states of the button (mouse hovering over it, clicked, inactive)
<nomed> why don't we use just one ?
<nomed> janimo, true if they were different icons
<janimo> we can use one, as the 3 are exaclty the same right now
<janimo> nomed, yes feel free to use one
<nomed> k
<mvo> infinity: the code is PERFECT
<mvo> its just the comments that need love
<janimo> ogra: what is this landscape package? do I need to add it to xubuntu :) ?
<ogra> janimo, you should (its empty anyway) see apt-cache show landscape-client
<infinity> mvo: Heh. :)
<janimo> ogra, any LP links for Landscape yet?
<nomed> janimo, and if i use absolute paths ?
<ogra> dunno, i didnt follow the development very closely
<nomed> so i remove all those icons :P
<janimo> nomed, we should not cannot depend on a theme...
<zul> heylo
<janimo> if it's not there the icons won't show up
<mdke> janimo: you know, it struck me that you could include the server and packaging guide in xubuntu-docs if you wanted. Maybe it's a bit late
<nomed> janimo, why doesn't xubuntu-default-settings depend on any pkge ?
<janimo> mdke, if I do another docs upload I'll try to keep this in mind
<janimo> mdke, although we have no prominent place for showing the docs, the desktop guide is linked from the about page
<nomed> janimo, it has to depend on
<mdke> janimo: yeah, you'd have to add it there, I suppose. Anyway, I'll leave it to you
<janimo> nomed: it des not need to dep on gdm
<nomed> Human if we use Human as gtk theme i guess
<nomed> or on xubuntu one if we use xubuntu one ..
<seb128> janimo: you are really obstined on that thunar bug :/
<janimo> seb128: no, I just do not understand your comments
<janimo> seb128: and you are not actually saying anything about the real issues upstream brought up
<seb128> janimo: grrrrr
<seb128> I explained you how all that works like 5 times now
<janimo> seb128: ok question.
<seb128> THAT IS NOT A MIMETYPE, STOP USING IT
<janimo> seb128: should Places be openable by anything but nautilus?
<seb128> yep
<seb128> by the default "x-directory/normal" handler
<janimo> seb128: how can that be set?
<janimo> ok
<seb128> x-directory/normal=app.desktop to defaults.list
<seb128> I already explained that on IRC and on the bug
<lmanul> janimo: give seb128 a break or he'll really hate you ;-)
<janimo> that is set by both nautilus and thunar right?
<janimo> lmanul: too late :)
<nomed> seb128, question.
<nomed> what does it happen if gdm doesn't find the gtk theme ?
<lmanul> janimo: Hehe, well, maybe try to print out the IRC log and read it a few times ? :)
<seb128> janimo: nothing is "set" by them, they both can open x-directory/normal yes, the default is set by the defaults.list
<janimo> lmanul: printers do not work in xubuntu, I cannot do that
<janimo> seb128: so if there are two handlers, why does gnome not use them?
<lmanul> janimo: then just read it on the screen :-p
<seb128> janimo: because you "hijack and break" that mimetype mechanism by using a private namespace fallback
<janimo> seb128: cannot be that prvate if firefox is using it?
<seb128> stop with that now
<seb128> stop claiming that firefox use it
<seb128> or prove it
<janimo> seb128: and again. I do not hijack or break anything. Remember this is upstream thunar behavior. I'd rather you fight it out with upstream developer rather than
<seb128> that's a free claim without any technical backup
<janimo> forcing me to make a change which I do not fully understand the risks of
<seb128> I'll not force you to do anything
<seb128> I'll fix it myself
<janimo> seb128: well that's the same thing
<seb128> GNOME is the default desktop and better to have xubuntu than Ubuntu broken, that you like it or not
<janimo> seb128: are you sure you will not break firefox in xubuntu?
<janimo> seb128: oh really? how technical is that answer?
<janimo> and gnoome is NOT BROKEN!
<seb128> it is
<janimo> user installs thunar then complains it opens it's places
<seb128> thunar hijack the directory opening
<janimo> do notr install it then
<seb128> grumpf
<mdke> that's definitely a bug.
<azeem> make nautilus Conflicts: thunar
<seb128> what about reading what I explained you like 10 times now on how mimetype association work?
<janimo> really , I'd rather make thunar conflict with nautilus than make a change which can affect the default xubuntu install
<mdke> konq was doing the same at one stage, thanksfully it was fixed
<seb128> a directory is x-directory/normal
<seb128> you can discuss with kubuntu guys, not with xubuntu team it looks like
<janimo> seb128: I asked you to please answer the points upstream thunar is rainsing rather then repeating the same arguments _to me_
<seb128> that's noted for next time they need something
<seb128> I already wasted 1 hour explaining again and again the same thing
<janimo> I am not thunar usptream have only a avgue idea how the mime system works 
<seb128> janimo: I commented on the bug
<seb128> and upstream has not point
<janimo> so I am not comfortable doing osmething because you claim it breaks gnome, since I know you don;t care at all if it breaks xubuntu
<seb128> it looks like they rather don't know how the freedesktop mimesystem work
<janimo> so please answer the points brought up by thunar upstream and I am fine with whatever you two decide
<seb128> I REPLIED
<janimo> but do not make me do a change or threaten to do it yourslef without being sure of it's consequences
<seb128> I don't threaten
<seb128> I inform you I'll fix that bug if you don't
<janimo> seb128: you did not reply. A reply is when what you say is connected to what previous comment said
<seb128> they didn't say anything
<seb128> they say "firefox might use it"
<janimo> seb128: ok if firefox does not use it  or it does not break anything I am fine with any fix you make
<infinity> What's the bug here?
<janimo> thing is you don;t know if that;s the case and you don;'t care. So your fix may cause other bugs
<janimo> infinity: bug 35997
<Ubugtu> Malone bug 35997 in libgnome "Gnome's Places menu starts Konqueror instead of Nautilus" [Unknown,Unconfirmed]  http://launchpad.net/bugs/35997
<seb128> infinity: thunar listing itself as an app opening "x-directory/gnome-default-handler", where "x-directory/gnome-default-handler" is not a mimetype but something internally defined by gnome-vfs as a fallback mechanism
<janimo> infinity: at the end, since it's an older bug that has a new duplicate
<janimo> seb128: 'fallback mechanism' implies there are no alternatives right?
<janimo> so if there are two default handlers and they are not used I would not call it fallback...
<seb128> janimo: it implies what I explained before, if no app is defined to handle "x-directory/normal" gnome-vfs force one
<seb128> janimo: it should be set only if there is no x-directory/normal handler since it hijacks x-directory/normal when set
<janimo> seb128: dont' nautilus and thunat both handel x-directory/normal
<janimo> ?
<seb128> janimo: THAT'S WHY YOU SHOULD NOT SET IT
<janimo> seb128: it's not a fallback then
<seb128> IT SHOULD BE SET IF NO APP HANDLE THAT TYPE ONLY
* ogra holds his ears
* mdke too
<seb128> janimo: it's a fallback in the sense it's set and used only if there is no x-directory/normal handler
<zul> cant we all just get along?
<seb128> zul: no, thunar breaks GNOME and janimo will not fix the bug for whatever reason
* mdke gives ogra his ears back
<janimo> seb128: do you have any docs about how this private thing is suppoed to work
<ogra> heh
<seb128> janimo: no, it's private stuff, not public API documented
<janimo> I cannot further discuss this since we are not getting anywhere
<seb128> janimo: it's supposed to NOT be used
<nomed> ogra, what does it happen if gdm can't find the gtkTheme ?
<ogra> it falls back to the one in gdm.conf 
<infinity> janimo: seb128 is right here.  You shouldn't be using the GNOME handler.
<seb128> janimo: right, you seem to have no knowledge of the mimetype mechanism nor and will not listen to what people explain
<ogra> if there is none found either it falls back to HappyGNOME or something
<janimo> infinity: I am not disputing that, I'd rather that instead of yelling at me he commented the exact same things in LP
<nomed> ok ...
<janimo> seb128: I am listening but not before making sure your fix does not cause more breakage
<infinity> janimo: He has, as far as I can see in the bug log.
<nomed> so it doesn't need to depend on any gtk theme true ?
<janimo> infinity: ok, it means I am really that clueless what can I say.
<seb128> janimo: I tried my best to explain you that's right, what about try on your xubuntu and let me know if you face any issue?
<janimo> seb128: I will
<seb128> janimo: do it now and not after dapper please then
<seb128> instead of saying again and again it might break something and that you refuse to do the change because of that
<infinity> janimo: In the upstream bug, upstream says" If software (like
<infinity> gnome-panel) wants to use nautilus, it should simply run nautilus.
<infinity> x-directory/gnome-default-handler is not garantied to be nautilus; in fact that
<infinity> would be really useless. Instead it's the user's preferred file manager."
<seb128> gnome-panel doesn't want to run nautilus, it wants to run the preferred handler for x-directory/normal
<ogra> nomed, oh, sorry, i misread ... i thought youre talking about the GDM theme
<infinity> janimo: Respond, and let them know that x-directory/gnome-default-handler is the default *GNOME* file manager fallback, but x-directory/normal is the *default file manager*.
<nomed> ogra, yes and not ..
<nomed> :)
<ogra> no idea how it handles a missing gtk theme 
<ogra> i guess it falls back to the default widget set
<infinity> janimo: He seems to not know about x-directory/normal, since he earlier states "x-directory/gnome-default-handler is, as
<infinity> the name suggests, the default handler for directories (should be renamed to
<infinity> something w/o 'gnome' in its name to avoid confusion)"
<infinity> (Which is wrong)
<nomed> ogra, i see edubuntu-artwork depends on gdm
<seb128> (cf my comment on lp from "2006-05-27 10:40:15 UTC")
<infinity> It has gnome- in the name, specifically because it IS gnome-specific.
<janimo> oh I wish one of yoou commented on that bugzilla instead of me proxying
<seb128> "That works for any mimetype. A directory is from "x-directory/normal" type, setting a default is only usin "x-directory/normal=app.desktop" to the defaults.list"
<ogra> nomed, yep
<infinity> janimo: That would involve signing up for another bugzilla. :)
<janimo> infinity: I know that;s why I am not asking you to :)
<nomed> janimo, shouldn't xubuntu-default-settings depends on gdm too ?
<janimo> but thing is I am caught between upstream and ubuntu on a matter I know too little about
<janimo> to be convinced by either
<janimo> being threatened or yelled at does not help in such cases
<janimo> quite the opposite actually
<janimo> nomed: no it can work w/oo gdm
<seb128> I yell because you ask again and again the same questions and I already replied to them
<infinity> janimo: I'm not yelling at you.  I'm not French.  :)  I'm just telling you that seb128 is right.
<infinity> seb128: Enjoy it while it lasts, I'll decide you're wrong about something else tomorrow. ;)
<seb128> I've enough bugs to reply to, to not explain myself 5 times on that one
<seb128> infinity: hehe ;)
<seb128> janimo: what you are saying is "I'll not fix the bug because I don't know how to fix it, and I'll not let you fix it because I don't trust you to not break xubuntu"
<seb128> janimo: which is basically "I'll not fix that for dapper"
<infinity> Argh, where's pitti?
<ogra> just make thunar conflict with nautilus ... :P
<janimo> seb128: no, I say I am not going to fix it before I am convinced it's an actual fix
<infinity> seb128: Do you know anything about pitti breaking the poppler ABI?
<janimo> seb128: it will be sorted by dapper one way or another
<seb128> infinity: yeah, cf devel list
<nomed> if it helps i may test it on a livecd (?)
<infinity> seb128: Yeah, I meant "anything more than that". :)
<seb128> infinity: we decided that tetex-bin rebuild is the way to go, all the other packages using poppler have been rebuilt since
<seb128> infinity: but mdz didn't reply to my "ok to rebuild it now before dapper"
<seb128> janimo: are you aware that it might be too late for changing for dapper already?
<janimo> seb128: no, it's not
<seb128> janimo: if you decide you will no fix it and that we have to change gnome-vfs it's probably
<janimo> if it were how did you want to fix it today?
<janimo> seb128: no worries it will be fixed in thunar.
<seb128> lol
<infinity> seb128: But we habe a different ABI from Debian now, with the same package name and same SONAME.
<seb128> the only way you have to change that to thunar is what I said
<infinity> seb128: That's double-plus ungood, in my books.
<seb128> infinity: 
<seb128> mai 26 18:25:10 <mdz>	pitti: if packages were built with the changed libpoppler they might need to be rebuilt
<seb128> mai 26 18:25:10 <seb128>	pitti: because if the ABI change we probably want to revert it, no?
<seb128> mai 26 18:25:13 <pitti>	seb128: TBH, rebuilding the rdepends seems safer to me
<seb128> ...
<seb128> mai 26 18:26:12 <seb128>	pitti: but we make us binary incompatible with rest of the world then?
* ogra wonders if its orwell year this year, everybody uses double-plus recently
<seb128> ..
<seb128> mai 26 18:27:33 <pitti>	seb128: is that an issue? if so, well, then we can revert the bug fix, too, but I wouldn't be so happy about reintroducing a bug
<seb128> infinity: that's from yesterday
<infinity> seb128: Thanks.
<seb128> np
<infinity> seb128: Oh, we may be saved.  Our poppler SONAME is already different from Debian's.
<infinity> And binary compatibility with the rest of the world is less of a concern for me.
<seb128> I think they have a new poppler version with the same soname to NEW atm
<nomed> janimo, ping me when you'll have 2 min ...
<janimo> nomed: now
<nomed> ok
<infinity> seb128: I can contact Ondrej and ask him to include our patch before it clears NEW, thus sidestepping the problem. :)
<nomed> we're not using the gtk theme (?)
<janimo> anyone besided fabbione know why ubnutu and kubuntu-devel irclogs are collecting the whole past week?
<seb128> infinity: right ;)
<janimo> nomed: where?
<nomed> i do not see the xubuntu gtk theme based on ubuntu-looks
<nomed> didn't jmak send it to you ?
<nomed> or jmack .. i don't remember the nick 
<janimo> nomed: no the deafult remains clearlook
<janimo> that theme he sent was incomplete
<janimo> too late to change that now, it remain clearlook
<nomed> he could just tell me 
<janimo> he sent the themes to the list and noone else commented on them
<nomed> i could even complete it ..
<janimo> nomed: is the current one not good enough?
<nomed> i think to use cairo ..
<nomed> we could use ubuntu-looks
<nomed> that's much better
<zul> janimo: all the logs are doing that
* infinity ICQs Ondrej and bugs him about poppler in Debian.
<janimo> zul, and is it intended?
<nomed> janimo, then ..
<seb128> ok, time for some non-ubuntish activities for a change, bbl
<ogra> janimo, that we have backlogs for 2 years form all channels ? sure, why shouldnt we log if we dont keep them
<nomed> if it 's possible to set xubuntu-default-settings Depends: tango-icon-theme
<ogra> s/shouldnt/should/
<janimo> ogra: I mean in the same file
<nomed> i could use abs paths within the gdm xml
<nomed> that's for icons ..
<janimo> ogra: there are no daily channel logs for the past week, only one beeg weekly log
<nomed> in this case i guess we do not need to add licences for the icons used
<nomed> as they are cc
<janimo> nomed, it's ok as it is now, the license is not problem
<janimo> it would be too much work at this stage for little gain
<janimo> so we either leave the theme as it is now, or replace those 2 icons
<nomed> so i'll not change those icons
<janimo> and set theme to Clearlooks if you think it's better tha human
<nomed> let's keep that pkge as it is
<janimo> nomed: ok
<ogra> JanC, no idea, you need to ask fabio
<ogra> janimo, ^^
<janimo> ogra, yes that why I started with does anyone besided fabbione know ;) ?
<bddebian> Howdy folks
<zul> hey fabbione how is the uk?
<Diskdoc> I'm back.. Can't seem to find any other channel more suited for Ubuntu RC bugtesting..
<fabbione> zul: exactly like i left it last time.. warm and wet
<zul> hmmmm...sicko...:)
<ogra> fabbione, did you ever get your dvb-t card to work ?
<fabbione> ogra: i don't have a dvb-t card yet
<fabbione> only a boring analog tv
<ogra> ah, k 
<ogra> i'm still struggling here
<fabbione> planning to shop for them after release
<fabbione> i have some issues... but i am nto sure if they are nv / nvidia related.
<ogra> seems my usb adapter is recognized fine after dropping the firmware into /lib/firmware ...
<janimo> fabbione: hi, are the irc logs supposed to not have daily dumps?
<ogra> but i always get "tuning failed" messages
<janimo> this channel's runs back a week already
<fabbione> ogra: mine doesn't need fw
<fabbione> janimo: they are supposed to be updated hourly and the script rotate on daily
<ogra> well, i want to use it on a leptop so i needed to buy a usb one ...
<fabbione> ogra: no i will buy PCI, but only after i test the analog one properly
<fabbione> i want to make sure that it is not a v4l2 issue
<fabbione> i solved the vbi one.. it was a bug in udev
<ogra> analog works fine for me, the prob is only that analog tv will be switched off germany wide this month
<ogra> dvb doesnt use v4l so i'm safe on that side :)
<fabbione> whops
<fabbione> janimo, Riddell: the logs are ok the bot.. checking the connection to the DC
<fabbione> at least they are not lost :)
<azeem> W 44
<azeem> oops
<fabbione> janimo, Riddell: ok fixed. It was an error in the daily rotate script. Can you please remind me after release to process the logs for the missing days?
<janimo> fabbione: will try to remember :)
<fabbione> janimo, Riddell: they are not lost.. they just need an upload
<fabbione> but i am far from the server and bw is not fast for these kind of hacks
<fabbione> -current anyway are good
<Diskdoc> If I find bugs in the Dapper RC that are already noted (though not resolved) for an earlier version of Ubuntu - should I post the bug again (as concerning Dapper/RC) or just add a note at the existing bug? I'd guess at the latter..
<ogra> add a note
<sladen> Diskdoc: don't duplicate bugs, but do update it
<fabbione> reopen the bug, increase severity and add tag REGRESSION
<fabbione> hey sabdf1 
<bddebian> Hello sabdfl
<sabdfl> hey hey fredom lovers
<sabdfl> s/fre/free/
<mdke> happy saturday
<zakame> hi all
<zakame> hi sabdfl 
<Diskdoc> Ok, thanks. This old PC I'm trying it out on has a strange twist to it, btw. Seems DMA (and block access maybe) has to be disabled for the CD-ROM in the bios AND at kernel boot with ide=nodma
<Diskdoc> Though when the desktop-CD has booted I can turn on everything with hdparm again
<zakame> fabbione: hi!
<fabbione> hey zakame 
<bddebian> Heya zakame
<fabbione> zakame: how is your X thingy going?
<fabbione> zakame: infinity and I are planning the work for 7.1
<pitti> hi
<fabbione> zakame: and i would really really love to see you involved
<fabbione> hey pitti 
<bddebian> Hello pitti
<zakame> fabbione: It's going great! I'm still ploughing over the drivers list, but I seem to have managed =)
<fabbione> zakame: great
<zakame> fabbione: ooh! so do I! :D
<fabbione> zakame: the idea is simple...
<fabbione> zakame: as soon as edgy will open, we will merge 7.0 from debian and sync the packaging
<fabbione> zakame: once that's done we will bump to 7.1 (if debian isn't there yet)
<infinity> fabbione: Ahh, you're recruiting lackeys.  Good, good. :)
<fabbione> infinity: zakame is learning :)
<zakame> hmm I remember aba (or was it hmh) saying something about it on #d-devel
<fabbione> infinity: so we will need to drive him a bit but i am sure he will do a great job
<zakame> infinity: LOL!
<zakame> fabbione: thanks! :)
<bddebian> Hmm
<lifeless> gnight
<infinity> Oh, and anything that even vaguely mentions "mesa", I suspect you two should just leave to me, since we're forked so far from Debian it hurts.
<fabbione> lifeless: night
<infinity> I'll try to sort it all out early on.
<zakame> gn8 lifeless 
<fabbione> infinity: we will need a new mesa from upstream anyway
<bddebian> gnight lifeless
<infinity> Yeah, but the packaging is horibly forked, I mean.
<fabbione> infinity: otherwise a lot of features in 7.1 will be null
<fabbione> infinity: yeah that too
<infinity> I'll have to mangle the packaging a bit before we bump to new upstream.
<lifeless> ~
<infinity> (And get some mangling fixes back into Debian while I'm at it)
<fabbione> infinity: we can work in parallel to get all the pkging sorted and later we bump upstream
* infinity nods.
<infinity> That sounds ideal ot me.
<infinity> to, as well.
<bddebian> And fix xmkmf too? :-)
<fabbione> infinity: you and I can do protos, libs and drivers/server and zakame can start stretching his wings on the apps that have less disaster impact
<infinity> fabbione / zakame: When we do this, I'll want us to keep a running list of everywhere where our packaging is forked (not patches, but hacks we need to make in debian/control for smooth transitions, that sort of thing)
<zakame> bddebian: yeah! I remember that Xp6 dependency bug again...
<infinity> fabbione / zakame: I can then take that list and try to get all our hacks back into Debian as well.
<bddebian> zakame: :-)
<fabbione> infinity: i think while we do the batch work we should sit in a quiet irc channel and track everything
<fabbione> infinity: patches and packaging
* infinity nods.
<fabbione> infinity: get daniels to commit patches and you to push pkging
<bddebian> I suppose asking if I could provide any help would be fruitless?
<infinity> I'll happily invite vorlon, gravity, and daniels to idle in that same channel, so they can pipe up if something seems "not right" from their end.
<fabbione> bddebian: how much do you know about X?
<infinity> (Or just ignore us entirely, their choice)
<fabbione> infinity: yup i agree
<fabbione> bddebian: zakame has been learning just how to build X for the past 2 weeks to be able to help..
<zakame> fabbione / infinity: ok!  I'll add that to the list :D
<fabbione> bddebian: and this transition has to go very fast in.
<bddebian> fabbione: Not as much as I would like to
<fabbione> infinity: zakame is preparing a schema to track a bunch of data already
<fabbione> infinity: on my input..
<fabbione> infinity: i am sure he can add more since he got it written down already
<infinity> fabbione: We have some small things to transition to get back in sync (Debian chose a more FHS-compliant font directory scheme than Daniel originally did, for instance), but most of it looks pretty smooth.
<zakame> yeah, I remember already putting down the x11-proto libs in pastebin
<fabbione> bddebian: i am sorry but X is a commitment that i am not going to give out to sporadic help. It's a "package" that requires dedication and constant attention
<fabbione> bddebian: and to several degree also a deep knowledge
<zakame> I'll be putting the list up on tiber once they're done (which is very very soon :D)
<fabbione> bddebian: if you are keen to learn good, but sporadic will get you nowhere
<ogra> btw, was there a final decisio if we upgrade nvidia drivers before release ?
<bddebian> fabbione: No problem.  Offer stands if I can do anything.  ANd yes I would learn but I seem to irritate you for some reason. :-)
<mvo> mdz: permission to upload a update gnome-app-install? updated desktop files and two (small) fixes?
<zul> bddebian, iritating fabbione is fun though :)
<fabbione> bddebian: eh??? no it's nothing like that.. i need people with commitment.. if you are keen to learn I am glad for you to join the team
<fabbione> bddebian: what i am asking you is to think about it before you offer for something that's pretty big and time consuming
<bddebian> Well the only reservation I would have is that we seem to keep losing good people from Universe to main. :-(
<bddebian> Not that I'm "good" per se, but I hit a lot of packages for Universe
<fabbione> zul: shusshhh'
<zakame> hehe
* bddebian notices infinity's silene too :)
<bddebian> Err silence even
<pitti> mvo: ah, just reading your u-m changelog. thanks for fixing the removal of obsolete packages
<pitti> mvo: do you have any idea about the missing l-support-en?
<mvo> pitti: cheers, thanks for spotting it in the first place
<mvo> pitti: I suspect a dependency problem in OOo, but i need to investigate
<infinity> What's this about OOo dependency issues?
<infinity> This doesn't have anything to do with the fact that I just noticed (like 10 minutes ago) that openoffice.org Conflict with openoffice.org2 (unversioned), while the latter depends on the former?
<infinity> I wish I'd noticed that YESTERDAY, so I didn't have to upload again to fix that upgrade path... *sigh*
<mvo> infinity: one of the language support things, its only a theory now, not a known fact
<infinity> mvo: Oh, so a different bug.  Great.
<infinity> mvo: I need to upload OOo again for the above, so can you find out for me if it's also buggy in some other way, so I don't have to upload twice? :/
<mvo> infinity: ok, I'll invetigate now
<doko_> infinity: please wait with the next OOo upload; have to fix an upgrade error as well
<infinity> doko_: You mean other than this "can't upgrade from breezy at all" error? :)
<doko_> infinity: yes
<infinity> doko_: Mmkay.
<Kamion> Seveas: please do not mark ubiquity bugs as duplicates; you're getting it wrong
<Kamion> Seveas: (there are multiple reasons why the bugs you're marking as duplicates might appear)
<Kamion> Seveas: please leave ubiquity bugs to me
<Kamion> (at least, you're potentially getting it wrong; from the evidence, there is insufficient proof)
<Riddell> thank fabbione 
<ogra> fabbione, is there any equivalent to IgnoreEDID in the nv driver ? 
<fabbione> man nv
<ogra> seems i cant get widescreen resolutions at all with nv ...
* fabbione -> beer
<ogra> only nvidia works
<ogra> fabbione, enjoy ! :)
<Riddell> carlos, jordi: here's a fun thread for you http://lists.kde.org/?t=114872530400008&r=1&w=2
<Seveas> Kamion, sorry, I thought I only picked exact duplicate traces
<infinity> doko_: Can you push your fix to me ASAP?  As soon as mdz gives me an okay on this, I want to get it up and built so the buildds and archive have settle before eveyone gets back to work on Monday.
<Seveas> I wouldn't dare touch ubiquity bugs except exact duplicates
<Diskdoc> Testing out the RC Desktop-CD. Now partitioning in expert mode - where are the raid options?
<infinity> mdz: Ping.
<doko_> infinity: sure, let me do this tonight, have to go shopping now
<infinity> doko_: Okay, I have to sleep soon anyway, but I'll be hoping to see it in my INBOX when I wake up. :)
<doko_> infinity: sleep well ... and long ... ;-P
<mdz> infinity: pong
<mdz> what's up?
<infinity> mdz: http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html
<mdz> mvo: diff for g-a-i update?
<infinity> mdz: As it turns out, those uninstallables aren't an archive problem (as we suspected, and thus did nothing about), but rather broken unversioned conflicts between openoffice.org-* and openoffice.org2-*
<mdz> infinity: the oo.o2 thing? that's been there for ages
<mdz> aha
<infinity> mdz: Permission to upload (yet again, yay!) to fix that, so upgrade without ubuntu-desktop installed won't explode? :)
<mdz> infinity: yes...whichever of you or doko makes the fix, the other should eyeball it before building
<mdz> infinity: going to take fabio out for a drink; please SMS at the number in the wiki and let me know how it turns out
<infinity> mdz: I'll test it locally too, to make sure I get it right the first time.
<infinity> mdz: The upload will be in ~10-12 hours, no need to SMS you.  (I need to sleep, and doko's sitting on another upgrade fix too)
<infinity> mdz: Happy drinking.
<zakame> ~[6~[6~/wind 2
<jordi> Riddell: fantastic
<sladen> mdz: I've sent a fix to 'acpid' to the queue to stop it shutting down after displaying the logout dialogue in GNOME
<mvo> mdz: http://people.ubuntu.com/~mvo/gnome-app-install_0.1.32.debdiff (is big because of the desktop file updates)
<_ion> Bug #46935
<Ubugtu> Malone bug 46935 in linux-meta "System hangs when using ltserial, ltmodem, /dev/ttyLTM0" [Normal,Unconfirmed]  http://launchpad.net/bugs/46935
<Riddell> jordi: are there any long term plans to sync translations between rosetta and upstreams?
<tsdgeos> Riddell: jordi is gone
<tsdgeos> or he lied me :D
<mdke> Riddell: if the upstream uses rosetta, then the answer is yes
<mdke> Riddell: if you're talking about Ubuntu translations in rosetta, the answer is no, as far as I know.
<mdke> (translators need to forward their stuff)
<jordi> ok I will be killed by the gf
<jordi> Riddell: there's a midterm plan to import KDE and GNOME SVN and only the KDE translators and GNOME translators members will be able to translate
<jordi> that, and translation multicasting will ease the problem
<jordi> but I *really* need to disappear now
<mdke> have fun jordi 
<Riddell> thanks jordi 
<green-mouse> Hi, what is ubuntu politics about including kernel paches in to "official" kernel image... I have laptop with centario proccesor, and cpufreq dont`t work without some paches... this is possible to include this pach to official kernel?
<infinity> green-mouse: We have plenty of patches for centrino cpufreq stuff.  Which cpu specifically doesn't work with out kernel?
<green-mouse> infinity, model name      : Intel(R) Pentium(R) M processor 1.73GHz
<green-mouse> infinity, i use linux-phc-0.2.4 patch...
<infinity> green-mouse: Have you actually tried our kernel (apt-get install linux-686) in dapper, with the powernowd also in dapper?  It should work fine.
<green-mouse> infinity, i use dapper
<green-mouse> infinity, i have linux-686 package installed...
<carlos> Riddell: About the German translators... it was due the missing translations we got becuase the problem with kde-i18n-de package
<carlos> Riddell: Ubuntu translators already asked me to revert the modifications and move them back to KDE ones
<carlos> Riddell: but I hadn't time to do that yet
<green-mouse> infinity, Linux green-mouse-laptop 2.6.15-23-686 #1 SMP PREEMPT Tue May 23 14:03:07 UTC 2006 i686 GNU/Linux 
<green-mouse> infinity, and cpufreq works only after patch applying...
<mjg59> green-mouse: What patch?
<mvo_> pitti has left the building?
<green-mouse> mjg59, linux-phc-0.2.4 patch...
<infinity> green-mouse: Okay, PHC isn't the same thing as the kernel's generic cpufreq interface (thoug it hooks into it, it looks like)
<mjg59> green-mouse: Where can we find that?
<infinity> http://sourceforge.net/project/showfiles.php?group_id=161063
<mjg59> And how are you trying to control the cpu frequency?
<infinity> http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU
<infinity> mjg59: ^^^^
<mjg59> Oh. So crack.
<green-mouse> mjg59, http://linux-phc.sourceforge.net/
<infinity> Yeah, it's completely orthogonal to the cpufreq support we ship that SHOULD work on his CPU.
<mjg59> That's not cpufreq
<sladen> green-mouse: do you have busted ACPI on your machine?
<green-mouse> sladen, yes
<infinity> green-mouse: That's a tweaker's interface for {under,over}volting and {under,over}clocking, not the same as plain old cpufreq.
<Robot101> mjg59: not at the fest'o'beer?
<sladen> green-mouse: the only reason for overriding a power/voltage scaling table is if the table supplied by the ACPI BIOS is incorrect
<sladen> green-mouse: right, so the actual problem is another one.
<sladen> green-mouse: in which case, $lots of other stuff probably doesn't work on your machine either
<green-mouse> infinity, ok... maybe cpufreq broken in ubuntu kernel....
<green-mouse> i appyd this path on vanilla kernel...
<ogra> green-mouse, sladen just explained it to you ... it has nothing at all to do with cpufreq
<sladen> green-mouse: so, what you're doing is adding an override for your CPU (with incorrect voltages, but which are close-enough that they might work)
<green-mouse> ok... in ubuntu kernel: modprobe speedstep-centrino
<green-mouse> FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.15-23-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): Invalid module format
<infinity> (base)adconrad@cthulhu:~$ lsmod | grep speedstep
<infinity> speedstep_centrino      8752  1
<infinity> freq_table              4928  2 speedstep_centrino,cpufreq_stats
<infinity> processor              26344  2 speedstep_centrino,thermal
<sladen> green-mouse: yes.  Dude, it gets the voltage/scaling pairs from ACPI.  Your ACPI is busted.  There are no voltage/scaling pairs to use, so it bombs.
<infinity> Works here (obviously)
<infinity> "Invalid module format" is a pretty iffy way to fail, though.
<sladen> green-mouse: please can you file a bug against 'acpi-support' and we'll debug a solution for you there
<ogra> infinity, <green-mouse> i appyd this path on vanilla kernel...
<ogra> green-mouse, are you currently running that patched kernel ? 
<sladen> infinity: valid point... that *is* an interesting error message
<green-mouse> ogra, not
<green-mouse> ogra, now this is ubuntu kernel
<infinity> sladen / mjg59 : Do we have a HOWTO anywhere for hacking /etc/mkinitramfs/DSDT.aml for people with ACPI issues?
<infinity> That's likely what this dude needs.
<sladen> infinity: I don't think so.  Could really do with one, rather than sending people off to the Gentoo documentation
<infinity> I didn't say the HOWTO had to be OURS.  Just any HOWTO will do. :)
<infinity> (Though our own would be nice)
<sladen> infinity: which (while fixing it admittedly) also included a respray, aerofoils, go faster strips and alloy hub caps
<green-mouse> ok, from there we start? Have centario CPU and speedstep not work for me.... what infomation you need to debug this problem?
<sladen> infinity: the acpi.sf.net one;  but most of that still encourages people to patch their kernel, concat onto initrd.gz ... rather than copying it into /etc/mkinitramfs/
<sladen> green-mouse: launchpad.net/distros/ubuntu/+source/acpi-support/+filebug
<sladen> green-mouse: https://launchpad.net/distros/ubuntu/+source/acpi-support/+filebug
<green-mouse> sladen, ok
<infinity> sladen: Yeah, some of our own user-contributed documentation is that bad too. :/  Have you seen the people who will post "I only had to add this [block of 30 options]  to xorg.conf to make my card work!" when all they really needed was one of those changes?
<green-mouse> sladen, thenks\
<mjg59> Uh?
<mjg59> Invalid module format is unlikely to be it bombing out
<HiddenWolf> infinity: or worse, compiling stuff when there are packages in the people. repositories
<mjg59> What does dmesg say?
<mjg59> sladen: Christ no. If there's a bug here, it's in the kernel, not acpi-support
<ogra> Riddell, do you list related projects on kubuntu.org like we do in edubuntu.org ? (and especially do you list xubuntu there ?)
<infinity> Is anyone else runinng a -386 kernel (I'm booted to -686 right now) who can confirm that that module loads?
<mjg59> green-mouse: After trying modprobe speedstep-centrino, could you please provide the output of the dmesg command?
<mjg59> Put it on pastebin rather than pasting it here
<sladen> mjg59: yes, it needs a generic 'powermanagement' but to assign things to before they get debugged
<ogra> infinity, sorry running -386 on amd64 here 
<green-mouse> mjg59, ok i post this in my bugreport...
<mjg59> sladen: If a kernel driver doesn't work, it's a kernel bug
<mjg59> green-mouse: Ok, give me the bug number once you've got it
<green-mouse> mjg59, ok
<infinity> ogra: modprobe that module, then.
<infinity> ogra: Doesn't need to DO anything, just want to see if it loads without "invalid module format", which is... Odd.
<ogra> ok
<ogra> infinity, a nice "no such device" here
<ogra> as it should be
<infinity> ogra: Okay, good.
<darius_> I just installed Dapper RC1 fresh.  Then tried to install ntp-server but the /etc/init.d/ntp-server script is looking for an 'ntp' user that was never created on the system.  Can anyone tell me if this behavious is consistent on another system?
<infinity> darius_: Oh, crap.  I have a bug report about that.
<infinity> darius_: try "export LANG=C ; apt-get install ntp-server"
<darius_> infinity: actually, it came up because I was trying to have it regularly check an ntp server (via the Time Setting gui interface) which trigger an install, but the install fails
<darius_> infinity: that didn't resolve it
<infinity> darius_: Oh, you'll have to purge it first.
<darius_> I just did an apt-get install ntp-simple from the command line and it fixed it on one machine
<infinity> "apt-get --purge remove ntp-server"
<infinity> Then "LANG=C apt-get install ntp-server"
<darius_> inifity: nope, I still got the error using that method
<infinity> Hrm.
<darius_> apt-get install ntp-simple did create the ntp user
<darius_> which resolves my problem .. but I think that leaves a problem for people trying to directly install ntp-server
<infinity> Well, yeah, but ntp-server depends on ntp-simple.
<infinity> Oh, feh.  I see the problem.
<darius_> actually, seems it will be a problem for everyone using the GUI
<infinity> No, it's a problem for everyone, period.  And has nothing to do with LANG, that was a red herring in a confused bug.
<infinity> Grr.
<Kamion> Seveas: unfortunately "RuntimeError: Install failed with exit code 1" requires more information; the actual trace is buried in syslog
<infinity> darius_: The problem is simple that ntp-server's postinst tries to restart, when it shouldn't (because it doesn't creat the user, nor contain the daemon, ntp-simple does)
<Seveas> Kamion, ah ok
<Seveas> Sorry again, will ask reporters for logs in the future
<Seveas> do you want me to undo my actions?
<Kamion> (so I added text to the crash dialog to ask people to attach syslog and partman, but about 50% of people seem to be ignoring that)
<Kamion> Seveas: yes please, otherwise I'll do it later
<Seveas> I'm on it
<Kamion> cheers
<darius_> I love being able to report an issue and *bham* someone is fixing it.  This is crazy.  I think Ubuntu will give Windows significant trouble in the near future
<bgertzfield> darius_: well come. :)
<Kamion> I honestly don't mind setting duplicate markings myself anyway - it helps me get an impression of which issues are most urgent
<darius_> I only wish hardware manufacturers were more support .. but I imagine it's coming.  I recently saw a request for quote go to a vendor and the requestor demanded that only hardware with linux open source drivers be provided
* mvo is away
<mdz> mvo: +                    if it.Component != "" and it.Component == "universe": ?
<ogra> does that only pull from it.a.u.c then ? 
<bgertzfield> darius_: coming from both the open-source and corporate worlds, hardware manufacturers will support software only when there's a lot of money to be made
<bgertzfield> or they have an ulterior motive (spreading goodwill among a great community, like the linux folks)
<darius_> bgertzfield: yeah, but if there's at least one manufacturer that has good support and competitive products then the rest start losing business.  This was a purchase for $50k, you can bet the distributor was willing to hunt for the right hardware
<bgertzfield> sure. it takes a long, long time for manufacturers to realize why they're losing business tho
<darius_> bgertzfield: plus, it would be nice if manufacturers created and released drivers but the biggest problem is manufacturers just not opening up their interface so that someone else could create drivers
<bgertzfield> no, it's more that they never wrote down the interface in the first place ;) trust me
<darius_> ah :)
<bgertzfield> usually the drivers are cobbled together at the last minute
<infinity> mdz: Aren't you supposed to be out buying drinks?
<ogra> yeah
<bgertzfield> yeah! celebration time
<darius_> half the ubuntu laptop install I make don't work out-of-the-box for the wireless networking.  This is so grueling.
<sladen> darius_: which wireless cards?
<darius_> broadcom, and some ipw2200 or whatever
<Riddell> ogra: not at the moment
<infinity> mdz: Since you don't appear to actually be out at all, can you approve this one for me? http://cerberus.0c3.net/~adconrad/ntp.debdiff
<darius_> many Dell latops, some HP - though I think HP is getting better
<ogra> Riddell, you mean you dont list any at the moment or you dont list xubuntu at the moment ?
<mdz> infinity: I have been out and back
<Riddell> ogra: just Ubuntu is listed
<ogra> ah, k
<infinity> mdz: darius hilighted it above, and looking at it, I'm not sure how this has ever worked for anyone.  Since we expose "apt-get install ntp-server" in the Time and Date gui, it seems pretty RC to me.
<infinity> mdz: Note that for minimum impact, I just copied the ntp-simple postinst wholesale (except for the runinng of the init script, since dh_installinit gives ntp-server that for free)
<darius_> I don't know if I've ever been able to install a Dell laptop w/ wireless support out of the box.  Really makes me hate their product :)
<mdz> infinity: was about to ask if you did that
<mdz> infinity: if so, fine
<infinity> mdz: Kay, cool.  Uploading.
<darius_> I'm sure Dell will come around eventually .. in 10 years - they finally started using AMD afterall :)
<darius_> Does anyone know if the /sys/module/processor/parameters/max_cstate misreporting of CPU load issue will be fixed before release?
<Kamion> Seveas: also, /var/log/partman, not /var/log/installer/partman
<darius_> The bug report was finally confirmed but we're at RC already.  It seems to affect a wide range of laptops (that worked with 5.10)
<sladen> darius_: what bug number?
<darius_> 30557
<darius_> I don't really understand what it is but it hit by nc6230 after upgrading to Dapper
<green-mouse> mjg59, Bug #46952....
<Ubugtu> Malone bug 46952 in acpi-support "cpufreq don`t work on centrino CPU in  "dapper" (kernel: linux-image-2.6.15-23-686)" [Normal,Unconfirmed]  http://launchpad.net/bugs/46952
<glatzor> hi Riddell. do you remember the missing translations issue for kde some time ago?
<infinity> darius_: ntp bug confirmed, fixed, tested locally, and uploaded.  Thanks for the reminder. :/
<glatzor> Riddell: there seems to be the same issue for koffice
<darius_> infinity: awesome.  Thank you
<sladen> mjg59: bug #30557 seems to be caused by a patch for ACPI C-states
<Ubugtu> Malone bug 30557 in linux-source-2.6.15 "cpu idle time in /proc/stat wrong" [Normal,Confirmed]  http://launchpad.net/bugs/30557
<hunt0r> hi all
<hunt0r> how can I prevent the bootstrap system from the live cd to load module?
<sladen> hunt0r: what module?
<hunt0r> cs
<hunt0r> ok fcpcmcia_cs.ko ok something like this
<hunt0r> wehen I try to boot it just says cs: io port probe and dies
<Riddell> glatzor: carlospc was saying he'll fix it
<glatzor> Riddell: yes for kde. but I noticed that this issue also applies to koffice
<glatzor> I did not notice...
<glatzor> Riddell: the leader of the German koffice translation team contacted me on IRC some minutes ago
<glatzor> Riddell: carlospc: applying the script of carlospc also to koffice would require a fresh upload of koffice?
<glatzor> Riddell: are there any string changes by you in the koffice package?
<sladen> hunt0r: how are you going to blacklist it if you don't know what module it is?
<glatzor> otherwise I would upload the current German translations of the kde team, since they are at 100%
<Riddell> glatzor: there's no kubuntu string changes in koffice
<glatzor> Riddell: to overwrite the Rosetta translation I have to do a "user upload", right?
<hunt0r> sladen: well I thought it the name is cs.ko becouse it says cs: blabla but maybe it has a slightly different name
<Riddell> glatzor: I don't know I'm afraid, but that sounds like it would do it
<glatzor> Riddell: Ok. 32 po files :/
<infinity> sfllaw: When you're around, can you check bug #46935?
<Ubugtu> Malone bug 46935 in wvdial "System hangs when using ltserial, ltmodem, /dev/ttyLTM0" [Normal,Unconfirmed]  http://launchpad.net/bugs/46935
<ogra> infinity, he was on it  yesterday already, if i didnt read wrong here
<infinity> ogra: Ahh, I see nothing from him in the bug log (and he wasn't subscribed until I added him), so I just wanted insurance. :)
<ogra> i only saw him poking on ltserial and ltmodem, probably it was a dup or something
<infinity> Could well be.
<infinity> Oh, yes.  Looking closely, there are several dupes of this one.
* ogra dinners
<HiddenWolf> has dinner, I hope. :)
<ogra> that too :)
<infinity> sfllaw: Nevermind, I see that you're all over a dupe of the same bug.
<glatzor> Riddell: did you need to reupload kde to solve the issue last time?
<Riddell> glatzor: I needed to upload the kde-i8n-de package, for some reason it was out of date
<dholbach> mdz, Kamion: ok to upload new example-content? fixes bug 46713 (ubuntu Sax.ogg ends abruptly, heno has a new version of it)
<Kamion> dholbach: yes
<dholbach> mdz, Kamion: sorry, the bug I meant is bug 46842
<dholbach> Kamion: merci beaucoup
<Kamion> de rien
* ogra looks for Ubugtu
<dholbach> LP is the problem, not Ubugtu.
<ogra> ah. still ?
<ogra> dholbach, nice to see youre not injured
<dholbach> ogra: injured?
<ogra> you dont watch/read the news ?
<dholbach> ogra: you mean because of that news story about that Berlin Amok run?
<ogra> yep
<dholbach> Oh man
<ogra> yep :/
<HiddenWolf> Heh, I'd run amok too if some loon started stabbing people at random.
<dholbach> Of course I'm not injured - as sad as the story is: Berlin is not a place where you have to fight for survival every day - as much as the media is working on that image
<dholbach> spiegel ahead of all of them
<ogra> heh, yes, i know
<dholbach> but oh well, I better stop complaining
<infinity> dholbach: BTW, you uploaded kooldock, which was FTBFS on all arches, due to an empty .po file.
<dholbach> infinity: i'll have alook, might be one of the AptGetOrg thingies, which built when I tested it (7-8 weeks ago)
<infinity> dholbach: But I'm betting you didn't test with pkgstriptranslations installed and in nazi mode. :)
<dholbach> infinity: no, not really :)
<glatzor> Riddell: it seems to be that the koffice 1.4 po files are used in rosetta
<glatzor> the number of strings (translated and untranslated) in the 1.5 po file and the rosetta po file differs by 300
<glatzor> for the kexi template only
<mroth> hmm.. should the new sun-java-jre in multiverse update /etc/alternatives/java to point to the sun version instead of gij?  doesnt seem to be doing so currently
<zyga> hello
<pygi> hey zyga 
<glick> hmm dapper for some reason i no longer automounts my external firewire drive when i plug it in
<ssam> glick, mine mount ok, anything interesting in dmesg
<glick> hey is there a reason why dapper now no longer auto mounts my firewire drive?
<glick> it did it once
<Induane> hey all is anyone here expirenced with zenity? it seems no one in the main ubuntu and ubuntu+1 channels is.
<Induane> thus I come seeking the genius of this channel
<glick> yeah it seems like pmount is screwy in dapper rc1
<mdke> glick: searching for and then filing a bug might be in order
<glick> mdke: where do i do that?
<mdke> glick: https://launchpad.net/distros/ubuntu/+bugs
<glick> mdke: when registering should i allow people to see my email or will i be spammed to kingdom come if i do that?
<mdke> glick: it is safe to allow it, I think
<glick> mdke: only registered people will be able to see it right?
<mdke> glick: i believe so. #launchpad can tell you more
<glick> ok sweet i submitted it
<glick> damn guess ill have to wait a while to access my firewire drive data :(
#ubuntu-devel 2006-05-28
<glick> is there anyway i can revert back to the old pmount before i upgrade?
<glick> upgraded?
<infinity> Are you sure pmount is your problem?  It hasn't been updated since May 11, and it's been working fine for all my removeable media.
<glick> infinity: well it my external drive worked fine on the liveCD and the install cd RC1 then i did a upgrade all and now it doent work
<infinity> Right, well, pmount on the RC desktop CD is the same as the pmount on your system.
<glick> hmm
<glick> infinity: so what else could be the problem?
<glick> hal maybe?
<infinity> hal hasn't had an update since RC either.  I'm trying to see if anything interesting has...
<glick> infinity: does it log somewhere what i upgrade?
<infinity> glick: /var/log/dpkg.log
<_ion> gtk_widget_show(windata->summary_label); gtk_widget_show(windata->body_label);
<_ion> Sorry, wrong chan.
<infinity> I'm not seeing anything uploaded since RC that would account for your issue..
<infinity> Oh well.  I guess I'll let pitti catch your pmount bug and debug it with you.
<nomed> what perms /dev/fuse should have ?
<nomed> i'd like to use sshfs as nomrmal user without each time chmod it ..
<glick> yeah i dont get it
<glick> should i try a reinstall or something?
<glick> hm damn is a mystery for the ages
<glick> could i have done something screwy?
<Seveas> nomed, please use #ubuntu for support
<nomed> Seveas, i wanted to figure out if it's an udev issue .. first ..
<nomed> i'll google
<Seveas> it's not, you have to add yourself to the fuse group
<nomed> Seveas, i maybe need to reboot even if it looks strange .. because even if i'm in fuse group i can't use /dev/fuse
<nomed> i can just in case i set it as root:admin
<Seveas> did you logout+login after adding yourself to the fuse group?
<glick> do i have to maybe add myself to the fuse group?
<glick> nah cause i get kernel error messages
<nomed> Seveas, it looks like i need to use same user name as user@host
<nomed> if i use "user1@ubuntu# sshfs user2@host: /mount/point"
<nomed> it doesn't work
<nomed> it works with "user2@ubuntu# sshfs user2@host: /mount/point"
<mjr> Worked last I tried. But try setting the user in ssh config if all else fails.
<Seveas> works fine for me too, i can mount dkaarsem@remote even when I'm dennis@local
<Burgundavia> jdub, can you pop the trunk on that ubuntu-website mailing list?
<glick> yeah i have no idea where the bug could lie, its prolly not pmount after all
<glick> cause pmount wasnt updated
<glick> damn
<bddebian> Howdy
<zul> hey
<bddebian> Heya Chuck, what's happening?
<zul> not much...just watcihing nation geographic
<glick> excuse me where can i look for individual packages?
<glick> im looking for an older kernel package
<glick> the -22 kernel
<glick> does anyone know how i can rollback my kernel a version?
<mdke> glick: you might want #ubuntu
<Lathiat> how do you change the title of a bug?
<Lathiat> thsi bug ahs such a horriblke title theres been 6 duplicates including mine :)
<Lathiat> ah, "Edit Description"
<bddebian> Yep
<bddebian> Heya Lathiat
<Lathiat> howdy bddebian 
<Burgundavia> zul, are you in Canada?
<zul> yep
<Burgundavia> zul, are you on ubuntu-ca and in #ubuntu-ca ?
<zul> im on the wiki and not in #ubuntu-ca yet
<bddebian> Heya Burgundavia
<Burgundavia> salut bddebian 
<mdke> Riddell: we have some translated desktop files for khelpcenter/kubuntu-docs in our repo now. if you can upload, that would rock.
<jsgotangco> good morning
<phil_> howdy all -- anyone here inclined to comment on the current state of bcm43xx support in dapper?
<Burgundavia> phil_, it is included, what else do you need to know?
<phil_> whether it's considered complete, bleeding-edge, or somewhere in between
<phil_> i.e., whether it's expected that many people will still have to use ndiswrapper for bcm43xx under dapper final
<Burgundavia> phil_, I believe it is recommended you use bcm43xx
<Burgundavia> it has been included in the mainstream kernel as of .16
<phil_> that i did know, but between the device i'm working with now and the posts i'd seen on the forums, it seemed like the module was there but not really working yet
<phil_> but if it is considered working, i'll go look for support info
<phil_> would it be inappropriate to ask if any particular urls come to mind which would document this specific feature of dapper from a dev standpoint?
<Burgundavia> afaik, there is no documentation
<phil_> cool, that still helps.  thx!
<phil_> oh, and being new to ubuntu, if i should find anything useful, where should i bring it?  here?
<zyga> is it too late for network-manager bugs?
<robitaille> it's never too late to report bugs...
<robitaille> but it doesn't mean they will be solved between now and next week
<zyga> :)
<zyga> its pretty trivial to fix IMHO
<zyga> some wifi cards (like mine, bcm 34xx) require down-up cycle after hibernation
<zyga> network-mangaer doesn't know about hibernation but it could perform the down-up cycle on manual 'select network' request
<glatzor> ping Riddell
<glatzor> high urgent ping to Riddell :)
<pitti> Good morning
<Hobbsee> hi pitti 
<Hobbsee> glatzor: it's not even 8.30am on a sunday morning over there, you know...
<glatzor> Hobbsee: i am utc+2 :)
<Hobbsee> glatzor: bah.  whatever that equals.  timezones should be obliviated.
<Hobbsee> yes, let us have sun at midnight!
<pitti> Hi Hobbsee 
<glatzor> evening jsgotangco
<highvoltage> hey mr jerome :)
<jsgotangco> hello
<jsgotangco> how's the weekend treating you two?
<highvoltage> very well, thanks :)
<highvoltage> been productive
<jsgotangco> highvoltage: did you see the email of corey regarding the download link
<highvoltage> just seen it, will get to that just now
<kagou> hi
<sivang> morning all
<skyrider> morning
<sivang> hey skyrider , been while since I last saw you in here :)
<skyrider> yes, long, long time ago :(
<skyrider> I'm more active in ubuntu-ru community then in english community
<sivang> skyrider: cool
<tepsipakki> so, is there a RHN (Redhat Network) equivalent coming out some time after dapper release?
<jdub> tepsipakki: sort of
<jdub> tepsipakki: http://blogs.the451group.com/opensource/2006/05/26/mark-shuttleworth-interview-part-i-on-dapper-and-ubuntu-in-the-enterprise/
<tepsipakki> that's what I just read :)
<jdub> that's the only public mention of it thus far. :-)
<tepsipakki> heh
<tepsipakki> I understand it is a service that costs something, like RHN
<jdub> we'll have to wait and see ;)
<tepsipakki> that would make sense, there's still room for a free "alternative" whatever pops out of ServerCandy
<mdke> jdub: I'll be your best friend if you change my blog details on planet
<mdke> c'mon, that's a good offer
<jdub> mdke: oh, i mustn't have pushed that up!
<nomed> hi mdke ...
<nomed> is it too late to fix an issue in xubuntu doc ?
<nomed> http://help.ubuntu.com/6.06/xubuntu/desktopguide/C/multimedia.html
<nomed> xubuntu doesn't need that gstreamer stuff ...
<mdke> nomed: probably too late, yes. best to contact the author
<nomed> or at least it should be explained it'll be needed incase user will install some other player ..
<nomed> ok
* mdke chuckles at the name "Gnome Bling Manager"
<glatzor> ping Riddell
<ogra> mdke, heh
<ogra> its *bling*
<mdke> great word, bling
<glatzor> skyrider: hello
<skyrider> glatzor: hello
<glatzor> I just read your question at #translators
<glatzor> skyrider: do you refer to the GNOME or KDE desktop?
<skyrider> glatzor: and?
<skyrider> GNOME of course
* mdke hugs jdub and declares eternal best-friendship
<glatzor> skyrider: hm. the term should be "Administration" and is located in the gnome-menus package
<skyrider> skyrider: I will try to check it in rosetta now. Because I don't have my Ubuntu here.
<glatzor> skyrider: the string shouldn't be "system settings"
<glatzor> could you provide a screenshot if you are on ubuntu again?
<skyrider> glatzor: of course. It will be later in the evening.
<msikma> Man, insane. I put my laptop on an online market place and in half an hour time, I got four phone calls about it.
<Riddell> glatzor: hi
<glatzor> good morning Riddell
<glatzor> Riddell: https://launchpad.net/distros/ubuntu/+source/koffice-i18n/+bug/47057
<Ubugtu> Malone bug 47057 in koffice-i18n "koffice-i18n version not in sync with koffice" [Normal,Unconfirmed]  
<glatzor> I could narrow down the koffice translation issue
<mdke> hey Riddell, did you get my hilight last night? We have some translated desktop files for kubuntu-docs in the repo. Dunno if it is too late for you to upload them, would be great if you could.
<Riddell> glatzor: we need to talk to carlos about this
<Riddell> mdke: I'll take a look, thanks
<glatzor> Riddell: furthermore I don't understand how the translation of koffice in rosetta works: the KDE translations are in universe and koffice itself is located in main
<Riddell> glatzor: they go into the language-packs like all the other rosetta translations
<glatzor> Riddell: no. this is not the case
<glatzor> Riddell: take a look at: http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=kexi.mo&searchmode=searchfiles&case=insensitive&version=dapper&arch=i386
<mdke> jdub: the url is slightly wrong, it has the url to the feed rather than to the blog. But thanks for adding, at any rate (I also need to figure out why it isn't dated the same as on my blog, but I haven't really looked at dates with pybloxsom yet).
<glatzor> Riddell:  sorry, ok it is in language-pack-kde-de-base. but this was not found by the packages.ubuntu.com
<Riddell> packages.ubuntu.com doesn't know the contents of dapper packages
<jdub> mdke: it gets what you give it :)
<mdke> jdub: oh, my bad then.
<jdub> mdke: <channel> <link> <- fix that
<jdub> mdke: or better still, use the rss plugin
<mdke> i'll check it out
<mdke> jdub: I was using rss2renderer.py
* mdke reads it
<jdub> mdke: oh. why was it pushing out (broken) rss 0.9?
<mdke> god knows
<mdke> jdub: you know what, I've given you the wrong url.
<mdke> jdub: should be rss2.xml
<jdub> rss2renderer uses index.rss by default...
<mdke> jdub: i changed it and forgot I had done so, sorry. index.rss must be getting pushed out by something else
<jdub> can you give rss2renderer a list of names? :)
<mdke> jdub: don't think so. I think it is index.rss2 by default, and I set it to rss2.xml
<jdub> mdke: (meanwhile, it's probably worth fixing any kind of crap output)
<mdke> jdub: isn't the output at rss2.xml working?
* jdub spanks mdke for using pyblosxom anyway :0
<jdub> ;)
* mdke prefers custard to spanking
<jdub> mdke: btw, your Ipodlinux link is " "
<mdke> thanks
<glatzor> Riddell: the KDE upstream translation coordinator just pointed me to incomplete translations of amarok, too.
<glatzor> Riddell: amarok only seems to affect only the  German  ones. koffice all languages.
<skyrider> glatzor: Today I've heard from one of our russian translators that Russian translation of amarok is screwed.
<skyrider> But probably it fixed it by uploading .po
<skyrider> I didn't checked it though
<skyrider> s/it fixed/he fixed/
* sivang wonders why nautilus source pkg doesn't apply some of the patches in the debian/patches dir. it's using simple-patchsys.mk
<pitti> sivang: maybe they don't end in .patch or .diff?
<sivang> pitti: lemme check
<sivang> pitti: looking into 93_upstream_nautilus-dnd-user-owned.patch , it ends with patch still when trying to create a new patch, as in "$ cdbs-edit-patch 120_copy_not_move_from_readonly" I don't see it applied and see the source is untouched where this patch should apply
<pitti> sivang: 120 < 93 in asciibet
<mdke> jdub: much better, thanks, and sorry
<pitti> sivang: simple-patchsys doesn't know about numeric ordering (neither does dpatch)
<sivang> ah, crap
<pitti> sivang: use 093 and 120 if you depend on numerical ordering
<sivang> pitti: k, thanks alot I will do that :-)
* sivang thanks at least it's not using dpatch
<sivang> pitti: can I use z_my_patch_name instead?
<sivang> pitti: (putting Z only to make it applied after all patches have been)
<pitti> sivang: why not just use a smaller patch number, like 23_foo? nautilus does not have so many patches
<pitti> sivang: if people name a patch with a very high number (90_foo), they usually *want* it to be applied last
<sivang> pitti: okay, makes sense. /me does that 
<sivang> pitti: hmm, my issues is actually, that my patch must come after 93_upstream_nautilus-dnd-user-owned.patch
<pitti> sivang: so what, use 94_foo then
<sivang> pitti: there's already patches from 93-101
<glatzor> thanks, skyrider
<pitti> sivang: doesn't matter :) 94_foo and 94_bar will work fine
<skyrider> glatzor: np
<sivang> pitti: okay, just wanted to make sure of that. thanks!
<pitti> sivang: however, 99_foo and 101_foo doesn't look right; poke the person who introduced that :)
<sivang> pitti: you looked into the source ? :)
<pitti> sivang: no
<glick> hmm apprently killall doesnt work in dapper
<glick> i cant kill my own processes?
<glick> kill doesnt work
<glick> killall doesnt work
<glick> not even as root
<tseng> it absolutely works
<tseng> try a kill -9
<glick> tseng: killall telnet    <- should kill all my telnet processes right?
<glick> especially if im root?
<glick> lol it doesnt work
<_ion> Telnet? Eww.
<tseng> it should, but there is no guarantee that sending a signal to a process makes it die instantly
<tseng> if at all
<glick> tseng: a process cant catch or ingore a term signal
<_ion> Since when?
<tseng> ok, good luck with that then
<glick> _ion: what do you mean since when?
<_ion> Why would a process not be able to catch SIGTERM?
<glick> _ion: i mean sigquit
<glick> or sigkill
<mjr> you mean sigkill
<_ion> % foo() { echo foo }; trap foo QUIT; kill -QUIT $$
<_ion> foo
<mjr> and if a process doesn't die with -9, then it's a kernel problem
<glick> killall sends the kill signal doesnt it
<mjr> glick, no
<mjr> it sends term by default
<mjr> use the -9, luke
<tseng> in the future this sort of thing should go to #ubuntu
<mjr> it really should
<glick> damn
<glick> ok
<tseng> but there is nothing wrong with kill, you just misunderstand it
<glick> i feel stupid
<glick> heh
<glick> thanks
<tseng> and telnet is being a pain
<glick> hey where can i put a feature request into gnome?
<ssam> glick, the gnome wiki, or write a spec on launchpad
<highvoltage> sfllaw: ping
<sivang> hey highvoltage , 'sup?
<highvoltage> sivang: hey, long time no see :)
<sivang> highvoltage: yes, how are you doing ?
<jdub> glick: bugzilla.gnome.org
<highvoltage> doing well, we're getting the edubuntu website in shape for release. lots of work! :)
<glick> jdub: its not a bug report ihave
<glick> just a idea for a feature thatd be cool
<jdub> glick: bugzilla is not just for bug reports (have a look)
<_ion> /summon mvo
<sivang> highvoltage: it's also Moin based right? like the main ubuntu site
<ogra> _ion, its sunday
<ogra> _ion, give him his well deserved rest :)
<highvoltage> sivang: used to be, it's now drupal
<sivang> ah, drupal is also cool
<sivang> my soon to be active blog is using it
<sivang> still haven't figured all the features and possibilities
<_ion> Well, i posted a fixed theme to bug #46642, anyone's free to inspect it and possibly include it in the package. :-)
<Ubugtu> Malone bug 46642 in notification-daemon "Panel notification appears too low, distorts bubble" [Normal,Unconfirmed]  http://launchpad.net/bugs/46642
<Riddell> mdz: I'd like to remove openoffice-kde from amd64, it's broken and stops the file open dialogue from working
<infinity> Riddell: An OOo-amd64 upload will be pending after the current ppc/i386 upload goes up, so if there's concensus on this, we can do it then.
<infinity> Riddell: Note that removing packages doesn't magically make them get uninstalled, mind you.  So it may just be better to exclude it from your -desktop seed so new installs don't get it, and leave it at that.
<Riddell> infinity: I was just meaning from the desktop seed
<mdz> Riddell: how long has it been broken? is there a bug open?
<Riddell> mdz: quite a while, I remember there being a bug I can try and find the number
<infinity> Riddell: I thought the only OOo/KDE issue was with skim/scim... I didn't realise the whole shebang was broken.
<mdz> Riddell: was it installed and/or broken in breezy as well?
<Riddell> infinity, mdz: it worked in breezy, but seems to have regressed to not finding qt/kde widgets in dapper and openoffice now tries to use the native file dialogue which just doesn't do anything on amd64
<pitti> mdz: http://paste.ubuntu-nl.org/14774  <- psycopg debdiff; I tested it very carefully and made sure that this is the only usage of \' (fixes bug 46473)
<Ubugtu> Malone bug 46473 in psycopg "psycopg needs quoting fix" [Critical,In progress]  http://launchpad.net/bugs/46473
<mdz> Riddell: you need to do a seed merge & metapackage update for landscape anyway, so fine with me
<mdz> sort of disturbing that it's remained an issue for so long though
<infinity> Riddell: Are we sure this doesn't just need an update of ia32-libs-kde to include a few more libraries?  (Which would also, afaik, fix the OOo-amd64/KDE/skim issue?)
<mdz> pitti: that code is pretty hideous
<Riddell> infinity: it would also need doko_'s patch to qt to find the lib32 directory
<pitti> mdz: you mean the comparison with space and ~? yes :)
<infinity> Riddell: Right, which is likely too intrusive at this point.  Feh.
<Riddell> yep
<mdz> pitti: yes
<infinity> We can't force openoffice.org-amd64 off users' systems without some pretty large headaches.
<infinity> (So we won't)
<pitti> mdz: true, but that's not really something I'd like to change at this point
<mdz> pitti: I don't really understand the fix though
<infinity> Riddell: So, be prepared to field a lot of "it broke on upgrade, argh" bug reports.
<mdz> it was replacing ' with \', now it replaces ' with ''?
<pitti> mdz: right
<mdz> pitti: that doesn't seem like it would have the same effect
<infinity> mdz: '' is traditional SQL escaping for '
<pitti> mdz: the 'why' is a long story; http://www.postgresql.org/docs/techdocs.50 gives details, if you are interested
<pitti> mdz: with some client encodings, you can abuse \' escaping to sql injection, which is why psql now disables it by default for these client encodings
<mdz> so if I have a string foo'bar and I want to quote it, it would be 'foo''bar'?
<pitti> mdz: also, \' is not SQL standard, '' is
<infinity> mdz: Yup.
<pitti> mdz: right
<mdz> that's horrible
<infinity> Yes, it is. :)
<mdz> but your fix is correct in that case ;-)
<infinity> But it's also The Way and The Light.
<pitti> mdz: in fact we are really, *really* lucky that ' is not a valid last byte in any known multibyte encoding (whereas \ is, which is where the problem comes from)
<infinity> I just wish Shift-JIS and BIG5 would die already. :/
<infinity> Dealing with the dozens of random encodings for Japanese stuff I get over here is hell.
<doko_> Riddell, infinity: it needs either the patch, or a preload, plus the scim libs and plugins in ia32-libs
<pitti> doko_: I'm going to file a Debian bug for http://patches.ubuntu.com/patches/psycopg.CVE-2006-2314.diff now; do you have time for that soon? (I can NMU if you like)
<infinity> doko_: Is there any fix that you would categorize as "non-intrusive, obvious, and easy for a detached party (say, me or mdz) to identify as 'correct' at a glance"?
<infinity> doko_: If so, it might be nice if you could help Riddell put such a proposal together ASAP.  If not, then I guess he's stuck with dropping it from -desktop and dealing with the fallout. *shrug*
<pitti> mdz: so, permission to upload?
<mdz> pitti: I thought I already OKed it?
<pitti> ok :)
<doko_> infinity: yes, maybe the preload thing that I sent, and load it using the ooo-wrapper script, so you can avoid the diversions
<Riddell> doko_: where can I find that and how can I test it?
<doko_> Riddell: in a mail sent to you; wait, I'm sending it again
<mdz> doko_: what is all this about?
<doko_> mdz: scim crashing OOo on amd64 KDE
<Kamion> grr, stoopid grub-installer
<infinity> mdz: Un-busticating OOo-amd64 and KDE, so Riddell doesn't have to drop the package from -desktop and break upgrades.
<infinity> doko_: Or, rather, I assume this will also fix that?
<infinity> doko_: (It's the same problem, I'm guessing, from his description?)
<doko_> infinity: where's Riddell's description?
<ogra> doko_, scrollback
<doko_> ugh, file-open dialog broken?
<ogra> yep
<infinity> doko_: The "not finding widgets" bit seemed pertinent.
<infinity> doko_: Dear God.  How is debian/control generated in OOo?  This looks scary.
<doko_> could somebody tell me, why vnc4 was uploaded, and who did it? I cannot see any sync requests, and no uploader ...
<doko_> infinity: debian/rules debian/control
<infinity> doko_: Just from debian/control.in, or does it cleverly paste all of them together somehow?
<infinity> Current release:  4.1.1+X4.3.0-10
<infinity> Creator: Barry deFreese
<ogra> doko_, ask bddebian 
<doko_> infinity: pasting as well
<doko_> yeah, he's building using XFree, not xorg :-/
<ogra> meh
<\sh> moins
<ogra> afternoon
<ajmitch> hi \sh, ogra 
<Riddell> mdz: can I upload this fix for guidance? http://www.kubuntu.org/~jriddell/tmp/guidance.diff
<doko_> Riddell: is there a possibility to set the KDE plugin path?
<mdz> Riddell: the changelog should say what the patch does
<pitti> mdz: http://paste.ubuntu-nl.org/14776 same fix for pygresql, also no rdepends
<pitti> mdz: (in main)
* mdz rubs his eyes
<mdz> pitti: ok
<pitti> mdz: ETOOMANYSLASHES?
<infinity> Ugh, yeah.
<mdz> yes
<Riddell> doko_: not as far as I know, although it wouldn't surprise me if there was some way to do it
<mdz> pitti: OK to upload though
* pitti doesn't even want to think about the possiblitity of mysql having the same issue
<mdz> Riddell: patch is fine
<_ion> MySQL _is_ an issue.
<pitti> _ion: I can't see why it shouldn't be, at least
<pitti> unless it doesn't support these encodings
<Riddell> mdz: thanks, I'll add a better description
<mdz> BenC: morning
<BenC> hey
<BenC> cool, the wireless applet has the two icons closer together now...that was starting to bug me :)
<infinity> pitti: Easy enough to test, I suppose.
<doko_> Riddell: see http://people.ubuntu.com/~doko/ooo-amd64/ for a ia32-libs-kde, which *should* fix the scim problems. please let me know, if that works
<pitti> infinity: sure
<Riddell> doko_: downloading
<doko_> it includes the patched qt3, plus libscim8c2a scim-qtimm; if you run strace -e trace=file /usr/lib/openoffice/program/soffice.bin -writer, then it *should* open /usr/lib32/qt/plugins at some place.
<doko_> using the i386 strace binary of course
<Riddell> doko_: how do I get i386 strace?
<doko_> download the i386 package, and put the executable in /usr/local/bin/strace32
<infinity> pitti: What's up with language-pack-kde-tl-base and language-pack-kde-tl being out of version sync?
<mdz> Riddell: don't forget about that seed/metapackage merge, whatever happens with oo.o-kde
<infinity> pitti: -base is newer than the other one, rendering them both uninstallable.
<infinity> pitti: Oh, I see, you did a non-automatic upload of -base.  A fresh upload of the other to match versions would fix it.
<infinity> pitti: I'm doing so right now, to get it off my "eek, broken packages" radar.
<Riddell> mdz: yep
<Riddell> doko_: fighting with scim to get it setup
<\sh> Riddell: can we fix klaptopdaemon somehow to honhour linux key codes to fix the "Fn triggered acpi events from acpi-utils are not working" regression?
<doko_> Riddell: I forgot something ... please could you: cp -a /etc/qt3 /etc/qt3-32, and then edit qt_plugins_3.3rc to point ti the new locations?
<doko_> s,^lib/,lib32,
<doko_> s,^lib/,lib32/,
<infinity> Riddell: W. T. F.
<infinity> Riddell: 
<infinity> gtk-qt-engine (0.60-1.1ubuntu6) dapper; urgency=low
<infinity>   * Don't use shlib depends, stop requiring gtk
<infinity> Riddell: Not using shlibs is just plain wrong.
<ogra> infinity, err, that should have been demoted to universe long ago
<ogra> at least that was my proposal at the beginning of the release
<ogra> it breaks the gnome desktop completely if its installed and upstream seems not after fixing it
<pitti> infinity: uh, ouch, sorry; I didn't think about that when I quickfixed -lt-base
<pitti> infinity: thank you
<infinity> ogra: It's still in kubuntu-desktop.
<infinity> Riddell: Any comments on the above?  Is that meant to not be in kubuntu-desktop?
<ogra> infinity, ouch
<infinity> Riddell: And if it /is/ meant to be, then a better solution than "don't use shlibs" should be found, since that breaks on arches with a different libc (*cough*ia64*cough*)
<infinity> Riddell: (Though, arguably, we don't care much about ia64 as release rolls near, you may still want to be installable there for kicks)
<Riddell> infinity: it is ment to be in kubuntu-desktop, its ment to sit there dormant until gtk gets installed
<Riddell> I've also tested it under gnome lots and can never find any problems, although it doesn't get turned on by default if you have ubuntu-desktop installed
<Riddell> doko_: doesn't seem to make any difference
<infinity> Riddell: Kay.  Then I'd like to fix the shlibs issue (I understand you don't want to ship GTK, so I see the reason for the workaround)
<doko_> Riddell: which application creates /etc/qt3/qt_plugins?
<infinity> Riddell: who knows, maybe some KDE nut at HP will be the turning point for getting them to support our ia64 port... If kubuntu is installable. :)
<doko_> Riddell: do you have instructions, how to setup KDE for scim?
<Riddell> doko_: strace shows no sign of opening any plugins, although it doesn't crash at all for me, it just doesn't use skim
<Riddell> doko_: install skim, im-module, scim-anthy and language-pack-kde-ja-base
<doko_> Riddell: ok, so we have to add skim, im-module, scim-anthy to ia32-libs kde
<Riddell> run im-module -s ja_JA -z scim-anthy; restart X and run skim
<Riddell> doko_: so two instances of skim running?
<ReMink> Hi all !
<doko_> Riddell: which of these packages install modules into /usr/lib/qt or /usr/lib/kde ?
<doko_> at least scim-qtimm was loaded on i386
<Riddell> doko_: yes, scim-qtimm also needed
<infinity> mdz: Permission to upload the following, which makes kubuntu-desktop installable on ia64 again?  (Hey, someone at HP may be watching)
<infinity> mdz: http://cerberus.0c3.net/~adconrad/gtk-qt-engine.debdiff
<infinity> Riddell: ^^^
<mdz> infinity: what's with all the hardcoded shlibdeps?
<freeflying-g4> doko_: hi
<Kamion> infinity: did you see the continued problems with bug 33351?
<Ubugtu> Malone bug 33351 in ntp-server "user "ntp" does not created" [Unknown,Unknown]  http://launchpad.net/bugs/33351
<infinity> mdz: See the previous changelog entry.  It's in the context.  (That's Riddell's doing, not mine)
<Kamion> new prerm should take care not to error, I think
<mdz> infinity: is that the full changelog entry for 0.60-1.1ubuntu6?
<infinity> Kamion: Yeah, probably.  It was really only an issue for people who already had the broken version installed.
<infinity> mdz: Yes, modulo Riddell's signature.
<mdz> Riddell: whiskey tango foxtrot
<Riddell> infinity: good with me
<infinity> i already WTFed. :)
<mdz> I see
<Riddell> mdz: I turned off shlibs on qt-gtk engine so it doesn't bring in a load of gtk dependencies onto the kubuntu CD
<infinity> mdz: I believe the argument is to allow this to be in kubuntu-desktop, without having kubuntu-desktop pull in half the GTK/GNOME world.
<mdz> yes, I read the earlier discussion now
<infinity> Yeah.
<Riddell> which I appreciate is inelegant
<infinity> The word "sketchy" leaps to mind, but it's a bit late now to do it more correctly, I think.
<infinity> Kamion: I'll probably upload again to make things less fragile, though that will involve sidestepping dh_installinit, which is what's responsible for the "if invoke-rc.d fails, SCREAM REALLY LOUDLY" behaviour.
<infinity> Kamion: So, I'm weighing "let people figure it out and don't add extra hacks" against "make upgrades not suck for people who've had the broken packages installed all this time"
<Kamion> dh_installinit has a switch for that
<Kamion> --error-handler or some such
<infinity> Oh, that's pretty.  I've never seen that before.
<infinity> A bit extravagant for the problem at hand, though.
<infinity> The more code I write for the "upgrade from broken versions case", the more I die a little on the inside.
<Kamion> --error-handler=true is common
<infinity> Oh, cute.  Hadn't thought of that. :)
<Kamion> though that would land in both prerm and postinst
<infinity> I was planning a real handler, with dpkg --compare-versions and such, to only ignore errors from busted versions..
* Kamion blats more minor ubiquity fixes at the archive, hopefully cleaning up all the soluble reports from RC that I've had so far
<Kamion> there's stuff like "fails on MacBook Pro", but well ...
<mdz> infinity: anyway the trivial dep change is fine
<Kamion> most of the reports have been variants of the old "grub hates XFS" problem (which I've just band-aided to crash less badly ...), with a few other odd corner cases
<Kamion> not as bad as my inbox looked at first glance
<infinity> mdz: Kay.  Any opinions on the ntp thing?  Worth fixing upgrades from broken versions, or just leave people to divine the "I have to remove the package and reinstall with the unbroken version" fix?
<Kamion> they won't even be *able* to remove it, will they? not without creating the ntp user?
<Riddell> doko_: the qt_plugins_3.3rc file is created whenever you run a kde programme, it's put into /etc/qt3 if it's run as root
<Riddell> else ~/.qt
<infinity> Kamion: Some people were claiming success removing it.  I didn't actually try, TBH.
<doko_> Riddell: that's just ugly ..., so you have to patch that to move to ~/.qt-32 as well ...
<infinity> Kamion: It would make sense that they shouldn't be able to, though, without "exit 0" hacks or something.
<infinity> Kamion: Feh.  Right.  I'll fix the upgrade path, then. :)
<Riddell> doko_: I guess so, although goodness knows where
<Riddell> doko_: how come this worked in breezy?
* infinity curses smurf, for lack of anyone else to blame this on.
<doko_> Riddell: did scim work in breezy with OOo?
<Riddell> doko_: no, but qt widget theme did
<Riddell> or maybe it didn't, maybe I just saw the KDE icons and thought that was the widgets too
<doko_> Riddell: what is the first section in /etc/qt/qtrc for you? [3.3]  ?
<Riddell> head -n2 /etc/qt3/qt_plugins_3.3rc
<Riddell> [usr] 
<Riddell> lib/kde3/plugins/styles/lipstik.so=30306^e3^ex86_64 Linux g++-4.* full-config^e2006-03-29T05:44:59^e
<Riddell> oh, qtrc, yes that's libraryPath=/usr/lib/kde3/plugins/
<doko_> but why? isn't that section about qt3?
<doko_> and should be libraryPath=/usr/lib/qt3/plugins/ or something like this?
<Riddell> I think /usr/lib/qt3/plugins/ is built in and KDE adds the pointer to /usr/lib/kde3/plugins/ so qt knows where to pick up the kde widget themes
<doko_> right, but it does it do two times ...
<ogra> Riddell, i just had one user testing gtk-qt-engines, it appears that his gnome desktop doesnt start any apps after he used it ... i'd suspect bug 37561, it would probably make sense to include that one line patch probably 
<Ubugtu> Malone bug 37561 in gtk-qt-engine "unexpected character in ~/.gtk_qt_engine_rc" [Normal,Confirmed]  http://launchpad.net/bugs/37561
<ogra> (rm ~/.gtk* solved it for him)
<Riddell> ogra: trying it
<doko_> Riddell: updated ia32-libs-kde: install /etc/qt3-32, and use /usr/lib32 in /etc/qt3-32/qtrc. now try to find out how the other files are written ...
<Kamion> mdz: are you going to be starting on release prep over the bank holiday Monday, BTW? I'll be off work most of the day, although I do have to do a ubiquity upload to update translations by request of sabdfl.
<sabdfl> thanks Kamion
* infinity goes out to buy brain food to help him hack into the wee hours.
<doko_> Riddell: im-module doesn't exist
<infinity> mdz: Oh, any qualms about me upload that hppa Xorg detection fix in the next hour or so?  (I'm assuming not, from your bug comment, but want to make sure)
<infinity> s/upload/uploading/
<infinity> ME UPLOAD PACKAGE.  ME LIKE UPLOAD.
* Mithrandir gives infinity a cluster of bananas.
<ogra> infinity, cant you write a script that creates a bunch of empty packages for you then ? :)
<doko_> Riddell: oh no, scim does have it's own plugin system as well ...
<\sh> pitti: do you have a simple "gain root" exploit on actual dapper to restore my passwd, without rebooting the machine, because there is no keyboard or display attached?
<pitti> \sh: check /var/log for passwords :-P
<infinity> \sh: If he did, he would have uploaded a fix by now.
<pitti> \sh: seriously, no
<\sh> na...
<pitti> \sh: you won't get around rebooting, unless the current password is very weak and can be figured out with john
<pitti> (and you can get the encrypted password with some other nonstandard means)
<\sh> pitti: the password is not weak :( and I hope that serial console is working during boot..oh no...I don't have a serial on this laptop
<\sh> I'm doomed until next weekend :(
<doko_> Riddell (and any other scim expert): are the scim modules loaded by the application used, or by some kind of server process?
<Riddell> doko_: I think they're just used by /usr/lib/scim-1.0/scim-launcher
<Riddell> and the scim frontend talks to that
<Riddell> well, best check that this a scim person
<doko_> Riddell: so no need to have these as 32bit versions
<Riddell> if my understanding is correct there should not be
<Riddell> infinity: did you upload gtk-qt-engine?
<\sh> hmmm.....wasn't the scim/skim thing a plugin for qt3?
<dholbach> Riddell, doko_: are you going to do a scim upload anytime soon? if so, could you please include  http://daniel.holba.ch/ubuntu/scim.debdiff ?
<pitti> mdz: http://patches.ubuntu.com/patches/python-pgsql.CVE-2006-2314.diff - third and last python psql interface in main
<pitti> mdz: this one has no rdepends but *-desktop, so it's on the CD
<pitti> mdz: but again, I test it carefully
<pitti> s/test/tested/
<doko_> dholbach: looks like we don't need it, if Riddell is right regarding the scim plugins
<doko_> Riddell: new ia32-libs-kde at http://people.ubuntu.com/~doko/ooo-amd64/
<dholbach> Riddell: if you think you don't need a scim upload, please tell me, so I can get that change in on my own.
<infinity> Riddell: Yeah, I uploaded it.
<glatzor> Riddell: are there any Ubuntu string changes in amarok? otherwise I would upload the German upstream translation
<Riddell> glatzor: none
<Riddell> glatzor: but it's amarok 1.3 not 1.4
<glatzor> Thanks Riddell
<glatzor> ok thanks. I would have used the wrong one. I am going to use the one from the source package
<_ion> gloubiboulga: Hi. Online?
<Gloubiboulga> _ion, hi
<_ion> gloubiboulga: Could you please join #ubuntu-desktop? We're discussing bug #40607 and i was told to contact some xubuntu guy because Tangerine is the default theme in xubuntu.
<Ubugtu> Malone bug 40607 in tango-icon-theme-common "Ok/Cancel buttons" [Normal,Unconfirmed]  http://launchpad.net/bugs/40607
<Riddell> ogra: what's the magic in gdm needed by ltsp?
<ogra> Riddell, the magic is that we use ldm ;)
<ogra> Riddell, until recently gdm wasnt able to do ssh based connections, so we wrote ldm ... we'll probably switch (based on testresults) in eft
<Riddell> ah, right
<Riddell> so we need a KDE port of that then :)
<sladen> join #ubuntu-desktop
<ogra> no, rather teach KDM to use ssh as well 
<ogra> then we can use the native login managers :)
<Riddell> ogra: so why write ldm instead of changing gdm to optinally use ssh?
<ogra> Riddell, because initially ldm was way smaller etc ...
<ogra> but over time it grows to gdm size due to feature requests of users
<ogra> and it didnt look as easy to intrude ssh in gdm than to just invest some hours over the weekend to write a trivial fullscreen gnomecanvas/glade window
<ogra> (thats all ldm currently is)
<ogra> executing: ssh -X user@server /etc/X11/Xsession after you hit enter
<jono> hey
<dholbach> Riddell: hum... do you want to do a scim upload or not? else I'd just upload that icon change?
<Riddell> dholbach: go ahead I'd say
<dholbach> mdz, Kamion: are you ok with  http://daniel.holba.ch/ubuntu/scim.debdiff (new icon from the designer)?
<mdke> hey dholbach 
<dholbach> hey mdke
<mdke> dholbach: we removed a stray symlink from the ubuntu-docs package and bumped the version number to 6.06.1, I guess it's not worth uploading, right?
<dholbach> mdke: you should ask mdz - if that's all the changes, I think he'd be happy with it.
<mdke> mdz: ok to upload a new ubuntu-docs to fix bug #47016 (incredibly trivial fix)? 
<Ubugtu> Malone bug 47016 in ubuntu-docs "Dapper RC's Ubuntu-docs package html softlink has missing target." [Normal,Fix committed]  http://launchpad.net/bugs/47016
<mdke> dholbach: thanks
<dholbach> mdke: de rien
<dholbach> mdke: i'll have to leave soon, so if Matt is ok, just drop me a mail and I'll do it
<mdke> dholbach: sure thing
<dholbach> rock on
<mdke> mdz: (here is a diff of the change https://lists.ubuntu.com/archives/ubuntu-doc-commits/2006-May/002629.html )
<desrt> macbook +1 (wifi)
<tseng> mdke: you might have better luck mailing that to him
<mdke> tseng: ok, thanks
<mjg59> desrt: Mm?
<ogra> mjg59, i have a first success report of ltsp running on a intel imac :D
<mjg59> Ha
<ogra> booted with rom-o-matic PXE image ;)
<desrt> mjg59; got wifi working on the macbook.  small ordeal
<mjg59> desrt: What needed doing?
<desrt> mjg59; you need to manually load new_wlan_scan_sta and new_wlan_ccmp
<mjg59> desrt: Why?
<desrt> mjg59; then you need to recompile wpasupplicant against the madwifi-ng headers (the dapper version won't work with madwifi-ng)
<desrt> mjg59; because they're not automatically loaded....?
<mjg59> Oh, well, the wpa thing is just impossible
<mjg59> desrt: Yes, but why? :)
<desrt> no idea.  i filed a bug
<mjg59> Ok
<infinity> Missed a PCI ID?
<mjg59> infinity: No, the PCI IDs aren't in there
<mjg59> Easiest would just be to add them to post-load
<infinity> Oh, right, he didn't have to manually load new_ath_pci.
<mjg59> Think we could swing a new l-r-m with only that change?
<infinity> I'm preparing a new LRM anyway, so push that change to me and I'll get it approved.
<desrt> it's just filed against l-r-m in launchpad
<desrt> malone #47137
<Ubugtu> Malone bug 47137 in linux-restricted-modules-2.6.15 "new_wlan_scan_sta not autoloaded" [Normal,Unconfirmed]  http://launchpad.net/bugs/47137
<desrt> mjg59; so weird thing is... wpasupplicant is compiled for the old madiwif
<desrt> mjg59; but it's the new drivers that get autoloaded...
<Riddell> mdz: gtk-qt patch for review http://kubuntu.org/~jriddell/tmp/gtk-qt.diff
<desrt> hm.  neat.  wifi cuts out randomly, network-manager springs into action and brings it back for me :)
<ogra> MVO !!!!
<ogra> argh
<jsgotangco> ?
<zyga> hello
<ogra> he fiddled with hwdb to make it translatable 
<zyga> sun-java5-jre is not installable on pure dapper rc install due to 'unable to display license dialog'
<zyga> I guess something like dialog/whiptail should be depended on
<ogra> and i have no clue what he did, but i have tns of bugs about it not working at all anymore as long as you have a non english locale
<zyga> 'license could not be presented'
<zyga> that's the exact wording
<zyga> it does work via synaptic though
<jsgotangco> strangely, i was able to install it a few hours ago
<jsgotangco> (terminal)
<zyga> jsgotangco: did you add any repo/package?
<jsgotangco> multiverse
<ogra> jsgAWAY, me too, yesterday
<zyga> same here
<zyga> still, any hints?
<bgertzfield> zyga: hm. that's interesting
<bgertzfield> zyga: I just made a new package based on sun-java5-jre using the same pattern to display the license
<bgertzfield> zyga: are you in non-interactive mode?
<bgertzfield> dpkg-reconfigure debconf to see
<zyga> bgertzfield: hmm, don't now how aptitude invokes dpkg
<zyga> bgertzfield: I tried aptitude and manual apt-get -f install
<zyga> checking
<bgertzfield> the sun packages will refuse to install if debconf is set to noninteractive mode
<zyga> bgertzfield: yes, non-interactive
<bgertzfield> zyga: there you go.
<zyga> is that the default?
<bgertzfield> no.
<bgertzfield> change it to any of the interactive modes and you'll be set
<zyga> I never altered that in any concious way
<bgertzfield> zyga: maybe that's a bug, I dunno
<bgertzfield> but its definitely not the default
<zyga> bgertzfield: but synaptic did show a gnome debconf frontend
<bgertzfield> zyga: no clue.
<bgertzfield> just letting you know how the sun jre packages display that message. :)
<bgertzfield> somehow you ended up in noninteractive mode
<zyga> bgertzfield: thanks :)
<bgertzfield> zyga: the new vmware-player package does the same thing. :)
<zyga> bgertzfield: I'll make sure it works on clean dapper final install as well as typical breezy-dapper upgrade
<bgertzfield> right
<zyga> bgertzfield: strange, I'd want an auto frontend that chooses dialog/kde/gnome autimatically
<bgertzfield> zyga: I'm pretty sure gnome etc. fall back to dialog
<zyga> good, did set it to gnome :)
<bgertzfield> great
<zyga> whoah!
<bgertzfield> ?
<zyga> does anyone remember xara xtreme graphics program (about a year ago on shashdot)
<zyga> they wanted to go open source and do a linux version
<zyga> and it's there already, the source, linux building instructions AND the license
<zyga> GPL
<zyga> this is *so* cool
<bgertzfield> XTREEEEEEEEEEME
<bgertzfield> sorry
<bgertzfield> I just had a mountain dw
<bgertzfield> *dew
<zyga> we should definitly have a package :)
<bgertzfield> zyga: would you like to test the new vmware player packages?
<zyga> bgertzfield: sure
<bgertzfield> mvo will be uploading them to the repository shortly, but I have a local apt repository
<zyga> bgertzfield: but I have no images
<bgertzfield> oh, no X?
<bgertzfield> never mind :)
<zyga> bgertzfield: no, no vmplayer-ready images
<bgertzfield> oh
<bgertzfield> grab the Ubuntu Browser Appliance: http://www.vmware.com/vmtn/vm/browserapp.html
<zyga> grabbing
<zyga> bgertzfield: ping me in 20 minutes :)
<bgertzfield> will do.
<zyga> okay I'll mail xara to ask about their co-operation on a dapper-ready package
<sladen> zyga: it should be in Debian
<zyga> sladen: I just check, didnt find anything matching xara, are you sure?
<zyga> ah
<zyga> you're right
<zyga> why is it in non-free, that's GPL code
<mjr> hmh, I though the core of xara was still non-free, though expected to be released in the near future
<zyga> mjr: right, I got carried away
<zyga> one library is still non-free
<ogra> doko_, here ? 
<doko_> ogra: yes
<ogra> doko_, i just discovered that oodraw is missing in my edubuntu appmenu, known ? 
<ogra> (i just knew about the double entry of impress/calc mess)
<ogra> oodraw is installed and starts fine though
<ogra> (from commandline)
<doko_> mdz: looks like Riddell's testing was sucessful, together with some changes. patch at http://people.ubuntu.com/~doko/ooo-amd64/qt32-diff, which needs a followup-upload integrating this and some scim packages into into ia32-libs-kde. ia32-libs-kde will grow by 1,5MB. fixes the scim and kde widgets issues
<doko_> ok to upload?
<ogra> oh fun, its in the menu editor, but disabled in both categories (garphics/office)
<doko_> ogra: yes, requested by the menu cabal
<ogra> urgh, even in graphics ? 
<ogra> (i could understand that its not in office)
* ogra doesnt think thats a good idea
<ogra> infinity, ping ? 
<infinity> ogra: pong.
<ogra> infinity, i have a strange nvidia prob here
<ogra> nvidia-glx is installed, and enabled (logo on startup etc)
<ogra> but glxinfo complains
<infinity> Define "complains"
<ogra> extension GLX missing on display :0.0
<ogra> running the recent dapper driver and have 16bit colors defined in xorg.conf
<infinity> Erm.
<infinity> So, is "glx" enabled in xorg.conf?
<ogra> i wouldnt even have bothered to look, but someone just reported the same prob to me 
<ogra> yep
<ogra> its in the modules section
<infinity> And does using 24-bit colour fix it?
<_ion> Btw, why 16bit?
<infinity> It's entirely possible nvidia-glx just plain won't do OpenGL overlays on 16-bit displays.
<ogra> _ion, shitty lcd panel
<infinity> Which would be a "sucks to be you" thing.
<ogra> it worked on breezy 
<infinity> ogra: Uhh.  Why would the panel care what your colour depth is?
<infinity> ogra: "It worked on breezy" is nothing I can do anything about, since it's a big fat binary blob. :)
<ogra> infinity, because its a cheap leaptop 
<infinity> ogra: You can install nvidia-glx-legacy, though.
<ogra> with a 6500 card o_O
<ogra> 24bit doesnt fix it
<ogra> MVO
<ogra> !!!!
<ogra> !
<_ion> mvo!!!!!111111
<mvo> ogra: OGRA!
<ogra> mvo, hwdb is totally broken 
<mvo> _ion: !
<ogra> (in non english locales)
<siretart> mvo: pong (late) :)
<mvo> ogra: hu?
<_ion> mvo: Bug #46642, last messsage.
<Ubugtu> Malone bug 46642 in notification-daemon "Panel notification appears too low, distorts bubble" [Normal,Unconfirmed]  http://launchpad.net/bugs/46642
<ogra> mvo, bug 47139 for example
<Ubugtu> Malone bug 47139 in hwdb-client "hwdb-gui doesn't start network test when using german translation" [Normal,Unconfirmed]  http://launchpad.net/bugs/47139
<mvo> _ion: a fix for the infamous "my bubble looks like a ufo" bug?
* mvo hugs _ion
<ogra> i have another for french and a guy on IRC reporting one in es
<_ion> mvo: Worksforme
<mvo> _ion: dude, that is really really wonderful, I'm going to give it a try now
<mvo> ogra: interessting, it must be broken for 3 months then
<ogra> mvo, yes :/
<ogra> but i get the reports only since two or three days
<ogra> (wasnt the translation not in the langpacks until recently ?)
<ogra> s/wasnt/was/
<mvo> ogra: possible
<ogra> bug 46878 
<Ubugtu> Malone bug 46878 in hwdb-client "hwdb-gui translated into Slovak does not work" [Major,Unconfirmed]  http://launchpad.net/bugs/46878
<infinity> I assume you only started getting reports when you re-enadbled the hwdb button in gst or wherever it was.
<infinity> Most people don't run something they can't find.
<ogra> infinity, i neither dis nor enabled it ...
<ogra> so i dont know when it was dis/enabled
<mvo> ogra: well, the gui does not cope well with long strings, thats for sure :)
<infinity> ogra: hal, that was it.
<ogra> mvo, its canvas
<infinity> ogra: And it certainly was you who uploaded to enable to button. :)
<infinity> s/to button/the button/
<ogra> infinity, ah, yes, that one , i thought you meant the menu hiding
<ogra> i lied, i dont have a 6500, but a GeForce FX 5700
<ogra> should that use the legacy driver ? i couldnt imagine
<Mithrandir> the 5700 is fairly old
<infinity> ogra: I'm rolling a new upstream to test right now.  Hold on for a bit and I'll point you at it.
<infinity> 5700 is oldish, but hardly "legacy".
<ogra> Mithrandir, the laptop is 1 year old
<infinity> (legacy will drive it just fine, though)
<ogra> so i'd esxpect it not to be older than 2 years
<ogra> which doesnt seem legacy
<infinity> -legacy should be fine for anything up to the 6800 series.
<infinity> (I know, cause I test it on a 6800GT...)
<Mithrandir> ogra: two year old GPU chipsets are fairly old. :-P
<ogra> Mithrandir, but noty "legacy" old :)
<ogra> infinity, was a driver upgrade approval granted ? 
<infinity> ogra: No, but that won't stop me from rolling test packages, will it?
<ogra> nah
<ogra> but if it helps me and the user talking to me in PM i'd support a request :)
<infinity> Yeah.  Well, shut up and let me work then. ;)
<ogra> -legacy doesnt help btw
<ogra> oh, wait, i need to reboot i guess (always forget there is also a kernel module)
<mvo> ogra: bh, no idea what does wrong in hwdb
<ogra> mvo, can we revert your translation changes ? 
<ogra> (easily)
<ogra> mvo, gnomecanvas doesnt support line wrapping unless you use rtf text, the line wraps need to be in the text itself
<ogra> so thats easily explained
<ogra> but it looks like we should really revert to the version before transaltion, seems its broken everywhere now
<robertj> whee, who decided to make update-manager not suck finally?
<ogra> mdz, around ? 
<robertj> kudos to whoever that was
<infinity> mvo: When did I get an extra /etc/apt/apt.conf.d where it doesn't belong?
<infinity> mvo: In /etc/apt.conf.d
<Mithrandir> infinity: bug 44172
<Ubugtu> Malone bug 44172 in unattended-upgrades "ships /etc/apt.conf.d" [Minor,Confirmed]  http://launchpad.net/bugs/44172
<infinity> Ick.
<mvo> infinity: uh, no idea
<infinity> mvo: Tollef filed a bug for you already. :)
<mvo> infinity: I have it I think, thanks
<infinity> mvo: Would be nice to not have that there for release, since it'll be confusing as heck for people who put files in the wrong dir.
<infinity> (ie: I think it's more than "Minor", given the confusion factor)
<mvo> infinity: did you got my /msg?
<infinity> I did, I'm ignoring it for 10 minutes while I work on something else. :)
<mvo> Mithrandir: what bugnumber is the /etc/apt.conf.d bug?
<infinity> mvo: Look up.
<infinity> mvo: About 10 lines. :)
<Mithrandir> mvo: 44172
<mvo> infinity: *cough* right
<mvo> Mithrandir: thanks
<infinity> Mithrandir: So, let me guess, you discovered it the same way I did -- It royally screwed up your tab completion on /etc/apt/sources.list, right? :)
<Mithrandir> infinity: yup.
* infinity wonders why he never noticed until today.
<infinity> Guess I just haven't mangled my sourcs for a while.
<desrt> i don't suppose we're seeing a new kernel for dapper? :p
* desrt tweaks some stuff...
<crimsun> desrt: not before it's released.
* desrt makes an unhappy face
<desrt> the 'mouse button emulation' is moduleable
<desrt> but it does absolutely nothing unless a hook is compiled into char/keyboard.c (which is not a module)
<crimsun> desrt: something to raise to BenC for -updates, possibly
<desrt> nod
<desrt> a couple of entries to the usb hid quirks list, too
<infinity> ogra: Still here?
<ogra> infinity, sure
<ogra> sitting here crying 
<infinity> Mithrandir: new nvidia-glx in chinstrap:~adconrad/
<infinity> ogra: ^^^
<infinity> Please test.
<ogra> seems none of the nvidia-glx thingies work with *any* card of the 5000 series
<infinity> doko_: Around?
<Mithrandir> infinity: care to put them on rookery so I can be lazy and not wake my laptop?
<infinity> Yeah, but then you get to wait for my scp to finish. :)
<infinity> Which should be soon.....
<ogra> hrm
<infinity> ogra: Did I just move files where you were trying to copy them?
<ogra> why do i get no such file or directory errors ... i can see the files
<ogra> infinity, nope, only scped
<infinity> http://people.ubuntu.com/~adconrad/new_video/
<ogra> infinity, but see above
<infinity> Yeah, you could see them, then I moved them.
<infinity> Hence no such file.
<ogra> heh
<infinity> Bad me.
<infinity> Mithrandir: http://people.ubuntu.com/~adconrad/new_video/
* infinity prepares to test the fglrx bump on his laptop.
<infinity> The nvidia-glx looks good, though.
<mdke> new drivers eh?
<mdke> nice
<mdke> you guys rock
<infinity> mdke: Not necessarily slated for release, but the more testing I can get, the better.
* ssam wonders if they'll fix bug 46034
<Ubugtu> Malone bug 46034 in nvidia-glx "Page crashes X" [Major,Confirmed]  http://launchpad.net/bugs/46034
<mdke> infinity: i don't have any hardware, but I bet if you post to sounder or something you'll get loads
<mdke> they get all excited about things like that
<highvoltage> mdke: sounder gets excited about everything ;)
<mdke> highvoltage: that is true
<infinity> ssam: Only one way to find out.  Test for me. :)
<infinity> ssam: If it fixes a large number of bugs, I'll petition for inclusion.  If it's "not much better, really", we can wait.
<ssam> infinity, i am affraid im on ati here :-)
<Mithrandir> infinity: Zofia's machine's clock is off.
<infinity> ssam: There was a new fglrx in that directory too.
<ogra> infinity, YAY
<Mithrandir> but let's see if this bird flies now.
<infinity> Mithrandir: Probably, yeah.  WinXP machine, but likely has UTC=yes set.
<ogra> infinity, perfect here
<ssam> infinity, on powerpc :-) no binary drivers for me
<infinity> ssam: Oh. :)
<infinity> ogra: Seriously?
<ogra> yes
<infinity> !
<ogra> too sad thats my test machine
<infinity> ogra: And neither of the other two versions worked for you at all?
<ogra> and i have to wipe the beauty again next week
<ogra> noper
<infinity> ogra: Well, that's certainly something worth reporting, then.
<ogra> neither legacy nore the default -glx one
<ogra> and the user i talked to in #ubuntu-de had a 5200 that showed the same symptoms
<infinity> ogra: Is he still around to test?
<ogra> nope, seems not
<ogra> but i'll poke him if i see him
<ogra> hmm
<ogra> my distributor logo disappeared suddenly ...
<ogra> how weird
<Mithrandir> infinity: almost there.
<Mithrandir> *0   1600 x 600    ( 542mm x 203mm )  *50
<h3sp4wn> Is it probability or fglrx 8.25.18 going into dapper zero (I don't need help on installing it but I believe (according to the change log) it will stop my machine hanging every time I shutdown)
<infinity> h3sp4wn: Can you test the packages at http://people.ubuntu.com/~adconrad/new_video/ and confirm for sure if it fixes your crash?
<h3sp4wn> No problem at all
<infinity> h3sp4wn: If so, the odds may increase.
<Mithrandir> infinity: turning edid back on helped:
<Mithrandir> *0   2560 x 1024   ( 684mm x 271mm )  *50
<infinity> Mithrandir: So, it's fixed your issue?
<Mithrandir> infinity: yes, great, thanks.
<Mithrandir> infinity: tell Zofia to kiss you from me, or something.
<infinity> Okay, I need to start tallying success stories.
<infinity> ogra: That's a laptop with a 5200Go in it?
<h3sp4wn> infinity: I just build the module with module-assistant or is the kernel / restricted modules their already have it in ?
<infinity> h3sp4wn: The grab the linux-restricted-modules package there that matches your kernel.
<infinity> h3sp4wn: So, 2.6.15-23-{386,686,k7,amd64-geneic,amd64-k8,etc}  Whichever one you're using. :)
<infinity> "The grab"?
<infinity> Try "Just grab..."
<bgertzfield> h3sp4wn: linux-restricted-modules was made to let the build daemons auto-build all the kernel modules
<bgertzfield> no need to use module-assistant.
<Kamion> oh crap, I've just guessed why zyga had the noninteractive frontend set
<ogra> infinity, nope, he hasnt a laptop, i have an amd64 laptop with 5700go 
<infinity> Kamion: ubiquity's leaving it in noninteractive
<infinity> ?
<Kamion> infinity: correct
<h3sp4wn> I know I didn't know whether that particular dir just had the source and the updated package (and the kernel was for something else)
<ogra> (running i386 currently)
<Mithrandir> infinity: also, cleaning LCDs is good.  Makes stuff look _much_ better.
<Kamion> I'd forgotten that livecd.sh set that the HARD way
<Mithrandir> anyway, I'm off to bed.
<infinity> ogra: Okay, so the machine that just started working again was an amd64 5700Go?
<Kamion> (by whacking it into /var/cache/debconf/config.dat)
<Kamion> :q
<bgertzfield> Kamion: ubiquity changed it? damn
<Kamion> (oops)
<bgertzfield> that makes sense
<infinity> Kamion: That's the only way to set it early.
<Kamion> bgertzfield: no - ubiquity *didn't* change it
<bgertzfield> ahh
<Kamion> bgertzfield: the live CD build process sets it to noninteractive
<h3sp4wn> infinity: I will give you the results as soon as I have checked it a few times
<bgertzfield> Kamion: got it
<Kamion> infinity: I think that should be undone at the end of livecd.sh
<bgertzfield> yeah, that'll be a problem -- the new vmware-player package needs interactive mode just like sun-java5-jre
<Kamion> it means that package installation on the live CD behaves incorrectly
<infinity> Kamion: Well, in the old use case, it shouldn't have been, IMO.  Interactive package installs on a livecd are a nuissance anyway. :)
<infinity> Kamion: But yeah.  It should probably be unset again.
<Kamion> dialog, I think
<Kamion> (i.e. the default)
<infinity> Kamion: medium, dialog
<ogra> infinity, yep
<infinity> I assume we're setting it to critical, noninteractive.
<ogra> infinity, in i386 mode
<Kamion> you don't set the priority, just the frontend.
<infinity> Kamion: Err, wait, Ubuntu's default is high, not medium, right?
<infinity> Oh, we don't fudge the priority anyway?  Good.
<infinity> No need to unfudge it. :)
<Kamion> it's high, yes
<Kamion> 'echo RESET debconf/frontend | chroot $ROOT debconf-communicate' oughta do it
<infinity> Did you just test that on a live session?
<infinity> Or just assuming, due to your debconf guruness? :)
<Kamion> just assuming :)
<infinity> ("gurosity"?)
<Kamion> I'll test it now
<infinity> Danke.
<Kamion> that works but leaves it without the seen flag
<Kamion> chroot $ROOT debconf-communicate <<EOF
<Kamion> RESET debconf/frontend
<Kamion> FSET debconf/frontend seen true
<Kamion> EOF
<Kamion> maybe a >/dev/null thrown in there too
<infinity> Is there nothing less hackish that fiddling it directly?
<Kamion> you already *are* fiddling it directly - given that, unfiddling it is the least hackish approach IMO
* mdke lols at gurosity
* infinity laughs.
<infinity> Kamion: Fair enough.  I'll try the above on the next builds.
<Kamion> I'm assuming just exporting the environment variable didn't work right for some reason
<Kamion> thanks
<infinity> Exporting the envvar seems to be problematic in certain cases.  I've run across that myself.
<infinity> But in this case, it may have just been lamont applying a hammer.  That code predates me.
<Kamion> thought it might, it kinda bore lamont's metaphorical signature
<Kamion> if you ever track down said cases, I'm interested in trying to fix that
<Kamion> them
<infinity> They could be long gone cases of Debian past.
<infinity> But if I trip on one again, I'll let you know.
<Kamion> thanks
<Kamion> the environment variable should be higher priority than the value of debconf/frontend in the db anyway
<infinity> Oh, we already have a mess of debconf-communicate action in there anyway.
<infinity> Obsolete, at that, since it's for postfix.
<Kamion> and inefficient since it calls debconf-communicate twice in a row (although who cares)
<infinity> Kamion: Is there any reason why that needs to be done in one session, other than speed?
<Kamion> no reason, just seems pointless to load and save the database twice rather than once
<infinity> I waste severl minutes elsewhere, and you're trying to save me .5 seconds.  How sweet. :)
<Kamion> :-)
<h3sp4wn> infinity: I have just tried it 3 time  (it shutdown propely the first 2 but not the 3rd however I think on the third time kde was still initialising so that may have been the reason why it wouldn't (it has never shutdown properly at all before just now)
<infinity> h3sp4wn: Right, from never to 2 out of 3 is still good enough for me to call that a win.
<h3sp4wn> infinity: That is what I would say - Thanks for saving me the hassle of building them myself
<h3sp4wn> infinity: I have just tested it another twice so out of five attempts it has only not shutdown once (when I think kde was still loading) (from zero before)
<lucas> hi
<lucas> will there be some space in the release notes for important bugs that haven't been fixed before release ?
<infinity> lucas: Yes, there will be.
<lucas> bug 30447 would be a good candidate ..
<Ubugtu> Malone bug 30447 in xserver-xorg-driver-ati "Lockup problems with both the free xorg ATI driver and the proprietary fglrx driver, using various ATI cards" [Major,Confirmed]  http://launchpad.net/bugs/30447
<infinity> (I'd like it if there wasn't a need, but there always is)
<\sh> infinity: good that you are still awake :) gnade, can you magically tell your ubuntu build system to build sourcepackage "gnade" just for i386? 
<infinity> lucas: That bug is WAY too vague to really mention as a "know issue"
<lucas> yeah, I personally think that merging the bugs for both drivers was a mistake
<infinity> lucas: For instance, some fglrx crashers DID get fixed with the latest version (mine did, so did h3sp4wn's), and none of those relate to the ati/radeon DRI crashers.
<infinity> lucas: It's not even two bugs.  It's probably dozens.
<lucas> probably
<infinity> lucas: Saying "it's known that some video BIOSes on some video cards don't play nicely with some of our video drivers sometimes" isn't much to go on.
<infinity> (Note that lots of us have ATI cards that work fine..)
<lucas> yeah, but the "disable DRI" workaround should be mentioned somewhere
<lucas> since it seems to solve the issue for the free driver
<infinity> Yeah, perhaps so.
<infinity> \sh: Why?  It also built okay on sparc.  I suspect it should be buildable everywhere, if the code was a bit more portable.
<infinity> \sh: Oh, or if gnat was up to date elsewhere. :)
<infinity> \sh: Either way, not going to stop it from trying.  Having it fail doesn't hurt anything.
<\sh> infinity: oh yes, I just forgot to mention sparc powerpc and kfreebsd-i386 ;)
<\sh> looks like I need to learn a new language to fix some other ada stuff :(
<ogra> \sh, learn haskell :) then you can work at linspire (they switch all essential bits to this ubercommon language)
<\sh> ogra: well, first, I don't want to work for linspire, and second, wtf is haskell? ;)
<ogra> this language everyone knows :)
<\sh> oh cool, i'm not everyone ;)
<ogra> \sh, nah, we're just to dumb for such high level languages
* ogra guesses people like infinity already have written haskell :)
* \sh is learning erlang
<ogra> shudder
<\sh> ogra: ejabberd is writtein in erlang and it's working and working, no outages in the last 6-12 months :) all C stuff was crashing, but not this erlang stuff, great
<ogra> heh
<lucas> \sh: how many concurrent online users do you have on your server ?
* lucas considering a move to ejabberd
* _ion uses ejabberd.
<\sh> lucas: around 500-1000 depends on the day of the week
<lucas> ok
<lucas> which DB backend do you use ?
<\sh> lucas: the standard one..i'm using still ejabberd 1.0 without mysql
<lucas> ok
<lucas> thanks :)
<\sh> lucas: the backup of the database is easy and you can add more ejabberds to run in clustermode 
<lucas> yeah, but I was going for mysql, to be able to integrate other services more easily
<doko_> infinity: pong
<mdke> Riddell: any luck with those kubuntu-docs .desktop files?
<infinity> doko_: Can you test the LRM stuff at http://people.ubuntu.com/~adconrad/new_video/ for me?
<infinity> doko_: Let me know if it resolves any bugs for you.
<doko_> infinity: downloading ...
<bmonty> \sh: rshell/rs -image tmp/system.bas -c.repl system.img
<bmonty> oops, sorry
#ubuntu-devel 2007-05-21
<sn0> packages.ubuntu.com down ? or just me
<Nafallo> sn0: yes :-)
<sn0> Nafallo ok :] 
<Nafallo> sn0: there is however equivalent functionality in something we call launchpad... :-)
<sn0> Nafallo thanks, im aware of launchpad, was just browsing flash versions for a friend :D
<Nafallo> :-P
<Hobbsee> or apt-cache madison
<sn0> bloddy flash :p its evil
<Nafallo> gnash? ;-)
<sn0> i can't wait until gnash is a good replacement 
<psusi> iwj: got a second to discuss the new udev/dm/md stuff?
<mjg59> psusi: 03:54 in .uk
<psusi> ahh, he's uk eh?
<psusi> anyone awake right now that knows much about it or is working on it?
<psusi> BenC: maybe?
<womble> Is there an Ubuntu equivalent of snapshot.debian.net?
<persia> womble: https://launchpad.net/ubuntu/+source/<src-pkg-name> is fairly close, but not quite the same.
<womble> persia: Not quite the same, but almost certainly close enough for my purposes.  Thanks.
<pitti> Good morning
<Hobbsee> hi pitti!
<pitti> Good morning!
<ajmitch> hey pitti 
* beuno sees activity in the channel and takes to opportunity to pick the dev's brains
<beuno> I'm about to release UWN, anything worth mentioning about Gutsy?
* beuno deletes the "New in Gutsy" section
<jmg> haha
<fabbione> morning guys
<ajmitch> morning fabbione 
<Hobbsee> hi fabbione 
<mneptok> arrr!
<ajmitch> uh oh
<fabbione> hmmm did we already switch gutsy to .22?
* Hobbsee beats mneptok with a club
<fabbione> as default i mean
<crimsun> fabbione: no.
<fabbione> ok thanks
<pitti> fabbione: I saw several -meta uploads already, but at least on amd64 I still didn't get it yet
<mneptok> Hobbsee: please. my girlfriend has already been hospitalized on this trip. :/
<fabbione> pitti: neither did x86...
<mneptok> (looooong story)
<fabbione> mneptok: whops...
<Hobbsee> mneptok: then you shouldnt have beaten her up!
<mneptok> but all is well. the Romanians are taking *very* good care of us.
<pitti> siretart, Riddell: wrt. http://merges.ubuntu.com/libt/libtunepimp/libtunepimp_0.5.3-2ubuntu1.patch, do we still actually need to keep the mp3 package separate? or can we move this stuff back to main?
<mvo> doko_: I take the eject merge
<crimsun> cjwatson: hi, do you know if the autosyncer is capable of running for universe but not for main?
<doko_> mvo: thanks
<Mithrandir> crimsun: hm, unsure.  I guess we could do that.
<mvo> doko: hdparm, lshw too
<Mithrandir> crimsun: why?  Want to continue syncing into universe long than for main?
<crimsun> Mithrandir: yes.  We had a protracted discussion earlier regarding fixes not making it into Universe.
<crimsun> (We-> in -motu)
* Starting logfile irclogs/ubuntu-devel.log
<jsgotangco> leut?
<jml> dict.leo.org isn't helping me
<jml> unless perhaps 'leute' is meant.
<pitti> jsgotangco: 'Leute'
<jsgotangco> highvoltage: brush up your french!
<jsgotangco> *g*
<highvoltage> I thought 'leut' is singular for leute :)
<Treenaks> highvoltage: there isn't a singular for leute :)
<Treenaks> afaik
<highvoltage> aah
<pitti> right
<pitti> 'leute' == 'people', and like in English there is no singular
<gnomefreak> person?
<pitti> gnomefreak: yep
<ajmitch> what's up with the buildds? they're all idle, and a number of packages are in 'needs building' state
<Mithrandir> ajmitch: I'll take a look
<ajmitch> thanks
<Riddell> pitti: yes it needs to be separate, we can't have mp3 on the CD
<pitti> Riddell: ah, ok
<seb128> mjg59: do you think that your 20_mixer-applet_use_gstreamer_notify.patch could make the icon not being updated when the volume is changed?
<Fujitsu> The binaries for qgis were all rejected (I presume due to this Soyuz crazyness)... What do I do about it?
<seb128> Fujitsu: what crazyness?
<ajmitch> seb128: stuff in needs building state for a few days, with buildds idle
<Fujitsu> The buildds were doing strange things, and those binaries were rejected soon after Mithrandir said he'd take a look.
<Fujitsu> I think they might be related, considering I've never had binary rejections before.
<seb128> k
<Mithrandir> Fujitsu: you read your bug mail. :-P
<Mithrandir> Fujitsu: libqgis1 includes .so symlinks, please fix that.
<Fujitsu> Oh, I see.
<Mithrandir> they should go in the -dev package
<Fujitsu> Just noticed that.
<Fujitsu> Hmmmm... my changes from the Debian package are minimal.
<Fujitsu> Mithrandir: My inbox gets read before bugmail, and I knew the buildds were being strange, so...
<Mithrandir> I'm not saying it's your fault, just saying it's a bug.
<Mithrandir> the buildds don't usually generate binary rejects, btw.
<StevenK> No, the archive will.
<StevenK> Well, Soyuz
* StevenK idly wonders if Soyuz supports crazyness like UNACCEPT.
<Mithrandir> StevenK: it's called "rejecting out of the accepted queue", and yes, we've done so in the past.
<Mithrandir> it's only insane when you do build-from-accepted.
<Mithrandir> if you don't, it's not really a big issue.
* StevenK nods.
<Fujitsu> Do you normally check binaries?
<StevenK> Sometimes I wish we did build from accepted, but given cron.daily runs hourly it isn't a huge issue.
<Mithrandir> Fujitsu: yes
* ajmitch recalls UNACCEPT being used once in debian within recent memory
<Mithrandir> StevenK: we're probably going to at some point.
<StevenK> ajmitch: I can only recall Daniel Stone + XFree86 4.3
<Mithrandir> ajmitch: it was used for a premature upload of a newer xorg versions, I've had it happen when udebs were first introduced.
<ajmitch> that was what I was thinking of
<Mithrandir> s/xorg/xfree86/, yes
* ajmitch hopes that ADSL2+ actually comes to this area sometime this year
<ajmitch> uploading large packages is painful
<StevenK> Try it on 256Kbit.
<ajmitch> that's what I have for upstream at the moment
<StevenK> Ah
<slomo> are autosyncs not working anymore? i see at least one package that should've been autosynced since about a week
<TimGroe> Hey, I don't know if this is the tight place to anounce this, but I have made a new system for building .deb files abit like checkinstall, but more ... structured
<Mithrandir> slomo: they are, I just finished a run, why.
<Mithrandir> slomo: as in, what package?
<TimGroe> http://timg.ws/?p=20
<slomo> Mithrandir: gnome-sharp2
<TimGroe> It accepts a file like Frugalware's FrugalBuild or Arch Linux's PKGBUILD
<Mithrandir> slomo: gnome-sharp2 |   2.16.0-3 |         gutsy | source
<Mithrandir> isn't that the right version?
<Mithrandir> hm, no -6 is current in debian
<Mithrandir> [BLACKLISTED]  gnome-sharp2_2.16.0-3
<slomo> weird... why is it blacklisted?
<Mithrandir> caused something to blow up, but it's worky now; synced.
<slomo> thanks :)
<pitti> Riddell: hm, I'm still confused about libtunepimp -- it does not depend on anything except libtunepimp5; does it contain codecs? I thought it was just a lib for tag handling
<Riddell> pitti: interesting, I'm sure it used to depend on libmad
<pitti> Riddell: the source b-deps on libmad-dev, but there's no binary dependency
<Riddell> pitti: ldd /usr/lib/tunepimp/plugins/mp3.tpp | grep mad
<Riddell> pitti: it does need libmad, I think it just doesn't have a depend because shlibs doesn't find the library with the weird extension
<pitti> Riddell: ah, so I should add that explicitly
<Riddell> pitti: yes
<TimGroe> will an OpenVZ-enabled kernel make it into Ubuntu ?
<TimGroe> I am running one now on Ubuntu 7.04 (Linux kernel 2.6.20) and it runs a treat
<Lutin> Adri2000: tu parles bien de "02:39 < Hobbsee> it may not have the sources, but the author is not evil"
<Lutin> err.
<dholbach> doko: do you have any idea what happens in  http://daniel.holba.ch/temp/pydbg ?
<dholbach> doko: the current version is broken, so I'll upload the merged version (which is broken in the same way) - it'd be nice if you had a idea about this
<Keybuk> You are not the bug assignee nor the maintainer of libtool (Ubuntu), and therefore cannot edit this bug's status.
<Keybuk> err, wtf?
<Mithrandir> you're not logged in?
<Keybuk> aha!
<fabbione> it seems like LP lost all autologin stuff
<Keybuk> Mithrandir: bingo
<fabbione> or chanced cookie or whatever
<Mithrandir> it did that on friday or so.
<fabbione> i noticed only today
<Keybuk> several UI bugs in one go there <g>
<Mithrandir> now that you're logged in, you should file them. :-P
* Keybuk is confused
<Treenaks> Why?
<Keybuk> APT claims there are no updates
<Mithrandir> Keybuk: the buildds are borked.
<Mithrandir> or the slave scanner, more likely
<Keybuk> have you tried restarting it?
<Mithrandir> yes
<Treenaks> Keybuk: </IT Crowd>
<Mithrandir> 2007/05/21 12:56 BST [-]  Job slave_scanner completed with exit code 1
<Keybuk> this includes things that have been built
<Keybuk> e.g. powertop, apt doesn't think it is in the archive
<Keybuk> builds aren't making it into the queue?
<Keybuk> psycopg.IntegrityError: ERROR:  duplicate key violates unique constraint "buildqueue__builder__unq"
<Keybuk> ouch
<Keybuk> ww too ;)
<Mithrandir> somehow, I don't envy people subscribed to the error reporting mailing list.
<Mithrandir> it's been mailing that list once every ten seconds over the weekend or so
<StevenK> Woot
<Fujitsu> Heheh.
<Keybuk> *hugs* them
<Mithrandir> there, cprov saves the day.
<robertj> is https://bugs.launchpad.net/bugs/95460 a candidate for a fix in -updates?
<ubotu> Launchpad bug 95460 in samba "samba 3.0.24 on feisty is broken" [Undecided,Needs info]  
<robertj> apparently some KDE util is b0rking every share it touches by adding invalid config options
<StevenK> Mithrandir: Hrm. Did cprov just un-save the day? All of the buildds are idle again.
<Mithrandir> yes, but Ng is saving the day instead.
<Mithrandir> it was slightly more complex than we first thought.
<StevenK> Ah
<Hobbsee> hey all
<Treenaks> hi Hobbsee 
<Mithrandir> hi Sarah
<Hobbsee> :)
<Hobbsee> Mithrandir!
<fabbione> yo
* Hobbsee stomps on Mithrandir's feet in greeting
<Hobbsee> hiya fabbione :)
<seb128> hey Hobbsee
<Mithrandir> Hobbsee: /me sees Hobbsee stomp the ground.
<Mithrandir> s/Hobsee: //
<Mithrandir> well, without typos, anyway.
<Hobbsee> heh
<Mithrandir> I'm levitating.
<Hobbsee> oh really now?
<Mithrandir> yeah, you should come see
<Hobbsee> Mithrandir: dont tempt me :P
<Hobbsee> Mithrandir: you could post pictures, at least
<Mithrandir> do you realise how hard it is to take pictures of yourself levitating?
<Mithrandir> it screws up my concentration
* Hobbsee points to Simira 
* Hobbsee points to Odin
<Hobbsee> take your pick.
<StevenK> Neither of those is a garden implement.
* StevenK ducks
* Hobbsee bashes StevenK with large, metal, spiky garden implement.
<StevenK> Ouch!
<Treenaks> bashes, not pokes?
<StevenK> That's going to bleed when my heart beats!
<jsgotangco> the classmate just died
<Mithrandir> Hobbsee: they're both at home.
<Hobbsee> Mithrandir: ahh.  then find someone at the office?
<Treenaks> or a random stranger off the streets?
<Mithrandir> nah, can't be bothered.
<Hobbsee> (hi seb128)
<StevenK> Mithrandir: Has Ng saved the day yet?
<StevenK> Hrm. I haven't seen Rails do that before.
<Mithrandir> StevenK: yes, but I'm not sure whether soyuz now works by pure willpower or what.
<Mithrandir> the last line in the log file says: 2007/05/21 13:11 BST [-]  Server Shut Down.
<StevenK> Heh. Ng might just be running it through his head.
<StevenK> Ah. The page I haven't seen before is Rails returning 500.
<joebleaack> salut
<Hobbsee> greetings
<joebleaack> am si eu o mica intrebare poate ma poate ajuta careva
<Hobbsee> in english?
<joebleaack> k
<robertj> pitti: whats the next step in the life-of-a-spec after it has been drafted? does it get assigned first or does it get a release target first?
<joebleaack> i have an adsl connection to the internet but i ca't conect my ubuntu relese 
<shawarma> joebleaack: Try in #ubuntu
<joebleaack> thru an adsl modem 
<joebleaack> #ubuntu
<shawarma> Or #ubuntu-ro
<pitti> robertj: usually assigned, since it's hard to predict feasibility without an assignee
<shawarma> (I'm guessing you're Romanian?)
<joebleaack> it is line
<joebleaack> yep
<shawarma> type:
<shawarma> /join #ubuntu-ro
<robertj> pitti: and low-priority specs need to find their own assignees I assume
<joebleaack> well
<joebleaack> haw can i setup my adsl modem
<shawarma> joebleaack: Ask in the other channel that you just joined.
<joebleaack> it is an alcatel stpeed touch 330 
<shawarma> joebleaack: Type "/join #ubuntu-ro", find the window for that channel and ask there. It's a Romanian ubuntu channel.
<Hobbsee> joebleaack: this is not a channel for support.  please see the /topic
<ssam> is bug Bug #109204 suitable for an SRU? it has a well tested small patch
<Hobbsee> ubotu: wake up
<ubotu> Sorry, I don't know anything about wake up - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<ssam>  Bug #109204
<ubotu> Launchpad bug 109204 in gnumeric "Gnumeric strange colors (purple charts) on bigendian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109204
<ssam> Hobbsee, ubotu thought it was kernel bug for some reason
<Hobbsee> weird
<Hobbsee> ssam: looks like a good candidate for a SRU
<ssam> Hobbsee, cool, do i need to pester someone for that
<Hobbsee> !sru
<Hobbsee> follow the ^ process
<Hobbsee> !ping
<ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse.
<ubotu> pong
<Hobbsee> laggy bot.
<ssam> do i need to be a dev to do it?
<Hobbsee> no
<Hobbsee> you'll need someone to sponsor your work though (which is why there is the ubuntu-universe-sponsors / ubuntu-main-sponsors)
<ssam> thanks, it wont be until later in the week that i'll have a block of time to do this, but i'll give it a go.
<TimGroe> has anyone had a chance to look at Easypkg?
<TimGroe> http://ubuntuforums.org/showthread.php?t=450251
* Mithrandir prods the bleep
* bleep BLEEP
* bleep bites Mithrandir with the sharp, pointy teeth.
<ion_> Onomatopoetic nicknames ftw.
<StevenK> Oooh, shiny
<Shiny> yes.
<dholbach> doko: do you have any idea why https://launchpad.net/ubuntu/+source/gnome-python/2.18.2-1ubuntu1 ftbfs?
<dholbach> doko: (it worked nicely for me in a puilder)
<pitti> BenC: hmm, where did /proc/version_signature disappear to?
<Shiny> pitti: i ate it.
<pitti> BenC: the current apport hook uses it to figure out the source package version; if it's gone for good, I need to change that
<bddebian> Heya
<pitti> BenC: hm, and it seems that the current 2.6.22 kernel dropped the core_pattern fixes
<TimGroe> Hobbsee: A fellow Australian :)
<TimGroe> lol, goto bed!
<Hobbsee> yep :)
<Hobbsee> it's only midnight
<TimGroe> aha, I know :P
<Hobbsee> and i didnt even leave work 2 hours ago..
<TimGroe> :O
<TimGroe> damn
<BenC> pitti: Ah, yeah, I'm working on getting all our patches back in from 2.6.20 today
<BenC> pitti: next upload this week will have them
<pitti> BenC: ah, great; so it's known
<pitti> thank you
<pitti> BenC: btw, do you see a chance of getting them upstream?
<pitti> (the two fixes to core_pattern behaviour)
<BenC> pitti: I'll work on sending those out too
<psusi> iwj: got a second to talk about the dm/mdm/evms/lvm/udev again stuff?
<dholbach> doko: it seems gnome-python ftbfs because dpatch is broken somehow
<cjwatson> crimsun: I tend to think that's a risky option (autosyncing universe but not main), as it increases the chance of ending up syncing only part of some transition or other from Debian - especially while Debian is in an unrestricted development phase
<Keybuk> pitti: iwj is away this week, what's the issue?
* pitti looks confusedly at Keybuk 
<\sh> doko, do you plan to add the gnu "d" (gcd) compiler to the existent gcc toolchain for gutsy?
<pitti> Keybuk: aah, that was meant for psusi, I figure
<Keybuk> err, yes
<Keybuk> p<tab> loses
<Keybuk> psusi: iwj is away this week, what's the issue?
<pitti> Keybuk: set completion_amount=0
<psusi> Keybuk: wanted to discuss udevlvmevmsagain spec, you familliar with it?
<Keybuk> psusi: yes, pretty familar :)
<psusi> ok... I have a bit of an issue with the part about ignore the kernel events, and make up your own
<psusi> what's wrong with using the kernel events properly?
<Keybuk> the apparent problem is that mdadm issues the add /block/md0 event before the array is usable
<Keybuk> and that devmapper devices may also not be usable at the point the kernel event is emitted, since they might be transient as part of e.g. lvm snapshot creation
<psusi> that's fine... udev should be able to deal with this by not doing its processing until the CHANGE event that makes it usable
<Keybuk> the difficulty is determining at the point of the CHANGE event, whether it is usable or not
<giskard> mjg59, Wakeups-from-idle per second :  1501.8 , a lot?
<giskard> ;)
<BenC> giskard: huge
<bdmurray> joejaxx: ping
<tkamppeter> pitti, Mithrandir, hi
<slomo> yay, dpatch is broken
<pitti> hi tkamppeter 
<tkamppeter> pitti, Mithrandir, I have sorted out the Ghostscript merger issues with Masayuki Hatta from Debian. We agreed on naming it ghostscript and I also got info about the C headers from upstream, so they are included in my new test packages, too.
<joejaxx> bdmurray: yes?
<pitti> tkamppeter: I saw you mails, thanks
<pitti> tkamppeter: so the only issue left is now that upstream regression wrt. breaking PDF GUIs?
<bdmurray> joejaxx: I saw a bug pertaining to ubuntu studio and ended up subscribing you to it.  Does that seem reasonable?
<tkamppeter> pitti, Mithrandir, and Masayuki suggested to split the docs into an extra package. This saves 8 MB on an installed system, so we have more space on our ISOs.
<pitti> tkamppeter: great!
* pitti -> dinner, bbl
<cjwatson> about 3.4MB compressed
<cjwatson> which is still not to be sneezed at of course
<tkamppeter> Yes pitti, for now we can put the package only into Gutsy so that users can test around. As soon as the upstream bug is fixed, we should think about backports.
<joejaxx> bdmurray: you should subscribe bugs to ubuntustudio-dev
<bdmurray> joejaxx: sounds good
<Keybuk> pitti, keescook: can you remember if there were any problems caused by devmapper spinning on devices?
<keescook> Keybuk: I don't think so; but perhaps I'm unclear on when that would happen.
<keescook> you're talking device creation spin?
<Keybuk> right, at the moment devmapper spins until udev creates the device
<keescook> only that sometimes it doesn't wait long enough in feisty.
<keescook> (the lvm snapshot problem, as i understand it)
<geser> pitti, Mithrandir: could you please accept vpnc for feisty-proposed?
<Keybuk> keescook: I think that's a waiting for the wrong devices in the wrong order problem
<keescook> ah, I thought the lvm snapshot issue was the something in udev was running vol_id on one of the temporary devices so that when lvcreate tries to delete the device, it find it still open and bails out
<Keybuk> yeah, we have a fix for that now
<keescook> oooh, what's the fix for that (since I still run into this issue)?
<Keybuk> SuSE have a patch to dmsetup to make it export the status of a dm device in a format udev can enter into its info db
<Keybuk> so we do that, and check ENV{DM_STATE}!="ACTIVE" :p
<Riddell> bdmurray: can you do the sru-verification on https://bugs.launchpad.net/ubuntu/+source/hwdb-client/+bug/91948 ?
<ubotu> Launchpad bug 91948 in hwdb-client "[apport]  hwdb-kde crashed with UnicodeEncodeError in assemble()" [Medium,Fix committed]  
<keescook> Keybuk: ah, very nice.
<bdmurray> Riddell: briefly reading the bug it seems that the key for reproducing the crash is non-ascii characters is that right?
<Riddell> bdmurray: yes, just enter something non-ascii in one of the comment text fields and see if it crashes
<pitti> geser: bug number?
<bdmurray> Riddell: okay, I'll get to that soon
<pitti> Keybuk: devmapper spinning on devices> no idea, sorry
<geser> pitti: bug #93413, that's the one you tried to accept on friday
<ubotu> Launchpad bug 93413 in vpnc "vpnc dead peer detection disconnects immediately" [Medium,Fix committed]  https://launchpad.net/bugs/93413
<geser> it doesn't show up in LP and I asked Mithrandir to look after it, he said it's still in the queue
<pitti> geser: not sure what you mean -- I did accept it?
<pitti> hm, weird
<pitti> geser: can you please add/update the tasks? is it fixed in gutsy?
<geser> yes, I uploaded a the same patch ti gutsy already
<geser> I opened a task for feisty but can't accept it
<pitti> geser: oh, that's nasty -- as u-core-dev you should really be able to
<geser> pitti: I'm only a MOTU, not core-dev
<pitti> geser: hm, I cannot accept it either
<pitti> mdz: hm, was it on purpuse that only ubuntu-drivers can accept bug tasks for stable releases now? that's really awful
<pochu> geser: I can, and I'm neither core-dev nor motu :)
<geser> pochu: open or accept?
<pitti> I can only nominate, too
<pochu> geser: go to launchpad.net/ubuntu/*feisty*/+source/package/bugnumber, and click on "Should be fixed on Feisty too"
<geser> pochu: " Nominated  for Feisty  by Michael Bienia
<geser> "
<pochu> geser: which bug?
<mdz> pitti: it's sort of a bug.  the same access controls are used for feature planning and bug targeting, which are completely different
<geser> bug #93413
<mdz> pitti: need to start a thread on launchpad@ to get it fixed
<pitti> geser: anyway, accepted for real now; sorry
<ubotu> Launchpad bug 93413 in vpnc "vpnc dead peer detection disconnects immediately" [Medium,Fix committed]  https://launchpad.net/bugs/93413
<geser> thanks
<pitti> pochu: heh, that is a nifty workaround!
<pochu> hehe
<pitti> geser, mdz: I was able to create a feisty task with ubuntu/feisty/..., click on 'also fix here'
<pochu> pitti, mdz, geser: I opened the Feisty task on bug 103688
<ubotu> Launchpad bug 103688 in liferea "liferea crashes - ** ERROR **: file itemlist.c: line 172 (itemlist_load): assertion failed: (NULL != itemSet)" [Medium,Fix committed]  https://launchpad.net/bugs/103688
<pochu> pitti: yeah, it is :)
* pitti looks at the libtunepimp FTBFS, "dpatch  deapply-all\nset: 8: Illegal option -o pipefail" and thinks *WTF??"
<pitti> dpatch has a bashism now or so?
<pochu> pitti: I think dholbach has fixed it (or he has broken it :))
<seb128> pitti: Daniel uploaded a fix for it some hours ago
<seb128> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425285
<pitti> great, thanks
<mdz> pitti: if you start the thread and CC me, I'll join in with my thoughts
<pitti> mdz: will do, thanks
<tkamppeter> pitti, what did you do with apport? Formerly, all Ghostscript crashes resulted in nice backtraces when one added the appropriate tags.
<pitti> tkamppeter: since when is it broken?
<pitti> and what happens now?
<tkamppeter> Now in most cases the tag gets automatically removed but no retrace is posted. In other cases the retraces do not contain more information than the original bug report from apport.
<pitti> tkamppeter: please retag the first group, there has been some trouble recently
<pitti> tkamppeter: the second is probably due to obsolete versions, etc.
<tkamppeter> pitti, strange is also that formerly, the poster of the retraces was "Apport retrace service" and now it is "Martin Pitt".
<pitti> tkamppeter: I fixed the poster this morning
<pitti> yay for random LP cookie changes :)
<pochu> pitti wanted to get more karma :p
<tkamppeter> I have now added comments to all these bugs that the users should grab the test packages of the merged Ghostscript, but no user answer so far.
<bdmurray> Riddell: verification has been done
<Riddell> bdmurray: goovy, now I just need to subscribe ubuntu-archive and hope someone will move it to -updates?
<pitti> Riddell: no, just ubuntu-sru
<pitti> Riddell: I'll look for verification-done tags and move them over on my archive days
<pitti> see wiki page
<pochu> BenC: seems like linux-meta depends on 2.6.20 yet.
<pochu> emilio@kiko:~$ aptitude show linux-image-generic | grep Depends
<pochu> Depends: linux-image-2.6.20-15-generic
<pochu> BenC: am I missing anything? :)
<Riddell> pitti: wiki page isn't very clear on point 5, it talks of ubuntu-archive
<Riddell> pitti: but I'll leave it in your hands then
<pitti> right, that might be misleading
<tkamppeter> pitti, thank you, I have retagged these bugs.
<pitti> tkamppeter: if it happens again with those, I can look into the logs about the reason for failed retracing
<Riddell> pitti: adept apport notification patch at https://bugs.launchpad.net/ubuntu/+source/adept/+bug/113508
<ubotu> Launchpad bug 113508 in adept "adept notifier still notifies kubuntu users of apport crashes" [High,Confirmed]  
<ogra-classmate> hmm, i wonder how a pbuilder oreforms on this thing
<ogra-classmate> *performs
<pitti> Riddell: looks good, bug updated
* pitti -> sports, cu tomorrow
<tkamppeter> pitti, now I got again a "** Tags removed: need-i386-retrace" with "Martin Pitt" as poster, on bug 115910.
<ubotu> Launchpad bug 115910 in gs-esp "gs-esp has crashed" [Undecided,Needs info]  https://launchpad.net/bugs/115910
<Keybuk> keescook: your dmsetup-fu is strong, right?
<Keybuk> how do I make a simple devmapper device spanning a disk?
<keescook> Keybuk: my lvm-fu is strong, dmsetup is just "okay".  :)
<Keybuk> lol
<Keybuk> I'm trying "dmsetup create foo --table "0 1024 linear /dev/hda 0" but just getting -EINVAL
<tkamppeter> pitti, bug 115677 gives always a bad retrace, also with the second attempt,
<ubotu> Launchpad bug 115677 in gs-esp "[apport]  gs-esp crashed with SIGSEGV" [Undecided,Needs info]  https://launchpad.net/bugs/115677
<keescook> In lvm, I'd do:  pvcreate /dev/sdb1; vgcreate bigvg /dev/sdb1; lvcreate -L$(vgs | grep -v VFree | awk '{print $NF}') -n biglv bigvg
<keescook> I don't recommend using non-partitions
<keescook> i.e. use hda1 not hda
<Mithrandir> keescook: the last number is the size, you probably want to make that bigger.
<Mithrandir> also, echo "0 1024 ..." | dmsetup create
<tkamppeter> pitti, and all answers still with "Martin Pitt" as sender: bug 114999, bug 115677.
<ubotu> Launchpad bug 114999 in gs-esp "[apport]  gs-esp crashed with SIGSEGV" [Undecided,Needs info]  https://launchpad.net/bugs/114999
<ubotu> Launchpad bug 115677 in gs-esp "[apport]  gs-esp crashed with SIGSEGV" [Undecided,Needs info]  https://launchpad.net/bugs/115677
<Keybuk> Mithrandir: the man page says the last arg is the start sector
<Keybuk> and echo still gives -EINVAL
<keescook> Mithrandir: hm, mine shows the last param as "Free" size
<Mithrandir> hmm, true
<Mithrandir> echo "0 1024 linear /dev/sda 0" | sudo dmsetup create blat
<Mithrandir> worked fine here
<Keybuk> interesting
<Keybuk> works fine on feisty for me too
<Keybuk> maybe this devmapper is b0rked
<Mithrandir> ok course, it's far too small, but it's there.
<Mithrandir> this is gutsy.
<Keybuk> yeah, I just merged devmapper
<psusi> eh?
<Keybuk> hmm
<Keybuk> table: 254:0: linear: dm-linear: Device lookup failed
<psusi> I merged it the other day but it's still waiting on a sponsor upload
<Keybuk> psusi: did you test it?
<psusi> you merged with debian and uploaded?
<psusi> run test?  no.. just built it
<tkamppeter> pitti, bug 115777 gives not more than "StacktraceTop:?? ()" as retrace, also with "Martin Pitt" as poster.
<ubotu> Launchpad bug 115777 in gs-esp "[apport]  gs-esp crashed with SIGSEGV" [Undecided,Needs info]  https://launchpad.net/bugs/115777
<slomo> Mithrandir: please give-back mono on x86 and amd64 :) should build fine now that dpatch is fixed
<Keybuk> psusi: the debian version doesn't seem to work at all with gutsy's kernel :-/
<psusi> my merge product is attached to bug #115334
<ubotu> Launchpad bug 115334 in devmapper "devmapper: new changes from Debian require merging" [Low,Fix committed]  https://launchpad.net/bugs/115334
<psusi> the debian version or the debian version plus the ubuntu changes?
<Keybuk> just the debian version
<psusi> ahh, yea... need our fixes methinks
<psusi> try my version
<Keybuk> which fix?
<Keybuk> the only odd change was the one to ioctl/libdm-iface.c
<Keybuk> and I couldn't find any rationale for that in the changelog, so assumed it was ian debugging
<ogra-classmate> cdan anyone explain why my classmate unionfs / doesnt show up in mtab ? is that normal for unionfs ?
<coastGNU> sabdfl: Who is responsible for canonical booth coordination at LinuxTag Berlin?
<coastGNU> sabdfl: It might be a good idea to have a local ubuntu mirror at LT. Tolimar always did this on events for Debian in the past. This is a good idea to avoid traffic outside the fair lan.
<psusi> Keybuk: which change is that?
<Keybuk> +	task->major = dmt->major;
<Keybuk> +	task->minor = dmt->minor;
<Keybuk> that bit
<psusi> no, that's important... check the comment above
<Keybuk> which changelog corresponds to that?
<psusi> we look up the device number after udev creates it
<Keybuk> we do?
<Keybuk> why?
<sabdfl> coastGNU: good idea, we could also do Ubuntu On Tap (live cd boot over network, with installer for the brave)
<psusi> because otherwise you don't know what it is?
<Keybuk> I stripped out all the udev stuff from the package
<psusi> ohh
<Keybuk> this is a kernel-is-returning-EINVAL problem
<sabdfl> coastGNU: doko *might* know who is going to be there, who is technical
<psusi> it sounds like the kernel is saying it can't find /dev/hda
<psusi> try giving it a partition instead of the whole thing... specifically one that isn't mounted
<coastGNU> sabdfl: It also might be a good idea to have a list of canonical partners who are present at LT. E.G. In the past I often guided people from companies to LIVE members. We could also do so for canonical partners.
<Keybuk> psusi: how weird, why can't it be mounted any more?
<psusi> Keybuk: I'm not sure, but I think that the device mapper wants exclusive access to the underlying device... though that is entirely likely to be wrong
<Keybuk> won't that break evms? :)
<psusi> why?
<Keybuk> it likes to make devmapper devices for every single block device
<psusi> well, like I said, it is entirely likely I'm wrong about that... but it's worth a try to use an unmounted partition instead of the whole disk
<psusi> also check if it said anything in your dmesg
<psusi> it sure would make merging this thing easier if it used dpatch
<Keybuk> that's up to Debian
<Keybuk> brw-rw---- 1 root disk 254, 0 2007-05-21 19:18 /dev/dm-0
<Keybuk> lrwxrwxrwx 1 root root      7 2007-05-21 19:18 /dev/mapper/foo -> ../dm-0
<Keybuk> lrwxrwxrwx 1 root root     10 2007-05-21 19:18 /dev/disk/by-id/dm-name-foo -> ../../dm-0
<Keybuk> lrwxrwxrwx 1 root root     10 2007-05-17 22:36 /dev/disk/by-uuid/8447e94d-ec1f-4c2b-a161-ec2cff8717a7 -> ../../hda5
<Keybuk> \o/
<Keybuk> (also note how the devmapper device doesn't get to override the UUID from the raw device underneath)
<psusi> there IS no uuid link for the dev mapper device
<Keybuk> right, but there can be
<psusi> and why is /dev/mapper/foo a link to ../dm-0?  that's wrong
<Keybuk> it turns out that that is right
<Keybuk> HAL prefers the devmapper devices to have their kernel names
<psusi> why?
<Keybuk> desktop crypto handling fu
<coastGNU_> doko: Hi Matthias. sabdfl told me you *might* know who is resposible for the canonical booth at LinuxTag?
<Keybuk> and the symlink solves another issue ;)
<Keybuk> it means that devmapper can mknod() /dev/mapper/foo
<Keybuk> at the same time as udev mknod() /dev/dm-0
<Keybuk> and udev replaces the /dev/mapper/foo node with a symlink
<Keybuk> (and if devmapper sees a symlink, there's no issue)
<Keybuk> (since a stat() on that symlink will return a block device with the right dev_t)
<\sh> can someone give me a clue to tell NM or avahi to not create an eth:avahi device?
<psusi> I'd prefer to see the whole damn dm-0 go away entirely
<Treenaks> \sh: uhr.. why?
<Keybuk> psusi: any particular reason?  the kernel logs everything with that name
<Keybuk> and the sysfs object has that name
<\sh> Treenaks, just because if I  don't have an ethX connection (neither wired nor wireless) I don't want to have any network interfaces up
<Keybuk> it's kinda kooky that it's missing on the disk
<Keybuk> and we don't lose anything from having it
<psusi> I dunno... I just don't like it ;)
<\sh> Treenaks, problem is, when I start my cisco vpn over ppp0 the cisco ipsec device tries to bind itself on the first ethernet device which is up, which means, eth0 and not ppp0 e.g.
<\sh> Treenaks, but I don't want to tell NM to disable the network completly 
<psusi> so why don't you have a uuid link?
<Keybuk> psusi: why should it?
<Keybuk> that uuid is already taken by /dev/hda5; and real block devices have a higher priority than devmapper ones
<psusi> ohh, right... they would have the same uuid
<Keybuk> yeah
<Keybuk> new udev has device priorities
<Keybuk> so you can say "this device wins over this device"
* Starting logfile irclogs/ubuntu-devel.log
<psusi> Keybuk: so you have it all working now?
<Mithrandir> slomo: slightly hard when there are "no builds recorded".
<slomo> Mithrandir: hm? https://launchpad.net/ubuntu/+source/mono/1.2.4-0ubuntu2 lists them
<Mithrandir> slomo: argh, I got bitten by the "the top of the version list is not necessary the newest one"
<Mithrandir> given-back
<slomo> thanks :)
<ajmitch> morning
<Keybuk> psusi: I think so, we'll see :)
<psusi> cool
<ion_> What would be really neat is if Ubuntu used 6to4 by default if the computer has a public IPv4 address and no IPv6 default route. Perhaps i should try to hack that some day or century.
<Keybuk> yeah
<Keybuk> that way we'd lose about 25% of our userbase when they can't get on the net
<Keybuk> <g>
<ajmitch> who needs them anyway? :)
<Keybuk> the IPv6 problem is that most people's ISP-supplied DSL routers do not deal with IPv6 well
<ion_> Of course the automatic 6to4 connectivity must be tested before a 6to4 route is added.
<Keybuk> and since the real world still uses IPv4, enabling IPv6 by default isn't important
<ajmitch> and for sites that are accessible via ipv6, it's often slower reaching them
<ion_> The available IPv4 resource pool has now been reduced to the point that ARIN is compelled to advise the Internet community that migration to IPv6 is necessary for any applications that require ongoing availability from ARIN of contiguous IP number resources.  http://www.arin.net/announcements/20070521.html
<Keybuk> heh, nothing will happen until the day they refuse to ever allocate an IPv4 address again
<psusi> yep
<Keybuk> not to mention they'd have to get RIPE, etc. to join in
<Keybuk> my ISP is arguably the biggest in the UK, and one of the largest in Europe, and they still have no IPv6 provisioning :-/
<ajmitch> APNIC wouldn't be a problem, we've got most of the world's population & probably the fewest ipv4 blocks
<maswan> Well, it keeps getting harder, as in more documentation required for justification etc, smaller allocations, requirement to use previous allocations before getting new IPs, etc.
<maswan> RIPE, ARIN etc can keep on delegating as long as they can get new /8s from IANA. Once that supply stops, ...
<Keybuk> plus they need to fix IPv6 first anyway
<maswan> the rirs already have, now just "all applications and equipment" needs to get fixed.
<Keybuk> and all ISPs need to spend a huge amount of money rewiring their networks ...
<Keybuk> ... in some cases replacing vasts amount of equipment
<Keybuk> before Canonical, I worked at an ISP.  We heavily looked into IPv6
<maswan> Yes, that's why you should start now, since you have an upgrade cycle still.
<Keybuk> and we worked out it would be cheaper to shut down the company than do the upgrade
<Keybuk> since the upgrade would put us out of business with the cost
<Keybuk> not only would we have required vast equipment upgrades over our entire national network
<maswan> Keybuk: Well, it'll be interesting to see how things turn out in a few years.
<Keybuk> but we would have had to change operating systems on large numbers of servers to have them on the network
<Keybuk> and would have had to completely re-engineer the network routeing, since that was based on IPv4
<Keybuk> (we provided a static IP or IP block to every customer, dial-up or DSL or leased line, so had our own routeing protocol)
<Keybuk> not to mention that BT didn't (and afaik, still don't) support IPv6 for DSL
<Keybuk> IPv6 fans have been predicting the imminent demise of IPv4 for as long as I can remember
<ion_> keybuk: The demise of IPv4 is always just five years away. :-)
<Keybuk> we'll all be using IPv6 on our Amigas <g>
<ion_> Right after the massive breakthrought of Linux on the desktop, and a bit before the release of Duke Nukem Forever.
<ion_> My Amiga has no problem with IPv6. :-)
<slomo> Mithrandir: please also give back gnome-sharp2 on amd64 and ppc for the same reason ;)
<maswan> Keybuk: As I said, it'll be interesting to see in a few years. If the ~2011 deadline still stands in 2 years from now, I suspect there will be quite a rush.
<Keybuk> tbh, the main problem with ipv6 in Ubuntu has been that those people who care about ipv6 are such fanatics about it, they're not interested in fixing the problems with ipv4 interoperability
<Keybuk> "turn off ipv4" is not a solution for 99.99% of our users
<ion_> IPv6 seems to work just fine in Ubuntu.
<Keybuk> it's actually deliberately slightly broken
<Keybuk> you won't get IPv6 DNS lookups unless you set a non-link-local IP
<smithj> i can't figure out where ubuntu creates /scripts/init-top/usplash in the initrd. it doesn't seem to exist on the real filesystem anywhere - does mkinitrd create it on the fly?
<maswan> Yeah. I hate that you have to workaroud broken hardware, but it is there. Bleh for home routers and firewalls and such crap.
<Keybuk> /usr/share/initramfs-tools/scripts/init-top/usplash
<maswan> At least it isn
<smithj> Keybuk: oh, thanks
<maswan> 't a "workaround" that breaks real setups
<TerminX> sudo is broken in gutsy?
<Keybuk> TerminX: not that I'm aware
<sladen> TerminX: is that a question, or something that you're finding?
<TerminX> oh, no, it's not sudo, it's pam in general :o
<Keybuk> maswan: "Could you read out your IP address for me?" ... "Sure, it's eff, eee, eighty colon co" ... "STOP! STOP! FOR GODS SAKE! STOP!"
<TerminX> wtf
<TerminX> I should just explain my experience today... I did an upgrade, and then samba started saying my password expired, so I changed it via smbpasswd
<TerminX> but it looks like smbpasswd changed my actual login password
<TerminX> seems wrong to me
<maswan> Keybuk: "192.168.1.2"
<TerminX> was something changed so that the smb password and the login password are unified?
<Keybuk> no idea
<Keybuk> did you read the changelog?
<TerminX> Keybuk: for which package? :p
<Keybuk> TerminX: any of them?
<Keybuk> this is a developer channel, not a support channel
<Keybuk> so I assume you're preparing a fix?
<Keybuk> otherwise you may find someone on #ubuntu is able to help you better than we can
<TerminX> no, I'm asking questions about development changes
<TerminX> not preparing a fix, not asking for support
<Keybuk> that's support
<Keybuk> (seriously, unless the one person who's touched samba is here and awake, there is little chance of getting a useful answer from us)
* ajmitch is here & awake, and to my knowledge, nothing changed in samba that would do that
<Keybuk> anyhoo, bed time
<Keybuk> nite all
<TerminX> ajmitch: did anything change that would prevent accessing your home directory via \\machine\username?
<ajmitch> it's been disabled from the default smb.conf for quite awhile now
<TerminX> I don't use the default smb.conf... it looks like the behavior is outright broken with the new version of the packages regardless of your conf
<TerminX> I downgraded to 3.0.24-6ubuntu1 from 3.0.25-1ubuntu1 and the issues went away
<ajmitch> I know of one potential problem that is being fixed upstream, and 3.0.25a should be out this week
#ubuntu-devel 2007-05-22
<BenC> anyone else getting double mouse-click events with latest gutsy?
<otavio> Is Tollef online?
<Hobbsee> otavio: likely asleep - but my Mithrandir 
<mjg59> Hobbsee: Your Mithrandir?
<Hobbsee> er, s/my/by/
* Hobbsee cant spell this early in the morning
<otavio> Hobbsee: thanks a lot. I'll send him a privmsg ... thank you
<otavio> mjg59: hey. :-D
<otavio> mjg59: how are you doing? :-)
<Hobbsee> mjg59: i should really be more careful with what i type, yes..
<calc> doko: hi :)
<Hobbsee> hiya calc 
<calc> Hobbsee: hi
<jcole> is there a hack around the "javascript menus behind flash" bug yet?
<jcole> for example, try to use the adobe menus -> http://www.adobe.com/
<StevenK> Mithrandir: Can you give-back espeak on amd64 and powerpc? Thanks.
<holycow> hey guys
<holycow> where can i find out information on intel wireless drivers?
<holycow> i was under the impression that they were open sourced but i keep on reading that they are binary and closed source
<Burgundavia> holycow: they require binary firmware
<holycow> in the u.s. i think they haveto be closed source by law but just curious in general about intel particapation in the community
<holycow> hey Burgundavia 
<Burgundavia> intel is busy rewriting their driver right now
<Burgundavia> new driver is called iwl, I think
<holycow> the goal is to provide open source drivers with a firmware blob perhpas?
<holycow> if that can be considered open source
<Burgundavia> that is already there
<holycow> aha! okay a bit clearer now
<Burgundavia> http://kerneltrap.org/node/7704
<holycow> oh! *bookmark*
<holycow> thanks for the linkage Burgundavia, thats great
<fabbione> morning
<Mithrandir> StevenK: given-back
<Mithrandir> slomo: given-back
<StevenK> Mithrandir: Thanks!
* StevenK chuckles at crested.
<StevenK> Current default timezone: 'Africa/Abidjan'
<ajmitch> ah, forums users
<ajmitch> has anyone else seen issues upgrading tzdata? it worked just fine for me when I updated the merge
<crimsun> fine here, too.
<ajmitch> I guess I can start to care iff people file bugs
* LongPointyStick pokes Mithrandir 
<Mithrandir> ouch
* Mithrandir orders odin to fetch the LongPointyStick 
<slomo> Mithrandir: thanks :) btw, the last mono upload will probably make you happy... it will free a few mb on the live cds
<Mithrandir> slomo: nice
<ajmitch> slomo: useful, what did you drop?
<slomo> ajmitch: nothing, all the .mdb debug files are in another package now
<ajmitch> ok
<Mithrandir> LongPointyStick: in general, there's no point in filing bugs about removal of binary packages no longer built; we catch those automatically.
<Mithrandir> or, semi-automatically, anyway.
<LongPointyStick> Mithrandir: he'd have to go a long way...
<LongPointyStick> and be a god swimmer
<LongPointyStick> Mithrandir: ah, gotcha
<LongPointyStick> s/god/good/
<Mithrandir> hmm, ENOTENOUGHFOOD.
* Mithrandir goes to fetch more
<slomo> fabbione: could you take a look at mono on sparc? might be necessary to disable the sigaltstack stuff on sparc or there might be an easy fix ;) http://librarian.launchpad.net/7732341/buildlog_ubuntu-gutsy-sparc.mono_1.2.4-0ubuntu2_FAILEDTOBUILD.txt.gz
<LongPointyStick> no food for you!
<fabbione> slomo: fix mono
<fabbione> slomo: i can't believe mono breaks on sparc on each and every single upload
<slomo> fabbione: it's simply not supported upstream... they only care about solaris/sparc
<persia> Mithrandir: Does the automatic catch for no longer built binaries include universe now?
<fabbione> slomo: make them care
<Mithrandir> persia: yes, it's always done so.
<fabbione> slomo: there are at least 3 distros that have sparc stuff... ubuntu, aurora (FC) and gentoo
<fabbione> slomo: i don't see why they can't consider it as part of their normal work at least not to break it
* LongPointyStick goes off to fnid some petrol
<persia> Mithrandir: Always?  I don't understand my experience with bug #32460 then.  Is it architecture specific?
<ubotu> Launchpad bug 32460 in supercollider "Please remove stale AMD64 supercollider binaries." [Medium,Fix released]  https://launchpad.net/bugs/32460
<Mithrandir> persia: there, a package stopped building for a particular arch.  That's different.
<persia> Mithrandir: I understand now.  Thanks for the explanation.
<slomo> fabbione: let me try something... and maybe i'll talk to them later about linux/sparc but i can already tell you that they will just tell me that it is not supported *shrug*
<slomo> fabbione: /*  * Can't use sigaction on sparc/linux, since it doesn't support SA_SIGINFO. Instead, we * have to use the obsolete sigcontext parameter: * http://www.ussg.iu.edu/hypermail/linux/kernel/0110.3/1531.html. */
<slomo> fabbione: that's the reason why it fails
<slomo> is this still valid today?
<fabbione> arch/sparc/kernel/signal.c:             if (ka->sa.sa_flags & SA_SIGINFO)
<fabbione> arch/sparc64/kernel/signal.c:                  (ka->sa.sa_flags & SA_SIGINFO) ? info : NULL);
<fabbione> arch/sparc64/kernel/signal32.c:         if (ka->sa.sa_flags & SA_SIGINFO)
<fabbione> same kind of catch all over the other arches, so i assume it is supported
<fabbione> and that mail is from 2001
<fabbione> 6 years ago
<slomo> fabbione: ok, i'll try another thing then...
<pygi> hi folks
<doko> Mithrandir: it appears that packages with versions like '-1build1' are not synced anymore (doxygen)
<Mithrandir> doko: current in gutsy is 1.5.2-2, same as unstable.
<StevenK> It FTBFS on i386.
<Mithrandir> well, that's hardly a sync problem. :-P
<doko> hrm, didn't see any sync email
<StevenK> Indeed, but it may explain why doko couldn't see it.
<StevenK> It failed to build due to LaTeX fun.
<Mithrandir> why would you see any?  It probably got caught by the automatic syncer.
<jack_deltrino> How do I do what dpkg-scanpackages . /dev/null | gzip -9 > Packages.gz does with apt-ftparchive?
<StevenK> Note to self. A package will probably build if I take the conflict markers *out* of configure.
<jack_deltrino> Hehe.
<dholbach> good morning
<TheMuso> dholbach: Morning.
<dholbach> hey TheMuso
<TheMuso> dholbach: Mind if I take the gnome-speech merge?
<dholbach> TheMuso: not at all
<dholbach> thank you
<TheMuso> dholbach: Looks like its going to temporarily break some stuff relying on it however.
<TheMuso> dholbach: Which I'm willing to fix.
<TheMuso> Due to soname change.
<dholbach> ok, if you need any help, let me know
<TheMuso> dholbach: Thanks.
<dholbach> oh ok - you take care of adding a new binary package and all that?
<TheMuso> Well that change was made in Debian.
<TheMuso> Now libgnome-speech7
<TheMuso> So the changes are a lot smaller, mainly only build/dependency differences.
<dholbach> ok
<pitti> Good morning
<Fujitsu> Hi pitti.
* Keybuk tries to work out what lvm-common is actually *for*
<fabbione> Keybuk: whatever changes you do to udev/lvm/etc.. please keep in mind multipath-tools :P
<Hobbsee> hey all
<Keybuk> fabbione: how would that be affected?
<fabbione> Keybuk: multipath-tools uses some udev rules including dm-* stuff :)
<Keybuk> *nods*
<cjwatson> lvm-common was there when both lvm1 and lvm2 were in place to support clean upgrades. it's probably largely pointless now but it would be gratuitous merge pain in future to remove it
<Keybuk> there might need to be an improvement to your udev rules, but nothing more
<Keybuk> cjwatson: the problem is there are bugs that seem to go away if you remove it
<fabbione> Keybuk: i am all up for improvements... 
<cjwatson> what, like "lvm is present"?
<cjwatson> lvm2 Depends: lvm-common
<Keybuk> cjwatson: lol
<Keybuk> cjwatson: the init script seems to break several setups working with our lvm-from-udev approach
<cjwatson> ah, so that's more "nuke lvm-common's init script" than "remove lvm-common"
<dholbach> does anybody know what is causing bug 114509?
<ubotu> Launchpad bug 114509 in udev "linux-image-2.6.22-1-generic + udevd = breakage" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114509
<Keybuk> yeah, but there's nothing else *in* lvm-common, other than a cron script :p
<cjwatson> it provides stuff like lvmiopversion
<Keybuk> I can't find anywhere else that's used other than in its own init script
<fabbione> iirc it's used in the installer too
<tepsipakki> a quick gallup: do we want the split & reorganized xbase-clients/xutils to also Conflict with our current xfoo-packages? That would force removing those on upgrade instead of just replacing
<Keybuk> dholbach: yes, I saw that lots and lots and lots yesterday
<Keybuk> it has nothing to do with udev
<Keybuk> it's a kernel change to the behaviour of devicemapper
<cjwatson> fabbione: it is not
<fabbione> cjwatson: ok cool
* Hobbsee ponders which part of kde to update next.
<Fujitsu> Hobbsee: GNOME.
<tepsipakki> hmm, no opinions? I'll add the Conflicts, then
<Hobbsee> Fujitsu: ewww.  no
<pitti> hi Hobbsee 
<Hobbsee> heya pitti!
* Hobbsee ponders the wisdom of copying very large files over wifi...
<pitti> Hobbsee: curious, why is that a problem?
<Hobbsee> pitti: just slow
<Hobbsee> pitti: although i think the link to au is where the slowness is
<pitti> Hobbsee: ah, ok; heh, I'm used to it, being on WiFi all my time :-/
<Hobbsee> ahh
* pitti wonders whether he is the only one for whom jabber is broken since we switched to pidgin
<seb128> pitti: yes
<seb128> pitti: works for me on my laptop and desktop and we got no bug about it afaik
<persia> pitti: Works for me.
<pitti> hm, thanks
<seb128> pitti: what error do you get?
<seb128> try pidgin -d on a command line
<pitti> seb128: it just doesn't want to connect
<seb128> might lack some nss depends or something
<pitti> oh, now it's actually connected, but i don't see any users
<pitti> I cannot belive that suddenly all jabber contacts have been offline for a week
<seb128> what is your jabber ID?
<pitti> ah, it just disconnected again
<pitti> it usually says 'XML is not well-formed'
<pitti> seb128: pitti@jabber.org
<seb128> hum
<seb128> maybe try the -d run to see if there is anything useful there
<Chipzz> tepsipakki: btw, either of xserver-xorg or xserver-xorg-core depends on xbase-clients, so having it split up (as much as I like it split up) currently has little value until that dependency is removed :S
<tepsipakki> Chipzz: yep, known
<tepsipakki> xorg needs to be changed as well
<tepsipakki> I just did an upgrade and it went well
<pitti> seb128: same: jabber: Recv (ssl)(111): <stream:error><xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>
<pitti> account: Disconnecting account 0x746cd0
<Chipzz> currently still on feisty
<tepsipakki> Chipzz: well, these are not even in gutsy yet ;)
<Chipzz> and the -intel driver is broken in gutsy last I heard, so not upgrading just yet ;)
<tepsipakki> broken how?
<Chipzz> not working, but that was last week; may be fixed now
<Chipzz> (the -intel driver in universe btw)
<pochu> Chipzz: because the 1.3 xserver, you have to upgrade to -intel 2.0
<pochu> Though yesterday night it wasn't in the archives yet, I downloaded from LP :)
<tepsipakki> 2.0.0 was uploaded yesterday..
<Fujitsu> Does our xserver do randr 1.2 nowadays?
<Keybuk> we have xserver 1.3, yes
<pitti> seb128: apparently pidgin's data dir is ~/.purple? I'll try moving this away and reconfigure my accounts
<seb128> pitti: weird error, open a bug on launchpad, upstream read them (though they reply on some only)
<seb128> pitti: yes
<pitti> seb128: thanks, will do that after I digged some more
<jmg_> dug ;)
<pitti> jmg_: noted, thanks ;)
<tepsipakki> xrandr the tool is old
<tepsipakki> but when the split packaging is in experimental we can sync them
<pitti> Mithrandir: can you please give-back libtunepimp? (dpatch breakage yesterday)
<StevenK> Woot. My ShipIt order arrived today.
<cjwatson> pitti: I'm thinking of starting to build the graphical installer (partly for giggles, partly because we've got the hardest of the dependencies available now and so it doesn't cost much, partly because it makes the d-i merge a good deal simpler)
<cjwatson> pitti: but it does need a few extra bits in main
<cjwatson> this is the alternate installer with the graphical frontend, as in Debian. I'm not wild about its UI, but a number of people seem interested in at least trying it
<pitti> cjwatson: you mean for lvm/cryptsetup support?
<pitti> ah, I see
<pitti> cjwatson: the return of the gtk framebuffer stuff? :)
<pitti> I tried it a few days ago, and while I don't see a major advantage of it, it certainly looks a bit friendlier
<cjwatson> specifically, it needs rootskel-gtk, ttf-farsiweb, ttf-cjk-compact, ttf-tmuni, and ttf-khmeros source promotions, cdebconf-gtk-udeb binary promotion, and various binary font promotions
<cjwatson> I don't really propose to have it be the default on the alternate CD; I think it's still too clunky
* pitti hopes that the ttf-* won't take too much space
<cjwatson> I wasn't even proposing to have them on the alternate CD ;-)
<cjwatson> it can be netboot only for the people who want to try it
<pitti> ah, that sounds fine
<cjwatson> but I wanted to see what you thought; I can still disable it again if you (or others) would prefer
<pitti> ttf-* sounds harmless, binary promotions as well (I still need to look at bugs etc.), I don't know about rootskel-gtk
<cjwatson> pitti: I can make ttf-* optional, though rootskel-gtk and cdebconf-gtk-udeb would be required to make it work
<pitti> grrr, the apport retraces go out as "Martin Pitt" *again*; I already fixed the cookie twice
<pitti> seems Launchpad now keeps the cookie value and just updates the name if I log out as apport and back in as pitti
<Hobbsee> pitti: yes, i was going to whine about that
<pitti> indeed, it does that *tsk*
<slomo> fabbione: ok, i give up... i'll just disable that for now until someone with access to a sparc machine fixes it
<slomo> fabbione: http://bugzilla.ximian.com/show_bug.cgi?id=81702 if you're interested...
<fabbione> slomo: you could also try to contact David Miller as mono/packager/upstream
<ubotu> Ximian bug 81702 in generics "[Linux/sparc]  Fails to build with --with-sigaltstack=yes" [Unknown,New]  
<fabbione> slomo: because when you come to me with mono stuff, i just bounce it to him
<fabbione> and it's really no point for me to proxy all the requests
<jovans> ist there a security bugfix for  the FreeType-Bibliothek on feisty availib.
<slomo> fabbione: later
<shawarma> slomo: You know you have access to a sparc machine, right?
<dholbach> where can I find out about the reason why a package's source has been removed from Ubuntu (if there's no bug filed for the removal)?
<pitti> jovans: what do you mean any details?
<pitti> dholbach: there's a log for it, a minute
<pitti> dholbach: http://people.ubuntu.com/~ubuntu-archive/removals.txt
<dholbach> thanks a lot, pitti!
<jovans> http://lists.gnu.org/archive/html/freetype-devel/2007-04/msg00041.html
<jovans> http://cvs.savannah.nongnu.org/viewvc/freetype2/src/truetype/ttgload.c?root=freetype&r1=1.177&r2=1.178
<jovans> so i am going bye
<illovae> hello
<slomo> shawarma: no i wasn't aware of that ;)
<pitti> keescook: jovan's message above ^, that's CVE-2007-2754; I guess it's on your radar then?
<shawarma> slomo: ssh slomo@sparky.ubuntuwire.com
<shawarma> slomo: Have fun! :)
<slomo> shawarma: thanks :)
<shawarma> slomo: np
<shawarma> slomo: Thank imbrandon, by the way. I'm just the messenger.
* shawarma hurries off
* mvo_ stares at the kdebluetooth merge mess
<StevenK> I'm doing the same at pycairo. The patch on patches.u.c is just under half a meg.
<Hobbsee> mvo_: dont bother.  kde 3.5.7?
<seb128> mvo_: what else do you expect from something starting with kde? ;)
<StevenK> Muahaha
* Hobbsee beats seb128.  they seem OK so far
<seb128> heh
<seb128> StevenK: yeah, those python-dbg changes are no fun
<pitti> Hobbsee: if you kick seb, I won't look for the next two minutes :)
<StevenK> Bwahaha
<Hobbsee> haha
<Riddell> Hobbsee: kdebluetooth isn't in kde mainline
<mvo_> Hobbsee: no, just regular debian merge
<Hobbsee> ahh
* seb128 stares at pitti
<Riddell> mvo_: what's up?
* mvo_ wonders why he touched that package in the first place
<mvo_> Riddell: nothing special, its just *huge* and the delta seems to be 99% cruft
<StevenK> seb128: Tell me about it. This merge also includes such fun as editing m4 macros for autoconf and re-running autoconf.
<mvo_> Riddell: you want to have it ;) 
<pitti> seb128: oh, just for the KDE bashing; nevermind
* pitti hugs seb128
<Riddell> mvo_: if you leave it then I'll get to it eventually, or another kubuntu type will
<seb128> pitti: yeah, I got it, I was just expecting from security to step and protect me from those KDE guys instead of looking somewhere else ;)
<Riddell> although at the moment there's about three kde releases to take care of
<mvo_> Riddell: ok, I take a closer look then
<StevenK> Riddell: 3.5.6, 3.5.7 and 3.80?
* seb128 hugs pitti
<imbrandon> StevenK, 3.80.x :)
<Riddell> StevenK: 3.5.7, 3.90.1 and koffice something
<StevenK> Fun.
<allee> mvo, Riddell, Hobbsee: I've a pkg of kdebluetooth-dbus-integration ready.  I've pinged dgollub about some bugs that need fixing.
<pitti> tepsipakki: hm, I'm TIL for xserver-xorg-video-voodoo; do you happen to know whether we still need the debian/ modifications?
<pitti> tepsipakki: oh, we still need the Conflicts/Replaces: xserver-xorg-driver-voodoo until the next LTS, so no sync; I can merge this unless you want to?
<Riddell> allee: great, actually tonio's a better dude for kdebluetooth than me
<allee> Riddell: your on the list just because you mentioned kdebluetooth too  :)
<pitti> tepsipakki: ah, nice, that's even in Debian
<allee> mvo_: relax.  I take care of kdebluetooth
<Riddell> allee: do you remember if we had a spec registered for bluetooth in kubuntu?
<Riddell> I can't see it now
<allee> Riddell: tonio wanted to write it.  I've seen him working on it last day at UDS
<imbrandon> Riddell, i think i rember seeing one, but i cant be sure
<StevenK> Mithrandir: Can you look at/voluntell someone to poke at the ia64 buildds. Both of the AUTO are showing as IDLE, and builds are piling up.
<pitti> doko, Mithrandir: does any of you feel a particular urge to merge ia32-libs? if not, I'll see to that now
<pitti> doko, Mithrandir: we only need it as a build dep of mbr now, so I'm not too afraid of breaking the world
* Keybuk didn't know pitti was into sado-masochism
* mvo -> lunch
<\sh> pitti, please leave it functional, so I can try to build wine32 on x86_64 ;)
<pitti> well, I didn't propose to upload something untested :)
<doko> pitti: an update should be enough, never merged that. maybe have a look, which additional packages debian includes
<pitti> I just meant that we don't need it any more for OO.o, so I'll test-build mbr and check it with vmware
<pitti> doko: we also need to drop some binary packages
<pitti> doko: and debian has quite a lot of fixes and updates, too, and we didn't merge any more since breezy
<pitti> Keybuk: it's not yet enough for OO.o ;)
<Keybuk> talking of S&M ... time to merge lvm2
<Hobbsee> you poor people
<StevenK> Hobbsee: Yes. Look what you have to look forward to - main merges.
<StevenK> Oh, wait.
<Keybuk> heh
<Keybuk> so, you know how earlier, I was trying to work out what lvm-common actually did
<Keybuk> turns out it's obsoleted by the new Debian lvm2
<Lure> Riddell: https://blueprints.launchpad.net/ubuntu/+spec/kubuntu-bluetooth
<Hobbsee> heh
<Company> asac: i have some comments about "easy codec install" in FreeFlash - should i bloat the wiki or do you wanna discuss it here?
<asac> Company: if your comments are well thought ... add it to wiki ... if you want to discuss it first ... lets discuss :)
<asac> improvements always welcome
<Company> asac: i think hooking into a playing flash file for the easy codec stuff is a bad idea
<Company> asac: 1) it's not as simple as in the wiki, since sound can be in lots of places
<Company> asac: 2) flash files are expected to be self-contained and it would break that model
<Company> asac: since it is well known which codecs are needed, why don't you do codec-install them upon package install or first start of the flash player?
<asac> Company: looking at gnash code it appears that flash actually gives up if the codec isn't found.
<asac> which is the place where to hook in codec install 
<Company> "gives up" as in stops playback?
* Company hasn't looked at gnash
<asac> imo doesn't matter ... the codec install will be asynchronous ... so even it it goes ahead ... it doesn't matter
<asac> Company: its just not there for the current flash movie ... next one will discover it ... or maybe after restart
<Company> hrm yeah, that's weird
<asac> Company: my solution looks pretty easy to realize ... tricky things are in "outstanding issues"
<Company> i'd prefer if it happened upon install or when instantiating the flash plugin the first time
<asac> actually i would like to find a way to start easy codec install for swfdec as well
<asac> so we have the option to switch
<Company> yeah, that's where i'm coming from ;)
<asac> i know :)
<Company> asac: you wouldn't catch the mp3 playback (or other audio codecs) with hooking into netstream
<asac> Company: in a perfect world we could hook in the easy code install to the gui code
<pitti> erk, ia32-libs merge is an utter mess
<Company> i would hook (in swfdec) the easy codec stuff into the mozilla plugin and upon plugin_init or plugin_new_instance do the check for the required formats
<Company> unless it's possible to do as a package post-install hook
<Company> in which case i'd run it there
<Company> but i'm not a packager, so no clue about that possibility
<Company> the difference between ie totem and flash is that totem plays anything, while flash needs 3 formats, so it doesn't make a lot of sense to defer installing codecs until later (imo)
<asac> Company: how should mozill introspect flash movies to see a missing codec?
<asac> i don't think that is feasible
<Company> mozilla shouldn't
<Company> the plugin should
<Company> swfdec's or gnash's moz plugin
<Company> just check if the 3 required codecs exist and if not, launch codec install
<asac> point is you cannot touch mozilla plugin code without risking severe breakage all over the universe :)
<asac> Company: its important for us that codecs that are not shipped in main get installed lazily
<asac> e.g. just if you need them
<fabbione> or make a big fat plugin wrapper
<fabbione> but that's like adding a can of worms
<Company> i don't want to touch moz code at all
<Company> i want to touch swfdec-mozilla code
<asac> ah ok
<Company> or make you do it :p
<asac> now i get your point
<asac> gnash has a standalone player as well
<asac> i want it to work for that one as well
<asac> swfdec might have a standalone player at some point ... right?
<Company> right
<Company> in gnash you could hook into the standalone player
<asac> ... so adding that to mozilla plugin code is not really a solution
<Company> since the plugin just launches that one using XEmbed
<pitti> doko: does ia64 now have a native oo.o, or do we still need the lib32z1/lib32stdc++6 packages from ia32-libs on ia64?
<Company> if you want the xid you'll have to do it anyway
<Company> since swfdec doesn't know about X
<asac> but gtk knows :) ... at least conditionally
<Company> right
<Company> but swfdec soesn't know about gtk either :p
<asac> so where do you get the window you draw upon from?
<Company> swfdec uses cairo
<Company> so the apps create a cairo context and pass that one to swfdec
<asac> ok ... i see ... for swfdec we might need to add that plugin install to wrapping application (e.g. mozilla-plugin + maybe standalong player)
<asac> anyway ... we need some detailed feedback from swfdec api about missing codecs
<asac> same goes for gnash of course ... which is the outstanding issue: extend backend/server contract to notify UI about missing codecs
<Company> yeah, that's the other point
<Company> why can't you just check all required codecs no matter if you need them for the current flash files or not?
<asac> because we don't want to encourage people to install things that they don't need
<asac> especially if those things are not in main
<asac> or have patents etc.
<tepsipakki> pitti: yes, I should've mentioned that the changes are in debian now.. 
<tepsipakki> pitti: did you notice the others too?
<pitti> doko: oh, ia64 doesn't have any OO.o any more in the first place; so we dont' actually need to care any more
<Company> so you want to delay install until the last possible second?
<pitti> tepsipakki: I just synced it
<pitti> tepsipakki: 'the others'?
<asac> Company: right
<Company> hrm
<tepsipakki> pitti: in the bug, -mga, -suncg6, -via
<Company> it's not that it's hard to export functionality to detect missing plugins
<tepsipakki> oh, and discover-data
<pitti> tepsipakki: I just looked at the merge, and didn't see a sync request bug for -voodoo; I didn't look at any other bugs
<Keybuk> Will remove the following packages from gutsy:
<Keybuk> lvm-common | 1.5.20ubuntu4 | hppa
<Keybuk> lvm-common | 1.5.20ubuntu12 | amd64, ia64, powerpc
<Keybuk> lvm-common | 1.5.20ubuntu14 | source, i386, sparc
<asac> Company: you use gstreamer as well, right?
<Company> it's just that it's a lot of work and would probably look ugly
* Keybuk dances the "ding dong" song
<Company> asac: yes
<tepsipakki> pitti: ok :) bug 115963
<ubotu> Launchpad bug 115963 in Ubuntu "Please sync from Debian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115963
<asac> ok ... actually its just a notify signal
<asac> Company: what would be ugly about that?
<pitti> Keybuk: -m '(Keybuk) Those suck and we do not like them any more'  ?
<pitti> tepsipakki: ah, I see
<Keybuk> pitti: conflict/replace'd by lvm2
<Company> asac: getting the notify signal from inside swfdec out to the application runing it
<asac> yes ... might be an implementation issue ... but for the general swfdec api contract it won't do any harm
<doko> pitti: correct
<asac> even more so if you don't depend on swfdec users to actually deal with that notification
<Company> swfdec doesn't expose the multimedia codes in its api
<pitti> doko: thanks; this will make the delta much smaller
<Company> they're buried very well deep inside the code :)
<fabbione> Keybuk: so i can sign with blood my machines won't boot anymore? :)
<asac> Company: right ... its just a codec name afaik
<tepsipakki> pitti: sorry, I thought you were doing archive-admin duties :)
<pitti> tepsipakki: no, just reviewing my merges; my archive day is Friday
<asac> e.g. like an error detail 
<Company> and you want to stop playback of the flash file until the codec installation is done
<Keybuk> fabbione: you mean they booted now? :p
<Company> and then continue with the codec
<fabbione> Keybuk: well sometimes...
<Company> which is something that the app would need to know about
<asac> Company: would be nice to restart after codece install is finished ... but its not necessary to stop it ... as its not getting worth then before i guess :)
<asac> Company: yes ... the app should deal with that ... we agree
<Company> would be weird if you get sound but no video
<asac> but its the case atm, right?
<asac> anyway ... app can do everything ... e.g. stop
<asac> continue
<Company> yes
<asac> its not in the realm of lib to decide that
<asac> just allow app to deal with that by singaling a missing codec
<Company> yeah, i'd somehow need to get that info out there
<asac> Company: if we can find a way to do that, we can do the app/plugin stuff after that.
<asac> ... which is actually the thing i want to do with gnash as well :) ... but i am not sure if gnash devs will understand me :)
<Company> i still think doing a dialog like "You just installed Flash. Flash might need proprietary codecs. [Install now]  [Ignore] " on first run would be better
<Company> in particular for my api ;)
<Company> anyway, i'll think about it some more
<Company> gtg now
<asac> yes ... but thats not the vision
<asac> Company: just provide info what codec is missing
<asac> :)
<asac> for now
<asac> that is a good base to everything we want.
<asac> ok ... me lunch
<slomo> hm, what happened to the ia64 buildds? they're all idle although stuff needs building
<Mithrandir> slomo: we're already investigating
<slomo> ok
* mvo grumbles about cryptsetup/luksformat not working on his three machines
<glatzor_> mvo: what  is zour problem? I have got several machines with luksformat
<mvo> glatzor_: luksformat /dev/sdb1 does not work for me
<mvo> strace says it tries to access something in /dev/mapper/temp-crypsetup etc  - then it times out and it stops
<glatzor_> mvo: you could try if loading the aes and sha256 modules helps
<glatzor_> your command was: cryptsetup luksFormat /dev/sdb1 
<mvo> glatzor_: tries that without success on a stock feisty system
<mvo> glatzor_: joy! if I luksformat the beast on a different system (e.g. a debian one) then mounting works fine. just creating the thing in the first place is broken it seems
<glatzor_> mvo: I haven't formatted any new disk using Ubuntu for some time.
<glatzor_> mvo: oh, I just figured out that mounting is also broken in GNOME :)
<glatzor_> mvo: oh, I just figured out that mounting is also broken in GNOME :)
<mvo> works for me
<mvo> (fiesty)
<glatzor_> perhaps I should use a smaller key
<glatzor_> and try again
<glatzor_> oh my god, the first after my move to the new flat, that I drive to recycling park.
<Keybuk> Seveas: ping?
<Seveas> Keybuk, pong
<Hobbsee> Keybuk: he went mad, so we shot him.
<Keybuk> ah, excellent
<Hobbsee> i dont htink he had any objections
<Keybuk> mathiaz: welcome ;)
<cypherbios> mvo: have you had a change to take a look over this bug https://bugs.launchpad.net/ubuntu/+source/apt/+bug/115536 ?
<ubotu> Launchpad bug 115536 in synaptic "apt-cdrom add fails to mount the medium" [Undecided,Unconfirmed]  
<mvo> cypherbios: checking
<cypherbios> mvo: apt tries to mount /cdrom/, but in ubuntu's default fstab the mounting point is /cdrom (without the slash) then I got the error
<cypherbios> mvo: if I manually change the fstab adding the slash, everything works fine
<mvo> cypherbios: I anwer in the bugreport. I haven't reproduced it yet, but I can give you a workaround
<pitti> \sh: btw, the current Debian package talks about 'wine symlinks'
<pitti> \sh: do you happen to know how they need to look like? and where?
<pitti> \sh: Debian package creates SONAME-less symlinks in /emul/ia32-linux/usr/lib
<vijay2000> hi all
<vijay2000> i am new to this community
<vijay2000> i need somebody to mentor me
<vijay2000> i want to get involved in ubuntu community activities
<Keybuk> vijay2000: welcome; the best way into the ubuntu development community is through the Masters Of The Universe team -- on #ubuntu-motu
<pitti> vijay2000: depends on what you actually want to do; if you want to help out with software development, then as Keybuk says
<vijay2000> keybuk: i have posted request to MOTU. i am yet to get a reply
<cypherbios> mvo: yes, If I use apt-cdrom add --cdrom /cdrom/ or --no-mount it works well but will not automount the media (which is the cool thing of apt-cdrom)
<vijay2000> i feel i can also do documentation
<vijay2000> i would like to know wat will b the next step after getting a mentor
<mvo> cypherbios: if you tell me what you need exactly, I'm pretty sure I can help you. synaptic has all the stuff in place to add a cdrom with graphical progress etc 
<mvo> cypherbios: and you can give it a lot of options so that it will look into different mount points, not mount/umount etc
<mvo> cypherbios: check the bug, I added some notes there
<pitti> vijay2000: https://wiki.ubuntu.com/UbuntuDevelopment has detailled descriptions of the processes and starting points; do you know this already?
<cjwatson> I also referred vijay2000 to https://wiki.ubuntu.com/ContributeToUbuntu on another channel
<pitti> vijay2000: https://wiki.ubuntu.com/DocumentationTeam as well
<cjwatson> this answers his question above, so I guess he hasn't read it yet ..
<pitti> cjwatson: thanks for that link, will use it in the future
<vijay2000> i have read the links that are given by watson and pitti
<vijay2000> i have also joined the mailing list 
<Hobbsee> vijay2000: now pick something you're interested in, and work on it?
<vijay2000> i am interested in software development .. but my knowledge in C is not tat good .. i have been working on microsoft technologies all these years... can i still get into software development 
<vijay2000> i am good in the concepts though
<cjwatson> there are lots of pieces of software in Ubuntu written in languages other than C
<cjwatson> it really does depend on your own specific interests though; the best free software developers often start out by finding something that bothers them personally
<vijay2000> i wanted to get involved in developing software which can be used by people across geographies
<vijay2000> can i get involved in kernel development
<vijay2000> i am very much interested in it
<pitti> vijay2000: do you already have some experience with it?
<vijay2000> no i dont have experience in it
<vijay2000> i am a new bie to linux
<pitti> vijay2000: let's do this in /msg
<cypherbios> mvo: sorry, I was not clearly in the bug description: In a fresh install of Ubuntu in my notebook when I open Synaptic and select 'Add CDROM...' I get an error: 'E: Failed to mount the cdrom.' and nothing happens
<cypherbios> mvo: I think this happens because Synaptic (apt) tries to mount a mounting poing (/cdrom/) different on the fstab's one (/cdrom)
<\sh> pitti, don't bother about wine symlinks...the debian package for wine32 on x86_64 is more then evil...
<pitti> \sh: right, I just disabled them for now until we know what we need
<\sh> pitti, actually when we could provide an easy to use 32bit libs for 64bit archs for the need to be used wine libs (it's really evil, because we need to -m32 some xorg libs) that would be cool...but I'm not a fan of this hack of debian
<dholbach> so now that I got past the dm-*/evms hurdle with 2.6.22-5, my wireless does not work at all with my x40 - is anybody else having similar problems?
<mvo> dholbach: oh, how did you fix the dm-* fun? my amd64 does not boot  with the same messages
<dholbach> mvo: sudo dpkg -P evms{-ncurses,} "fixed" it for me
<mvo> dholbach: thanks, I will try that
<dholbach> anytime
* seb128 doesn't upgrade in the middle of the day so he gets some work done instead of having to fix his desktop installation ;)
<dholbach> seb128: booting the old kernel still worked
<seb128> dholbach: didn't upgrade that neither ;)
<dholbach> right
<seb128> my catching up with desktop bugs starts being good, I might upgrade later ;)
<seb128> 46 unread bug mails and it was over 400 one week ago
<coleb> Has anyone seen this error when doing a cvs login? cvs: ldap-nss.c:1374: do_init: Assertion `cfg->ldc_uris[__session.ls_current_uri]  != ((void *)0)' failed.
<Riddell> pitti: was it apport that has code to test for the current desktop?  (KDE/gnome etc)?
<pitti> Riddell: /usr/bin/ubuntu-bug
<Riddell> thanks
<pitti> mjg59: do you have time to merge laptop-mode-tools?
<ssam> i am not sure if there is anything that can or should be done, but there is talk on the internet of a worm targeting openoffice http://www.sophos.com/virusinfo/analyses/sbbadbunnya.html
<ssam> i can't see any information about whether it is exploiting an oo bug, or just doing standard macro stuff
<cjwatson> mvo: has there been a discussion about the URI syntax proposed in https://wiki.ubuntu.com/AptFirefoxFileHandler? I have some comments
<mvo> cjwatson: only a discussion in the BOF. I'm very happy about feedback for the syntax
<cjwatson> mvo: firstly, it seems that for a single package (even with options) the syntax ought to be non-hierarchical, so apt:unrar rather than apt://unrar
<tkamppeter> pitti, Mithrandir, I have now made available a merged Ghostscript where http://bugs.ghostscript.com/show_bug.cgi?id=689237 is worked around, so it has no regression against gs-gpl-8.56.
<ubotu> bugs.ghostscript.com bug 689237 in PDF Interpreter "gv, kghostview, and pdf2ps hang with GPL GS 8.57 or newer, both trunk and gs-esp-gpl-merger" [Critical,New]  
<tkamppeter> I think this we can upload into Gutsy.
<mvo> cjwatson: that synatax was selected to stay compatible with guadalinex, they have deployed a similar system since some time already
<pitti> tkamppeter: yay
<pitti> tkamppeter: are there any remaining differences to Debian now?
<pitti> tkamppeter: i. e. what will go into Debian, not what's in it currently
<cjwatson> mvo: secondly, the deb%20http://blah syntax is very obscure; could I suggest simply apt+http://blah instead? there are other schemes that do that sort of thing (svn, bzr)
<tkamppeter> No, I have overtaken everything which the Debian maintainer suggested, so I think it will go into Debian the same way.
<cjwatson> mvo: I'm not sure that should be an overriding concern, since it isn't standardised
<keescook> pitti: CVE-2007-2754> yup, on the radar just behind the pending php and samba updates
<cjwatson> mvo: we could support apt://unrar but recommend apt:unrar
<tkamppeter> pitti, you are CCed on all my e-mails concerning this.
<pitti> tkamppeter: right, that looked promising
<cjwatson> mvo: I'm also not sure I see the use for apt://multiverse?add-component - shouldn't apt: use a temporary sources.list that overrides your usual configuration while installing from the browser?
<pitti> tkamppeter: I'll upload this in a bit and care for the removals of the other gs'es
<tkamppeter> Thanks, pitti.
<cjwatson> mvo: I think it would be a lot clearer if apt: URIs always caused a package to be installed, rather than mixing it up with sources.list maintenance
<mvo> cjwatson: the idea behind add-component and add-repository was that the repositories are added permanently - but I see the value in having it enabled only temporarely
<cjwatson> mvo: my suggestion would be something like apt+http://launchpad.net/~mvo/ppa/test:ppa-key:mvos-new-package
<mvo> cjwatson: hm, maybe not. the good thing about adding repositories permanently is that we can automatically ship updates this way
<cjwatson> though I'm not sure I entirely like that either - but it's better than %20 sprinkled through the URI
<cjwatson> mvo: I don't think we should conflate too much into this. URI syntax ought to be simple, not a fully-functional language
<cjwatson> a URI is supposed to describe a single accessible resource, not an arbitrary set of actions to be performed on your system
<mvo> cjwatson: the alternative to this would be a control file thing to add repositories. some mechanism for this would be good to have for PPAs
<cjwatson> as I said, I think we could ship apt: URIs that install packages from PPAs without having to add the repository permanently to sources.list
<mvo> cjwatson: that would mean that the user does not get automatic updates from it. if that is something we can life with, I'm fine with that
<cjwatson> but I do think adding repositories using the same syntax is a really bad idea - the UI ought to be quite different
<cjwatson> that's true - can I suggest using a different URI scheme then?
<mvo> cjwatson: sure
<cjwatson> apt-repository: or something if you want to do that
<cjwatson> the URI scheme as written just seems really easy to get wrong
<mvo> cjwatson: ok, that sounds good. this way the whole thing gets a lot easier/clearer
<cjwatson> actually, it would kind of make sense if it always pointed to a package, even if it added a repository along the way
<mvo> cjwatson: do you think we should still support apt+http:// handlers?
<mvo> cjwatson: which one should always point to a package? the apt-repository: link? or apt: link?
<pitti> tkamppeter: http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/gs-gpl/ still has the version from May 17th; this doesn't have the workaround you mentioned yet?
<cjwatson> how about apt+http://launchpad.net/~mvo/ppa/test/?mvos-new-package ?
<cjwatson> and have a db in /usr/share/app-install/ that can map the pre-? portion of that to a key
<cjwatson> that fits the generic URI syntax
<bddebian> Heya
<cjwatson> or apt+http://launchpad.net/~mvo/ppa/test/?component=multiverse?package=mvos-new-package
<mvo> cjwatson: I like the later better
<cjwatson> with that sort of thing you could also embed versioning if need be
<cjwatson> and the UI can notice if the repository isn't in sources.list and ask you whether you want to add it permanently in order to get updates, or just use it for this one install, or cancel
<cjwatson> does that sound good?
<mvo> cjwatson: yes, that sound pretty good. this waywe eliminate the need for a second protokol type as well
<cjwatson> I'm not sure how to do multiple packages; it doesn't really seem idiomatic for URIs to point to multiple resources
<cjwatson> but I wonder whether that is necessary - if it's very common to install multiple packages at once, one can always build a metapackage
<mvo> cjwatson: we could allow packages=one,two,three or simply multiple package= statements
<cjwatson> sorry, I know I'm coming in late and kind of blowing the spec out of the water :-/
<cjwatson> I only just saw it due to a reference from elsewhere
<mvo> cjwatson: that fine. I'm happy as long as it makes the spec better
<cjwatson> I'm guessing it should be no more difficult to make firefox support apt+http and apt+ftp as well as apt
<mvo> cjwatson: I haven't looked at the bits required in ff yet, but I suspect it would not
<mvo> cjwatson: how about I merge our discussion and your suggestions into the spec tomorrow morning and you have a additional look at this then?
<cjwatson> that leaves the question of what apt: alone should do - presumably apt:foobar?minversion=1.0 is a shorthand for ?package=foobar?minversion=1.0 and can only be used for packages in the standard Ubuntu repositories
<cjwatson> mvo: sure, sounds good, thanks
<mvo> cjwatson: exaclty
<ion_> Looks like a nice URI scheme.
<pitti> I cannot believe it -- echo -e is broken
<pitti> doko: it seems that bash's internal echo now doesn't evaluate escapes correctly any more: echo -ne '\007' works, but echo -ne '\125' doesn't
<pitti> doko: it does work with /bin/echo
<pitti> doko: and it works with etch's bash (3.1dfsg-8)
<ion_> pitti: printf ftw. :-)
<pitti> ion_: yes, that's what I am using as a workaround
<pitti> ion_: but it means another delta to Debian
<pitti> doko: I filed this as bug 116226
<ubotu> Launchpad bug 116226 in bash "echo does not handle escapes any more" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116226
<cjwatson> pitti: 'help echo' says:
<cjwatson>         \0nnn   the character whose ASCII code is NNN (octal).  NNN can be
<cjwatson>                 0 to 3 octal digits
<cjwatson> pitti: I think you need to make it begin with 0 (\0125). This is consistent with C
<pitti> cjwatson: hm, that would be four digits then, and it's inconsistent with what /bin/echo and printf do
<cjwatson> I note that etch's 'help echo' says:
<cjwatson>         \num    the character whose ASCII code is NUM (octal).
<cjwatson> pitti: the NNN part is three digits
<pitti> ah, right
<cjwatson> c.  The `echo' builtin now accepts \0xxx (zero to three octal digits following the `0') in addition to \xxx (one to three octal digits) for SUSv3/XPG6/ POSIX.1-2001 compliance.
<pitti> well, ok, it's an Ubuntu delta in either case, so it doesn't actually matter much
<cjwatson> upstream change in bash 2.05b-beta1
<pitti> cjwatson: \125 still works in bash 3.1 (etch and edgy)
<pitti> apparently they now dropped the old behaviour
<cjwatson> mm, I don't see that in CHANGES
<cjwatson> probably worth chucking at upstream
<cjwatson> mvo: one other query I have is whether minversion (or >= or whatever) is necessary - it only seems useful for dependencies, in which case you can just put it in a Depends: line
<cjwatson> (we don't support 'apt-get install foo (>= 1.0)', after all, although once in a blue moon I find a use for that in the installer)
<cjwatson> mvo: also dependencies between PPAs are probably worth considering - maybe ?extrarepository=http://blah ?
<cjwatson> though I realise that risks building back up to the complexity of the original :)
<mvo> cjwatson: good point. the use-case I had in mind was something like "the new gaim support the $foo protocol. install it now: apt://gamin?minversion=$version-that-supports-foo". but it should be fine to leave it for later
<cjwatson> interesting
<cjwatson> I see what you mean - maybe mention that in the spec?
<mvo> cjwatson: interdependencies between repositories is something I would like to keep away from for now. the good thing about the uri-schema is that it is easily extensable. lets see how people use the PPAs. I wonder how many will "stack" them in a way that we need this feature
<mvo> cjwatson: ok
<cjwatson> mvo: *nod*
<cjwatson> I sort of assumed that was why you had the sequence-of-commands thing in that design
<cjwatson> and of course you can always just have multiple links in the documentation ..
<cjwatson> I do like asac's suggestion of using this to integrate plugin installation
<mvo> cjwatson: yes, that is a good use-case for tihs too
<mvo> cjwatson: we can build some funky c-n-r thing with it too
* mvo needs to run for dinner now
<pitti> tkamppeter: ah, found it at http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/ghostscript/
<ion_> It would be interesting to add quickly indexed I support... metadata to packages, such as: mime:video/x-matroska mime:video/mpeg;fourcc=xvid,XviD,XVID protocol:client/xmpp hw:usb:v*p*d*dc*dsc*dp*ic03isc*ip*
<tkamppeter> pitti, did you not see the link in my e-mails? Sounds like you needed to search for my packages.
<asac> cjwatson: what suggestions do you need?
<pitti> tkamppeter: yup, saw it too late
<cjwatson> asac: read my sentence again :-)
<cjwatson> asac: I meant I liked your existing plan
<elmo> More than one copy of package bzr has been unpacked in this run !  Only configuring it once.
<elmo> Setting up bzr (0.8.2-1ubuntu3) ...
<elmo> except I installed bzr 0.8 and bzr 0.16 - surely configuring the later one would have been more useful?
<cjwatson> probably depends what order they got unpacked in ...
<asac> cjwatson: ah ... i have no special requirements on the apt: protocol handler ... it should just allow specific packages to be installed :)
<cjwatson> which might just have been command-line order?
<elmo> cjwatson: yeah, they were unpacked in 0.16 0.8 order due to shell glob expansion
<asac> maybe i need kind of "from which repo" ... if there are multiple versions found
<cjwatson> right, so it couldn't configure 0.16 because it wasn't there any more :)
<cjwatson> might be nice if it sorted multiple unpacks though
<elmo> oh, err, right
<pitti> tkamppeter: btw, I never got an email pointing to the updated URL with the 'ghostscript' package. Maybe you just forgot to CC: me, but if not, then can you please send this to the Debian upstream?
<tkamppeter> pitti, I have sent it, at 3:54pm german time. You are CCed. Also Masayuki from Debian should have gotten it. Perhaps it was caught by your spam filter.
<pitti> tkamppeter: will you also upload a fixed hpijs? (it has a versioned depends on the various gs-* variants)
<pitti> tkamppeter: not that urgent, but would be nice to not instlal the transitional packages by default
<tkamppeter> pitti, will correct this soon. I did not know that there were explicit dependencies on gs-*.
<tkamppeter> pitt, but as ghostscripts has a "Provides: gs-*" the transitional packages do not need to stay installed.
<pitti> tkamppeter: the problem is if a package like hpijs depends on 'gs-eps (>= 7)' (similar)
<pitti> tkamppeter: since Provides: does not support versions
<pitti> tkamppeter: i. e. a Provides: gs-eps will never fulfill a Depends: gs-eps (>= anything)
<pitti> tkamppeter: uploaded and replied
<tkamppeter> So for what is "Provides:" then good for?
<tkamppeter> And also important to know, as "Provides:" in an RPM fulfills dependencies. So then I know not to use "Provides:" in distribution-independent RPMS for printer drivers, to avoid problems with thealien-generated Debian package.
<pitti> tkamppeter: it works well for unversioned dependencies
<tkamppeter> pitt, is this a bug or a feature?
<pitti> tkamppeter: it's not a bug, it's just a missing feature
<siretart> I've written down some lines about managing packages with version control systems like bzr: http://wiki.tauware.de/misc:vcs-packaging - please feel free to give me feedback about this
* pitti jumps and bounces; there's a patch to fix video playback with the nv driver for my card; I can finally use free drivers again
<pitti> hi siretart 
* siretart hugs pitti
<pitti> siretart: anything that could be put onto BzrMaintainerHowto?
<siretart> pitti: I think we should focus on the mode 3 I'm proposing. However, I don't have the impression we have a consensus about that
<siretart> pitti: if we can agree on a mode I propose, I indeed think we should add mode 3 to BzrMaintainerHowto
<pitti> siretart: mode 3 == 'import upstream releases only'?
<siretart> right
<pitti> I agree, that makes most sense
<siretart> I think I have an idea how to extend bzr-builddeb on how to implement the loom concept based on that mode. It however needs some more thought and a proof of concept implementation
* siretart dinner
<seb128> pitti: that pages lacks a "why maintaining packages in bzr" ;)
<bhale> seb128: ack
<siretart> seb128: err, 'because it helps merging with debian and updating to new upstreams'?
<siretart> perhaps I should work out that part
<pitti> and because it makes collaboration of several maintainers much easier
<bdmurray> Bug 27281 had a recent comment in it and it came to my attention.  However, I am not sure what package would bring up that message.  Does anybody have an idea?
<ubotu> Launchpad bug 27281 in Ubuntu "incorrect/misleading error message says home folder should have 644 permissions instead of 755" [Medium,Confirmed]  https://launchpad.net/bugs/27281
<mjg59> Keybuk: Is TB 20:00 UTC or BST?
<siretart> mjg59: according to topic of #ubuntu-meeting, it is 2000 UTC
<kylem> siretart, ping
<seb128> pitti, siretart: it's not for me, and I don't think it makes merging, updating to new upstream and collaboration easier at the moment
<siretart> kylem: pong
<kylem> siretart, i've got the mailman pw for you, which email do you want it bounced to?
<siretart> seb128: for packages using patch systems like dpatch, I agree. If used properly, I do think it can help a lot
<siretart> kylem: the @debian.org please
<kylem> oh, you finished NM? congrats!
<siretart> yeah :)
<seb128> siretart: I'm happy to be proved wrong but for me it's only extra work 
<seb128> siretart: makes sense for packages where you queue work before uploading
<seb128> otherwise it's easier to do your change and upload
<siretart> seb128: I see your point
<seb128> when you want to modify a package using bzr you don't work on usually, you have to look for the bzr location first, checkout, modify, commit, figure how to build from bzr and then upload
<seb128> when in the non bzr case you apt-get source, modify, upload
<siretart> seb128: we discussed in Sevilla with mvo about extending apt to parse the XS-Bzr-Source field of packages to checkout that branch location. this addresses one part of your argument
<mvo> seb128: IIRC pitti filed a bug about that already
<mvo> ETOOMANYBUGS
<mvo> #
<mvo> #115959
<seb128> good, a first step ;)
<mvo> :)
<seb128> you still need to have commit right, commit, figure how to build from bzr ;)
<seb128> but that's getting better
<mvo> we could add somem friendly message about bzr-buildpackage into the apt-get source thing
<Keybuk> mjg59: UTC
<seb128> I think it'll make sense the day we upload from bzr
<mvo> seb128: more tomorrow, I need leave for the evening
* mvo waves
<seb128> if we still have to maintain a source package and keep it in sync with bzr it still doesn't make sense for lot of things
<seb128> mvo: enjoy your evening, see you tomorrow
<mjg59> Keybuk: Might be a minute or two late
<ajmitch> morning
<pitti> evening, ajmitch!
<tkamppeter> pitti, I am currently re-uploading the Ghostscript packages to my site, when merging the Ubuntu/Debian packages I forgot a configure option which made the build on the Ubuntu cluster fail.
<pitti> tkamppeter: NB that you need a new version number now
<pitti> tkamppeter: since -0ubuntu1 is already in gutsy
<tkamppeter> pitt, the corrected source packages are up now, 
<pitti> tkamppeter: weird though, it built fine for me locally, but failed on all buildds
<pitti> tkamppeter: I don't see a -0ubuntu2, please upload it there with a debdiff against 0ubuntu1
<pitti> tkamppeter: another question: why does ghostscript still need to handle alternatives? Can't this all go away, now that we have One True Ghostscript?
<pitti> tkamppeter: ah, forgotten build-dependency on libgtk+2.0-dev?
<tkamppeter> pitti, forgotten to overtake "--disable-gtk" from the gs-esp ./configure.
<pitti> quite amazing that ghostscript now supports gtk
<tkamppeter> I left the update-alternatives in for the case there would be a fork in the future.
<pitti> tkamppeter: what would that give us? and how much would it cost us in terms of disk space?
<pitti> tkamppeter: TBH I'd remove the alternatives stuff now and reintroduce it when necessary
<tkamppeter> pitti, I can take out the update-alternatives.
<pitti> that's not really urgent, though, the FTBFS is more important
<pitti> tkamppeter: so it's 'add gtk build dep' vs. 'disable gtk'?
<tkamppeter> pitti, The GTK support is as follows:
<tkamppeter> There is libgs and there are two executables replacing the monolithic GS, two tini executables linking to libgs.
<tkamppeter> One of them, gsc gives the Ghostscript we know from monolithic times.
<tkamppeter> The other, gsx, has an additional output device named "display" which is the X device but with a GTK-based window.
<pitti> ah, I see
<pitti> tkamppeter: well, I doubt that it is much useful, since we already have good gs frontends for Gnome; so I agree to just disable it
<tkamppeter> Ghostscript had this feature for longer, but neither in Debian nor in Ubuntu it was made use of it. gs-gpl was compiled monolithically all the time, and gs-esp was compiled with --disable-gtk, so only gsc got built. And this gsc was renamed into gs-esp and update-alternatived to gs.
<tkamppeter> Yes, with evince the new GS works perfectly ...
<pitti> tkamppeter: ok, thanks for the heads-up; I'll look at the new gs package tomorrow, if you do it tonight still
<pitti> good night everyone
#ubuntu-devel 2007-05-23
<Hobbsee> morning all
<calc> Hobbsee: hi
<Hobbsee> hey calc, how's it going?
<calc> Hobbsee: doing pretty good, still haven't finished closing on my condo :\
<Hobbsee> awww
<calc> found out my bank screwed up so i can't even get bank statements for the past 2 years due to some weird account crap they pulled on me
<calc> but they are going to send a letter to my lender to clear up anything
<calc> so whatever works :)
<Hobbsee> heh
<keescook> evenin' folks.  time for some dinner.  :)
<ajmitch> hey keescook 
<persia> Could I ask an archive-admin to forcibly reject webboard 0.2.1-0ubuntu4 before it is compiled and released?  I'd like to release a replacement -0ubuntu4 instead (and maintain a clean changelog).  Apologies.
<Hobbsee> persia: just upload another
<Hobbsee> dont think the archive admisn are awake
<persia> Hobbsee: OK.
<pitti> Good morning
<Burgundavia> morning pitti
<Mithrandir> morning, pitti 
<Hobbsee> hey pitti, Mithrandir 
* pitti hugs Hobbsee, Burgundavia, and Mithrandir
* Hobbsee hugs pitti and everyone else :D
* Hobbsee be squashed, though, as everyone else is bigger than her.
* Burgundavia hugs the world!
<Mithrandir> morning, Hobbsee 
<Hobbsee> morning :)
* Hobbsee wonders how high one can make the load on one's computer, when building kde packages.
<Hobbsee>  00:34:01 up 18:22,  1 user,  load average: 3.70, 3.07, 2.37
<Hobbsee> so far
<Hobbsee>  00:35:16 up 18:23,  1 user,  load average: 4.10, 3.33, 2.51 once it properly starts
<Mithrandir> just build more of them?
<Hobbsee> that's with 3 at once
* Hobbsee is about half way thru
<Hobbsee> 8 done, or almost done, 10 more to do.
<ajmitch> morning Mithrandir 
* pitti shakes his head at bug 110724
<ubotu> Launchpad bug 110724 in openoffice.org "OpenOffice runs as root for all users" [Undecided,Rejected]  https://launchpad.net/bugs/110724
<ajmitch> pitti: it is a bit crazy, isn't it?
<Hobbsee> pitti: is that another bug for the wall of shame?
<pitti> a proprietary Samsung printer driver which chmod u+s soffice.bin? That's *hilarious*
<pitti> Hobbsee: indeed, fortunately not our wall
<pitti> I don't want to know what crazy stuff 3rd party drivers do on windows
<Hobbsee> heh
<Hobbsee> pitti: https://bugs.launchpad.net/ubuntu/+bug/116344 was the first candidate, if you were wondering.
<ubotu> Launchpad bug 116344 in Ubuntu "Sifilinaptic Package Error for 3 days" [Undecided,Rejected]  
<racarr> I still love that
<pitti> Sifilinaptic?
<racarr> Synaptic was with a gentoo package frontend and caught a rather unpleasant bacterial infection?
<racarr> bad pun :/
<pitti> Hobbsee: well, I'd still not throw 'PEBCAK' at reporters; they might have used automatix and such, which is still PEBCAK, but on a level where they cannot relate it to the bug any more :-/
<Hobbsee> pitti: i only did due to the arrogance of the bugreporter.
<Hobbsee> when you're going to be that rude, then no, sorry, you're not going to get much of a reply
<pitti> I agree, it was a stupid report
<Hobbsee> and the actual part of that bug is already filed
<pitti> Hobbsee: oh, what was it? a proprietary Canon printer driver this time? :-P
<Hobbsee> no, that synaptic is dying over a malformed repository, rather than just ignoring it
<Hobbsee> and giving an unclear "file a bug" warning
<pitti> ah, right; I meant, is it actually known what adds 'sudo' lines to sources.list?
* Hobbsee would suspect an "echo"
<pitti> heh
* Hobbsee hasnt seen that reported before, ever, so....
* pitti registers a spec NoMoreSudoByDefault
<Hobbsee> haha
* Hobbsee registers a spec NoMoreStupidityByDefault
<pitti> 'Use case: if you cannot configure your system in a rescue root shell, you do not deserve to.'
* Hobbsee registers another spec IQTestForUsersDuringInstallation
<StevenK> Actually, echo sudo >> /etc/apt/sources.list won't work, since the shell will try and open sources.list for writing and fail.
<StevenK> It could be a botched script.
<racarr> Yeah. You have to use tee
<Hobbsee> i did wonder if it was tee.  that was the other one coming to mind
<ajmitch> StevenK: blame automatix?
<pitti> StevenK: that's what I was afraid of; there might be some automatix-like thing which screws it up
<pitti> that's why I'm interested in finding dups of that
<StevenK> pitti: Yup.
<Hobbsee> yay, automatixcrack.
<pitti> that reminds me...
* pitti adds an apt sources.list filter to apport
<tepsipakki> automatix et al should just use /etc/apt/sources.list.d/ ..
<tepsipakki> why not make sources.list read-only and force people to put other stuff in .d :)
<Hobbsee> haha
<ajmitch> tepsipakki: immutable, or hard-coded?
<tepsipakki> ajmitch: hmm, what's the difference there?
<ajmitch> tepsipakki: immutable being change by chattr
<tepsipakki> ok, immutable then.. but don't take that too seriously ;)
<minghua> I bet you'll get a flood of bugs with a read-only immutable /etc/apt/sources.list
<ajmitch> back later
<tepsipakki> or, reverse the logic; put distro-sources in s.l.d, and leave sources.list empty for the user :)
<dholbach> good morning
<dholbach> who of you would be interested in doing ubuntu-dev mentoring?
<dholbach>  it'd be nice to have some mentors available once I announce the new mentoring process
<Hobbsee> !logs
<ubotu> Channel logs can be found at http://people.ubuntu.com/~fabbione/irclogs
<pitti> hi seb128
<seb128> hey pitti!
<pitti> seb128: ah, http://merges.ubuntu.com/d/dbus/dbus_1.0.2-5.patch now separates the dbus Xsession.d script; that should get us rid of a few bugs :)
* pitti merges
<seb128> pitti: cool ;)
<pitti> mvo: can you please remove the dbus-1-utils dependency from update-notifier? the package is going away (merged into dbus itself)
<dholbach> hey seb128
<seb128> hi dholbach
<Hobbsee> TB meeting looks interesting.
<mvo> pitti: sure
<dholbach> hahaha... http://launchpad.net/~ubuntu-clusterfuck
<dholbach> awesome
<highvoltage> hehe
<dholbach> hey highvoltage
<highvoltage> good morning dholbach 
<dholbach> highvoltage: I updated reception-data (with input of persia and TheMuso)
<highvoltage> dholbach: excellent. I saw in the diffs that were emailed by launchpad.
<dholbach> super
<mvo> pitti: the retracer seems to ignore #101926 (need-i386-retrace is set). could you please have a look?
<mvo> pitti: same for #81048 (but that one is probably too old :)
<seb128> bug #101926
<ubotu> Launchpad bug 101926 in update-notifier "update-notifier_apt-check" [Undecided,Confirmed]  https://launchpad.net/bugs/101926
<pitti> mvo: ValueError: URL does not contain DistroRelease: field
<pitti> 05/21/07 09:42:55: retracing bug 101926 exit status: 1
<seb128> mvo: not sure if it works with the monolithic format
<pitti> mvo: same for 81048
<pitti> no, it doesn't work with the edgy format
<seb128> pitti: that's not the edgy format, that's people attaching the crash file from /var/crash rather than using apport to send the bug I think
<mvo> ok, thanks
<cjwatson> pitti: apport 0.80 changelog> POSIX sh should have '.'
<seb128> Hobbsee: nice changelog entry on bug #115538 :p
<ubotu> Launchpad bug 115538 in dealer "Please sync dealer (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/115538
* Hobbsee wonders what she's gettign picked on now for, while LP loads
<dholbach> hehe
<Hobbsee> seb128: haha, yes.  i blame debian.
<seb128> ;)
<Hobbsee> seb128: fix debian, kthxbye.
<seb128> Hobbsee: I'm doing the sync no need to bother ;)
<Hobbsee> seb128: hehe.  you appear to trust me. strange person :P
* Hobbsee is a green alien, so is clearly untrustworthy.
* seb128 notes to not trust Hobbsee again
<Hobbsee> seb128: and i do kde stuff.
<Hobbsee> seb128: and i'm different from everyone else, so couldnt be expected to be rational :P
<Mithrandir> shouldn't you be a blue alien then?
<pitti> cjwatson: right, that seems to be a quirk of zsh; I quickly changed this when siretart used that script on his server, and now I fixed it harder
<cjwatson> pitti: I would advise ignoring bugs due to using zsh as /bin/sh - that's definitely not recommended
<Hobbsee> Mithrandir: azure :P
<cjwatson> bash really shouldn't be needed just for ''
<Hobbsee> Mithrandir: there are no other green aliens, anyway
<cjwatson> '.'
<siretart> cjwatson: I don't have /bin/sh -> /bin/zsh. I only executed that script
<pitti> siretart: well, we copy&pasted commands from it to your sh
<siretart> yeah
<cjwatson> siretart: but you ran the script with zsh, right?
<siretart> indeed
<cjwatson> http://www.opengroup.org/onlinepubs/009695399/utilities/dot.html mandates '.' in a sh implementation - if zsh doesn't understand it, that's zsh's problem
<cjwatson> I didn't think zsh really claimed POSIX sh compatibility though
<siretart> hmm. it seems that zsh's '.' command expects a full pathname to the script to source, and doesn't like it in the current directory
<siretart> '. .alias' fails, but '. ~/.alias' works
<cjwatson> ah, now that is actually a bash bug I think - '.' is supposed to use $PATH, not the current directory
<siretart> according to your link, '.' is supposed to look in $PATH. I surely don't have '~' in my path
<cjwatson> so if apport's relying on cwd, it should use '. ./file'
<siretart> interesting
<siretart> which would work in zsh as well :)
<jmg> hey all whatever happened about upstart replacing cron?
<siretart> jmg: that needs to be implemented in upstart. there has been a discussion on the upstart mailing list about that
<pitti> siretart: hm, that's a really weird and nonintuitive thing, using $PATH for command line arguments
<pitti> yay for Unix consistency :)
<siretart> pitti: seems to be a unix standard however.. I admit that this is news to me
<pitti> siretart: hm, in this case I agree with bash TBH; sourcing something that could be anywhere in $PATH seems actively dangerous and error prone to me
<pitti> hm, bash still looks at $PATH for the argument, though
<siretart> pitti: I can imagine that there is somewhere a switch for zsh to enable this behavior
<siretart> aah, so bash just 'adds' '.' to the $PATH for sourcing? that's nasty
* pitti readjusts his future usage of .
<siretart> does bash prepend or append '.' to $PATH for '.'?
<pitti> no
<pitti> erm, sorry
<pitti> siretart: append
<siretart> wow
<siretart> this smells really fishy
<cjwatson> pitti: '.' is analogous to normal command execution
<cjwatson> IMO
<pitti> hm, then we seem to have a completely different view about what sourcing is supposed to do
<mvo> is librarianl.lp.net not working currently?
<cjwatson> "execute the stuff in that file in the context of the current shell" is how I think of it
<pitti> I have always regarded it as kind of #include for shell
<pitti> and had expected to give a path to a file name to it, not a command
<cjwatson> well, the path you give it doesn't have to be executable
<pitti> right
<cjwatson> I know of some things that rely on . looking in $PATH to useful effect
<cjwatson> e.g. '. gettext.sh'
<pitti> tkamppeter: ghostscript FTBFSed again, still stumbling over gtk
<seb128> pitti: what?
<pitti> seb128: don't worry, gtk is fine, it just complains about not finding the gtk .pc (it doesn't build depend on gtk-dev and isn't meant to)
<seb128> ah, k
* pitti can hear seb128's "PHEW" here
<seb128> :)
<tkamppeter> pitti, I have seen the Ghostscript problem. It is an upstream problem of the original GPL GS not being able to be compiled as libgs without GTK. ESP GS had fixed it and now I am moving this fix to upstream. Then I will make the Ubuntu package with an updated upstream tarball.
<pitti> mvo: argh, u-n has a versioned depends on dbus-1-utils, so the Provides: won't be enough
<Mithrandir> tkamppeter: are you upstream for ghostscript?
<mvo> pitti: I will upload a new u-n today, I think the -1-utils is really no longer needed
<pitti> mvo: right, and the next dbus will have dbus-monitor anyway
<pitti> mvo: today would be good, then I'll wait with the NEWing until that happened
<pitti> seb128: yay, things work well without the dbus Xsession.d script
<seb128> \o/
<pitti> seb128: I'll add a preinst transition bit that removes an unmodified script on upgrade
<seb128> pitti: GNOME works fine, but how is that going to work for other environments?
<pitti> seb128: they need to depend on dbus-x11
<seb128> ok
<pitti> Riddell, Hobbsee: do you know whether KDE needs a session dbus, and if so, will it start one by itself? or does it need /etc/X11/Xsession.d/75dbus_dbus-launch?
<mvo> pitti: ok, I wil ldo it before lunch
* pitti hugs mov
* pitti hugs mvo, too
* Hobbsee doesnt know
* Hobbsee is envious of mov.
* pitti gives Hobbsee the second hug of the day
<Hobbsee> :)
<pitti> Hobbsee: an experiment: just move this script away, log into KDE and check whether things are still working
<Hobbsee> yay, double hug!
<pitti> Hobbsee: at least in Gnome things work better than before
* Hobbsee will have to try later
<pitti> Hobbsee: or, simply check 'ps ux | grep dbus' whether you have a session dbus running
<pitti> (before and after moving the script)
<tkamppeter> Mithrandir, yes, I have gotten SVN write access, as I was also developer of ESP Ghostscript (ESP GS was by 95 % done by Mike Sweet and me) and so with the ESP GS merger Mike and me got also merged into GPL GS.
<Riddell> pitti: KDE 3 doesn't seem to need it, and I can't think why it would need it.  KDE 4 I'm almost certain will need it, I'm not sure if it has a way of starting it itself
<Riddell> pitti: why don't you want the dbus Xsession.d script?
<pitti> Riddell: if dbus is started from gnome, it gets some additional environment variables that some programs rely on
<pitti> Riddell: such as gnome-power-manager recognizing the keybindings for the power off button etc.
<pitti> Riddell: this is of course a bug in those apps, but it's easier to fix like this
<pitti> Riddell: if KDE4 needs it and doesn't start one on its own, we just need to add dbus-x11 to kubuntu-desktop, or make it a dependency of, say, kdebase
<mvo> pitti: can bug #61730 be closed now? 
<ubotu> Launchpad bug 61730 in update-notifier "No indication to the user that a core dump is in progress" [Low,Confirmed]  https://launchpad.net/bugs/61730
<Riddell> pitti: and that brings in the Xsession.d/75dbus_dbus-launch script?  won't that then break gnome again?
<pitti> Riddell: yes, for the case that someone installs both KDE and Gnome in parallel
<pitti> Riddell: as I said, it's not a good solution, but a quick one, and Debian split out the package, so I'd like to follow that
<Riddell> ok
* Riddell wonders what starts  /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
<Riddell> ah, that is the 75.. script
<gon> hellllllllo
<seb128> Hobbsee: isn't the gtk2-engines-gtk-qt transitionnal package required for dapper upgrades?
<Hobbsee> seb128: errr....i'm not sure, i'd have to check that
<Hobbsee> seb128: yes.  damn.
<Hobbsee> didnt think of that
<seb128> Hobbsee: I've removed the binary from gutsy for now since it's not longer built from the source package
<seb128> feel free to add it again if it's required
<Hobbsee> seb128: right. 
<seb128> Provides should really be versionned
<Hobbsee> seb128: would have thought a replaces: on the engines gutsy package would suffice, no?
<seb128> so we would not have to keep all those dummy packages only for upgrades
<Hobbsee> er, with the dapper version, presumably?  or the version where it changed?
<seb128> Hobbsee: well, it'll not install gtk-qt-engine when you try to update gtk2-engines-gtk-qt on dapper
<pitti> seb128: we need dummy packages for upgrades anyway, regardless of versioned provides
<seb128> pitti: why?
<pitti> until the next LTS
<seb128> right, because Provides are not versionned
<pitti> seb128: if you have a installed, and then a is removed from the archive and b Provides: a, then apt- won't automatically install b
<Hobbsee> pitti: then surely that's a bug in apt?
<pitti> Hobbsee: not really IMHO
<pitti> Hobbsee: first, it would be pretty expensive to guess which package to install, and also pretty error prone
<Mithrandir> pitti: I doubt you'll be able to upgrade without using the dist-upgrader, but no need to make it harder than we have to.
<seb128> pitti: that's because the provides is not newer than the real package because it's not versionned, no?
<pitti> Hobbsee: for example, if there are several replacements
<Hobbsee> good point
<Mithrandir> Hobbsee: that'd break if I had, say, a custom mta installed locally and apt would continually try to install another one because it didn't see my custom one in a repo.
<pitti> seb128: no, an upgrade will update the versions of installed pacakges, not install new packages out of thin air
<pitti> seb128: right, that too
<seb128> pitti: so the problem is not the versionning, is that we need a new field "deprecates"
<pitti> seb128: with versioned provides, apt could grab the latest available one, but I'm not sure whether this woudl break anything else
<seb128> which means "install that package instead of this old one"
* Keybuk considers an evil plan
<seb128> I think it's stupid to create zillion of dummy packages for that
<pitti> seb128: and if two packages deprecate the old one?
<Keybuk> I'm going to modify bzr to send the bazaar folks an e-mail, instead of nagging me about bzr-gtk being out of date
<seb128> that should really we a package field
<pitti> seb128: well, keeps us from renaming more pacakges than we really have to :)
<Hobbsee> Mithrandir: point
<seb128> pitti: don't use the "deprecate" then
<seb128> pitti: there is plenty of case where we keep a dummy package just for upgrade
<pitti> seb128: it should be something that points from the old package to the new one, not the other way round
<seb128> that's cluttering the apt index, the archive, etc
<pitti> seb128: I agree
<seb128> pitti: the old package you can't update
<seb128> usually you upload new packages, not old ones ;)
<pitti> right, that's why we currently use transitional packages :)
<pitti> whoops
<seb128> which sucks
<pitti> well, it's the renaming of packages that sucks
<seb128> I don't get what why a new "deprecates" would not work
<pitti> if it would be made easier, it would happen a lot more often, I figure, and create more problems
<pitti> seb128: if it would be used carefully, it certainly would
<seb128> you can create mess with transitional packages as well
<pitti> seb128: and you don't even need a new field for this; C/R/P is meant for this purpose
<pitti> you just need to teach apt to automatically replace those
<seb128> well it doesn't work
<pitti> but I can think of use cases where this would break
<pitti> (alternatives, like gs-esp vs. gs-gpl or so)
<seb128> if you have gaim on edgy and apt-get install gaim with gutsy source it'll not install pidgin without a transitional package
<seb128> right
<seb128> it'll would be mainly for renaming
<seb128> not for packages replaced by something else
<pitti> still, having a transitional package in debian/control instead of a new field isn't that much more work IMHO
<seb128> no, it's just ugly and increase apt index noise
<pitti> right
<Keybuk> it's an utter arse if you ever want to rename back though
<Keybuk> the trouble with transitions like that is that they are permanent
<Keybuk> consider the esd/polypaudio crack change
* Hobbsee begins to think this whole LTS thing is overrated.
<pitti> Hobbsee: well, LTS->LTS upgrades are kind of an important use case
<Hobbsee> true
<highvoltage> LTS is a touchy and difficult subject.
<pitti> but in gutsy+1 we can drop a *lot* of transition bits :)
<Hobbsee> :D
<pitti> s/in/after/
<Hobbsee> highvoltage: how so, in particular?  i wasnt aware of anything beyond a "having to keep all the transitional packages" POV
<Keybuk> pitti: no, we can't
<Keybuk> since gutsy+1 is the LTS, it needs all the transitions bits
<Keybuk> we can drop some in gutsy+2
<pitti> Keybuk: <pitti> s/in/after/ :)
<pitti> Hobbsee: I agree, keeping the transitional bits for so long is the main pain ATM; the rest is mainly political, I guess ;)
<Hobbsee> oh well, i know for next time, at least.
<pitti> Rejected:
<pitti> Unhandled exception processing upload: HTTP Error 502: Proxy Error
<pitti> ??
<pitti> seb128: you recently saw something like this as well, right?
<seb128> pitti: yeah, syncing was broken this way and it automagically fixed (or somebody did)
<seb128> pitti: oh, no, that was Bad Gateway for me
<seb128> you get that when uploading?
<pitti> seb128: yes
* pitti asks in #c-s
<tkamppeter> pitti, new 0ubuntu3 ghostscript packages are uploaded to the usual place. They contain the needed upstream fix. Can you please upload them? Thanks.
<pitti> tkamppeter: sure
<pitti> tkamppeter: hm, the changelog says 'new upstream release', but it's actually not
<pitti> tkamppeter: it's -0ubuntu3 and uses the same orig.tar.gz as before, and no debian/patches/svn-fixes.diff either
<Mithrandir> hi adilson
<agoliveira> Mithrandir: good morning
<dholbach> can I tempt anybody to join the ubuntu-dev mentors? I'd like to announce the new process soon and it'd be nice to have some more people who are willing to take on contributor or two and help them on their first steps :)
<tkamppeter> pitti, the source tarball is a new SVN snapshot, only the name is the same. I have replaced the _source.changes file by one with "-sa" now.
<pitti> tkamppeter: that doesn't work, you have to bump the version name
<pitti> indeed, the .dscs for ubuntu2 and 3 have a different md5sum for the orig.tar.gz
<pitti> tkamppeter: the old orig.tar.gz is already in the archive, it cannot be overwritten with a new one
<tkamppeter> pitti, so I have to change the upstream version name for a new SVN release. How are the conventions, so that I can start over with the right versioning scheme?
<pitti> tkamppeter: if the changes are relatively small, doing the svn fixes in debian/patches might be preferable
<pitti> tkamppeter: the other convention would be something like 8.60.dfsg.2 or 8.60.dfsg.1+svn20070523
<pitti> tkamppeter: the latter is more common, but since the old orig.tar.gz has an distro specific suffix anyway (.1) you could just as well increase that
<tkamppeter> And if I go for 8.60.dfsg.1+svn20070523 how should I name the final 8.60 release?
<pitti> tkamppeter: hmm
<pitti> tkamppeter: in retrospective, you should have used 8.60.dfsg~beta1 or so
<pitti> tkamppeter: now, just going to .2 should be fine
<pitti> tkamppeter: oh, btw, what did you have to remove for DFSG compliance?
<tkamppeter> So then I will take 8.60.dfsg.1+svn7997 for now and 8.60.dfsg.2 for final?
<tkamppeter> This is already done by the Debian folks, they remove Resource/Cmap because they consider that non-free.
<pitti> tkamppeter: sounds good
<pitti> tkamppeter: ah, is that a binary file without source, or sth. like that?
<tkamppeter> pitti, what do you mean?
<pitti> tkamppeter: for example, some upstreams ship PDF files in their GPLed tarballs without a 'source' (such as an OpenOffice or LaTeX document)
<pitti> tkamppeter: don't worry for now, I was just curious
<pitti> tkamppeter: btw, I changed all the seeds from gs-esp-x to ghostscript-x yesterday
<tkamppeter> No, the problem is that the CMap directory contains files with licenses for only verbatim redistribution.
<pitti> tkamppeter: I'll do the meta uploads and the removals once the new gs is actually in gutsy
<pitti> tkamppeter: ah, I see
<tkamppeter> pitti, now I redownloaded 0ubuntu2 from launchpad and did the standard uupdate approach to get to the new source tarball.
<tkamppeter> The new version will be 8.60.dfsg.2-0ubuntu1. Will the archive accept this one?
<pitti> tkamppeter: yes, that's fine; the final version will be .3 (or .4 or whatever) then?
<tkamppeter> Yes, so with every SVN update I will simply bump that number by 1. So if the final of 8.60 will take some time but we need the bug fixes they do earlier it can end up in 10 or 20 ...
<tkamppeter> For later versions I will directly start with something like 8.61~svnXXXX. Can one then use 8.61 for the final?
<pitti> tkamppeter: yes, you can
<pitti> tkamppeter: ~ is a special operator introduced for exactly this use case
<pitti> tkamppeter: it means 'smaller than the version before it'
<pitti> tkamppeter: so 1~1 << 1~2 << 1
<tkamppeter> Thank you very much, making use of this for the ghostscript package is not possible any more, but I will use it in later, similar use cases.
<Mithrandir> this means you can have positive version numbers smaller than 0.
<Hobbsee> that's...stuffed.
* highvoltage so doesn't understand that
<pitti> yes, you can have negative versions :)
<pitti> 0~1 < 0
<highvoltage> aaah
<tkamppeter> pitti, packages are on their way to my web space now: 8.60.dfsg.2-0ubuntu1.
* pitti -> lunch
<pitti> tkamppeter: will take a look later
<tkamppeter> pitti, thanks for all, tell me as soon as you have any questions or results.
<slomo> pitti: you might want to merge hal 0.5.9-3 (on incoming now i guess), it also uses a real init script now
<tkamppeter> pitti, upload of the new source files has completed.
<Keybuk> slomo: doesn't HAL depend on D-BUS anymore then?
<slomo> Keybuk: it still uses dbus... but stuff like hal and avahi got moved from /etc/dbus-1/event.d scripts to real init scripts
<Keybuk> any particular reason?
<slomo> Keybuk: afaik only consistence... every other daemon is in /etc/init.d and you could disable it with rc-conf for example
<Keybuk> fair enough
<pitti> tkamppeter: I'm back
<pitti> slomo: yep, will do that
<tkamppeter> pitti, all files are in place for a new upload now I hope the version numbering is correct now.
<pitti> tkamppeter: yep, it looks good; downloading right now
<pitti> slomo: that leaves us with dhcdbd, NetworkManager, and system-tools-backends
<nuu> does anybody know why s2disk (uswsusp) doesn't support screen width/height (-x and -y) params anymore ? that breaks hibernate.sh in acpi-support 0.95
<Mithrandir> because it's not needed?
<Mithrandir> acpi-support should just be fixed not to pass them
<slomo> pitti: i guess mbiebl will care for NM and dhcdbd soon... for s-t-b let's ask the debian maintainer :)
<StevenK> I uploaded uswsusp, should I fix acpi-support?
<nuu> StevenK: well from what i can tell, you could remove the whole usplash.conf checking if-fi block altogether from hibernate.sh
<nuu> ie just check for -x on s2disk, and run it without further ado
<StevenK> nuu: Would you mind filing a bug against acpi-support if you haven't already?
<nuu> sure, will do
<StevenK> nuu: Thanks!
<nuu> yw
* ogra-classmate watches evo filtering 22000 messages on his classmate ...
<jsgotangco> it can?
<bhale> jsgotangco: how many mails to the center of a evolution core dump?
<ogra-classmate> jsgotangco: sure
<ogra-classmate> it just gets extremly slow the first time it has to pull down all the imap headers
<jsgotangco> i mean is it like functioning as expected or awfully slow
<jsgotangco> ahh
<ogra-classmate> but once thats done it behaves 
<jsgotangco> ahh but would kids be expected to use evo? heh
<ogra-classmate> seb128: one thing i always notice is that evo seems to queue *every* click even if its unresponsive for a minute or so ... we should limit this queue 
<pochu> jsgotangco: And would kids be expected to have 22k messages? :)
<ogra-classmate> jsgotangco: no idea, its an app we ship so i need to test if it works
<kylem> pochu, kids reading lkml?
<pochu> kylem: nice kids, then :)
<bhale> kylem: i read it when i was 16, that is why i am brain damaged
<ogra-classmate> using my personal inbox and seeing it work *somehow* is enough of a stresstest i think ;)
<seb128> ogra-classmate: stop clicking like a mad man when the app doesn't react ;)
<ogra-classmate> seb128: i dont, but sometimes i'm in the overview list without noticing and scroll up or down
<jsgotangco> poor kids, i'll make sure my 5 year old won't use one then heh
* jsgotangco hides
<ogra-classmate> so it tries to display 50 msgs in a row
<ogra-classmate> having the queue limited to the last 5 or so would increase performance imho
<nuu> StevenK: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/116411
<ubotu> Launchpad bug 116411 in acpi-support "wrong s2disk parameters invoked by hibernate.sh in acpi-support 0.95 when /etc/usplash.conf is present" [Undecided,Unconfirmed]  
<StevenK> nuu: Excellent, thanks.
<nuu> you're very welcome
<pitti> tkamppeter: uploaded, thank you!
<aquarius> Is there some documentation somewhere on what services packages.ubuntu.com provides (i.e., what /cgi-bin/download.pl does, etc)? Or, more particularly, can I jump to "the latest version of vlc in feisty" through some nice URL like p.u.c/feisty/graphics/vlc/download without getting the vlc page and parsing it myself for the deb link?
<persia> aquarius: You probably want http://launcpad.net/ubuntu/+source/vlc
<aquarius> persia: ah, not really; what I want to do is point someone at a "download this package by clicking here" link which won't break if there's a patch release.
<aquarius> So http://packages.ubuntu.com/cgi-bin/download.pl?arch=i386&file=pool%2Funiverse%2Fv%2Fvlc%2Fvlc_0.8.6.release-0ubuntu4_i386.deb&md5sum=f10ad4197a89c79069a7a9eab73a5f0d&arch=i386&type=main (the get-a-deb link from p.u.c) is no good because if there's a new release of that package inside feisty, that link won't be to the most recent version.
<aquarius> and launchpad also links directly, so http://librarian.launchpad.net/6873078/vlc_0.8.6.release-0ubuntu4_i386.deb as a link is no good either.
<aquarius> I don't know whether the source to packages.ubuntu.com is available anywhere; I looked, but couldn't find it.
<Keybuk> it's the same as packages.debian.org
<aquarius> Keybuk: yeah, but #debian are being unresponsive and I can't find source for p.d.o either :)
<Keybuk> probably in their websuite source somewhere
<Keybuk> try mailing the debian-www e-mail lsit
<Keybuk> it must be available since someone else set up packages.ubuntu.com
<aquarius> yeah. I'll mail if I have to, I just figured asking on irc would be quicker...
<aquarius> ...and I was wrong ;)
<Ng> aiui packages.u.c is run by the same guy as packages.d.o, so it may be that only he has the source
<Keybuk> aquarius: djpig is apparently the person you need to ask
<aquarius> Keybuk: aha, yep, http://www.djpig.de/projekte/ has a (broken) link to a CVS repos...
<cjwatson> aquarius: IIRC the source used to be in debian-www CVS
* cjwatson goes to poke
<cjwatson> aquarius: http://cvs.debian.org/packages/?root=webwml
<cjwatson> doesn't seem to have moved to svn yet
<cjwatson> aquarius: a.k.a. 'cvs -d :pserver:anonymous@cvs.debian.org:/cvs/webwml co packages'
<cjwatson> in fact, there's an ubuntu branch there
<cjwatson> cvs -d :pserver:anonymous@cvs.debian.org:/cvs/webwml co -r ubuntu -d ubuntu-packages packages
<aquarius> cjwatson: aha! cool.
<mc44> was there a reason ndiswrapper was dropped from the feisty desktop CD?
<ogra-classmate> is there any way to restrict the amount of tmpfs to be used for varrun varlock etc ? TMPFS_SIZE seems to be completely ignored
<ogra-classmate> intrestingly SHM_SIZE isnt ...
<ogra-classmate> Keybuk: ?? ^^^
<Keybuk> ogra-classmate: no, but then they don't grow large anyway
<ogra-classmate> Keybuk: well, doesnt it allocate the maximum in ram?
<mjg59> It's not allocated until used
<ogra-classmate> ah, cool
<ogra-classmate> but still, setting 
<ogra-classmate> TMPFS_SIZE shouldnt be ignored
<mc44> on what package should I file a bug about the seeds?
<ogra-classmate> the fun stuff is that its apparently read by the initscript
<Keybuk> ogra-classmate: it's just swap space, usually
<ogra-classmate> well, i'm on a swpless system
<ogra-classmate> and try to get the last out of the ram
<Keybuk> ogra-classmate: where have you found this TMPFS_SIZE variable?
<ogra-classmate> its mentioned in /etc/default/tmpfs
<Keybuk> if there's too much in /var/run or /var/lock, limiting the size won't help you -- that'll just break the boot
<Keybuk> it is?
<Keybuk> only SHMFS_SIZE is mentioned there for me
<ogra-classmate> and apparently thats sourced by the initscripts
<tkamppeter> pitti, everything of ghostscript has successfully built now. Thank you.
<mjg59> Keybuk: # SHM_SIZE sets the maximum size (in bytes) that the /dev/shm tmpfs can use.
<mjg59> # If this is not set then the size defaults to the value of TMPFS_SIZE
<mjg59> # if that is set; otherwise to the kernel's default.
<mjg59> (feisty)
<cjwatson> mc44: ubuntu-meta is usually good enough if they're the Ubuntu seeds (otherwise substitute as appropriate)
<Keybuk> right, SHMFS_SIZE sets the size of /dev/shm
<ogra-classmate> right, thats what i have as well
<Keybuk> I can only see it get used by that
<mjg59> Right, but it implies that there's a TMPFS_SIZE that can be set somewhere
<Keybuk> that does indeed refer to a TMPFS_SIZE which is defined to "" in the same init script
<ogra-classmate> TMPFS_SIZE=
<ogra-classmate> [ -f /etc/default/tmpfs ]  && . /etc/default/tmpfs
<ogra-classmate> from mtab.sh
<Keybuk> I don't think it's useful to limit the size of /var/run or /var/lock though
<Keybuk> ogra-classmate: why do you disagree?
<ogra-classmate> the same is in mountvirtsubfs.sh
<Keybuk> ? there is no mountvirtsubfs
<mc44> cjwatson: thanks
<ogra-classmate> well, if its not allocated before usage i dont care much, but the variable not being used seems inconsistent
<Keybuk> it makes sense to limit /dev/shm, since that's POSIX shared memory
<Keybuk> and there's a defined behaviour for that being unavailable
<ogra-classmate> Keybuk: devsubfs indeed
<Keybuk> if you limit the size of /dev, /var/run or /var/lock, you just break important things
<desrt> tmpfs mounts default to half of physical memory
<ogra-classmate> yeah, so lets drop the variable 
<Keybuk> ogra-classmate: I think the variable has largely been dropped, and one instance of it was missed :p
<ogra-classmate> its just confusing and makes you think you can influence anything with it
<ogra-classmate> well, fine then :)
<Keybuk> otoh, it would make sense to limit the size of /tmp, if we mounted that as a tmpfs
<desrt> Keybuk; if you're gonna do that, please write something in the login-without-free-space blueprint
<desrt> Keybuk; since that would trivialise that entire spec :)
<Keybuk> desrt: do which?
<desrt> Keybuk; there's a spec from uds for logging in when all free space is used
<desrt> Keybuk; gdm falls back to writing xauthority into /tmp.  we're creating /var/overflow (1MB tmpfs) for it to write into.
<desrt> Keybuk; if /tmp is tmpfs (and not, say, part of a filled /) then we can just leave it in /tmp
<desrt> i think some apps do stuff like generate iso images and .wav files for CD burning in /tmp, though :)
<mc44> cjwatson: bug 116436
<ubotu> Launchpad bug 116436 in ubuntu-meta "wrong version of ndiswrapper in ship-live seed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116436
<cjwatson> desrt: please can it be /var/somethingthatisactuallyinthefhs
<desrt> cjwatson; :)
<cjwatson> desrt: ideally /var/run or /var/lock - otherwise the installer has to have code changes to create yet another tmpfs on the root filesystem
<cjwatson> /var/run seems perfectly good for this
<desrt> cjwatson; the problem is that it has to be a world-writeable (sticky) location
<desrt> cjwatson; and having such a location in /var/run or /var/lock would easily allow a user to pwn the system by filling it up
<cjwatson> so create an appropriately-permissioned directory in /var/run in an init script
<desrt> and when joe-random-user fills /var/run with junk and your daemons can no longer start...?
<cjwatson> then they could do the same with /var/overflow and /tmp and stop gdm from starting?
<cjwatson> DDTT
<ogra-classmate> just move /tmp to a tmpfs by default :P
<cjwatson> also you could make /var/run/gdm or whatever be group gdm, so they couldn't
<desrt> cjwatson; /var/overflow is only used in the emergency case
<cjwatson> desrt: /var/run/gdm should do just as well. please do not make the installer have to do more work here
<desrt> cjwatson; an interesting idea... but i suspect xauthority is created after the permissions drop
<cjwatson> there is no possible reason why /var/overflow can be superior to /var/run
<desrt> cjwatson; but it's worth checking out
<cjwatson> either can be filled up maliciously in exactly the same ways
<cjwatson> aside from the blatant FHS violation
<desrt> but 99.9% of the time if you fill /var/overflow nobody will care
<desrt> it's merely a fallback
<desrt> it's only used if every last block of space is occupied in ~
<cjwatson> it is still a bogus name
<desrt> i agree
<cjwatson> also, 83.6% of statistics are made up on the spot ;-)
<desrt> i'll look into the gdm-group xauthority thing
<desrt> cjwatson; fwiw, the real number is more than 99.9% :p
<cjwatson> having had to fix bemused people's systems when their root filesystem filled up, I disagree
<desrt> fewer than 1 in 1000 logins will fail due to there being exactly 0 blocks free on the partition that holds ~ :)
<cjwatson> it may be numerically small, but the impact is large
<desrt> ahah.  now you discover the "damned lies" aspect of statistics :)
<cjwatson> people care when they cannot log in and there is no indication whatsoever as to why
<cjwatson> or how to fix it
<desrt> it's really two separate cases, though
<desrt> if the user intentionally fills /var/overflow then to hell with them
<cjwatson> same goes for /var/run
<desrt> but if, on a server, say, the user is permitted to fill /var/run then we have trouble
<cjwatson> anyway, you can always mount another tmpfs under /var/run
<desrt> true.
<cjwatson> which solves the FHS issue
<desrt> it's a better place for it.
<cjwatson> having /tmp on tmpfs is a bit controversial (unfortunately?)
<cjwatson> and certainly making it be that way on upgrades would be a significant headache
<cjwatson> if you're on a low-memory but reasonable-disk system, /tmp on tmpfs can be a loss if you're used to dumping fairly big temporary things there
<ogra-classmate> yeah, firefox can get quite painful
<ogra-classmate> caching stuff in /tmp
<cjwatson> I have /tmp on a tmpfs on my under-RAMmed server, and mutt has problems dealing with mailboxes that are bigger than available RAM
<cjwatson> since it can't write the whole thing to /tmp
<mjg59> Do we default to /tmp being tmpfs?
<cjwatson> I set a different tmpdir to work around it, but it's pretty annoying
<cjwatson> mjg59: no
<mjg59> Didn't think so
<ogra-classmate> mjg59: nope
<desrt> cjwatson; gdm-group-writeable isn't good enough for creating xauthority.  it really needs to be 777.
<pitti> doko, dholbach: hm, launchpadBugs/HTMLOperations.py keeps throwing 'libxml2mod.so: undefined symbol: xmlTextReaderSetup' at me
<dholbach> URG
<dholbach> pitti: which version and what is are you doing? :)
<pitti> dholbach: gutsy apport retracer chroots
<dholbach> can you give me a use case or something?
<dholbach> I doubt it's a python-lp-bugs bug
<pitti> right, so do I; either it's something strange in python-libxml2, or a side effect of fakechroot
<dholbach> but it'd be nice if I could reproduce it - the bughelper reports generator thing does not have problems like that in its logs
<pitti> dholbach: happens at importing it: python -c 'launchpadBugs.HTMLOperations import Bug'
<pitti> dholbach: in libxml2.py, 'import libxml2mod'
<dholbach> hrm, let me create a chroot and try it there
<pitti> it doesn't happen on my desktop system
<dholbach> (it works on all of my machines - let's see what the chroot says)
<pitti> yeah, don't worry
<slomo> bdmurray: it's not necessary to ask for retraces of mono applications... they're completely useless anyway, same for the apport stuff
<bdmurray> slomo: what makes them useless?
<mvo_> pitti: I have a couple of hundreds apport processes runing on my box that DoS it currently
<seb128> bdmurray: any reason you tag bugs which have been closed as duplicates to retrace them?
<mvo_> pitti: are they supposed to run in parallel?
<pitti> mvo_: well, not exactly forbidden, but certainly not several hundreds
<pitti> mvo_: can you send me /var/log/apport.log?
<pitti> (and kill them afterwards)
<mvo_> pitti: once the system is under control I will
<bdmurray> seb128: I've been going through the mailing list and it seems some duplicate messages aren't showing up
<slomo> bdmurray: because stuff runs in a vm and you will only get random addresses without symbols, maybe some addresses with symbols from native libraries but it's just useless ;) better ask the people to give the terminal output of mono
<seb128> bdmurray: how do you tag the bugs? do you open them in a browser?
<bdmurray> seb128: no
<dholbach> pitti: hum, that works nicely in a chroot
<dholbach> (clean chroot)
<pitti> dholbach: hm, thanks; so I have to leave the gutsy chroots disabled for now
<bdmurray> seb128: I've been using mutt and it's ability to pipe messages to a command.  Sorry for any noise.
<seb128> no problem
<seb128> I was just wondering why I get all those tagging mails for closed bugs
<dholbach> pitti: what does      python -c "import libxml2mod"     say?
<pitti> dholbach: that error message
<dholbach> just 'libxml2mod.so: undefined symbol: xmlTextReaderSetup'?
<pitti> root@ronne:/# python -c "import libxml2mod"
<pitti> Traceback (most recent call last):
<pitti>   File "<string>", line 1, in <module>
<pitti> ImportError: /tmp/tmpZMeAaO/var/lib/python-support/python2.5/libxml2mod.so: undefined symbol: xmlTextReaderSetup
<dholbach> pitti: which version of  {python-,}libxml2  is that?
<pitti> 2.6.28.dfsg-1ubuntu1
<dholbach> both?
<pitti> yes
<dholbach> HRM
<mdz> bdmurray: I think the duplicate email thing may be a "feature"
<dholbach> for me the path is: /usr/lib/python-support/python-libxml2/python2.5/libxml2mod.so
<pitti> that should be a symlink
<seb128> pitti: ldd /tmp/tmpZMeAaO/var/lib/python-support/python2.5/libxml2mod.so | grep xml ?
<pochu> python 2.6? Is that new? :)
<mdz> bdmurray: I recall there was talk about reducing the spam caused by bugs with many duplicates, mailing all subscribers and reporters
<dholbach> pochu: that's the libxml2 version
<pochu> err, libxml2, oks :)
<bdmurray> mdz: if it is that makes it challenging to use the mailing list
<mdz> bdmurray: I agree, it's probably an oversight
<mvo_> pitti: ok, the problem is that apport calls apt-cache. if that crashes that causes apport to go wild (my local version has a bug apparently that I introduced this afternoon)
<mdz> bdmurray: something to raise on the launchpad list, make sure that the bug contact still gets emailed
<pitti> seb128: ldd does not work with fakechroot, sorry
<bdmurray> mdz: will do
<seb128> pitti: and "nm -D /usr/lib/libxml2.so.2 | grep xmlTextReaderSetup" ?
<pitti> # nm -D /tmp/tmpLUYmfr/var/lib/python-support/python2.5/libxml2mod.so | grep xmlTextReaderSetup
<pitti> 0000000000038860 T libxml_xmlTextReaderSetup
<pitti>                  U xmlTextReaderSetup
<seb128> $ nm -D /usr/lib/libxml2.so.2 | grep xmlTextReaderSetup
<seb128> 000ce6c0 T xmlTextReaderSetup
<pitti> similar here
<seb128> weird that it doesn't find the symbol
<seb128> it's present
<seb128> is there an another libxml2.so.2 to /usr/local or something?
<pitti> it's probably something really weird with fakechroot
<pitti> seb128: no, just that
<seb128> weird
* pitti reenables launchpad-crash-digger after lots of hacking
<seb128> how did you fix it?
<pitti> so,  only feisty chroots for now, but crashed gutsy tags won't get lots (I changed launchpad-crash-digger to test that and skip them)
<pitti> seb128: I didn't
<ogra-classmate> hmm, epiphany seems a lot less memory hungry ...
<pitti> but I need to do something else first before I try that again
<seb128> ogra-classmate: than what?
<ogra-classmate> and it scales the pages way better on this little display
<ogra-classmate> seb128: than ff
<seb128> ah
<seb128> yeah, epiphany is nice ;)
<ogra-classmate> i cant use evo and ff at the same time here
<ogra-classmate> but ephi and evo get along very well it seems
<desrt> classmate seems quite evil.
<ogra-classmate> i wouldnt even mind to have ephi by default in the classmate image
<ogra-classmate> but there is always the need for firefox as well, which brings me two menu entries 
<keescook> mornin' folks
<desrt> i have a question, security dude
<keescook> desrt: sure! wup?
<keescook> er sup?
<desrt> when you push security updates, why don't you merely push the single binary package that is actually affected by the issue instead of all of the binary packages from the source package that was affected?
<keescook> desrt: as I understand it, it's a limitation of Debian packaging.  pitti may be able to answer better than me.
<desrt> seems like something that it might be worth fixing
<pitti> desrt: that would mean that we would need to support a concept of multiple current source versions
<pitti> (and binary)
<desrt> pitti; or a concept of equivalent binary version
<pitti> desrt: nope, you cannot assume that they are equivalent
<desrt> pitti; or a concept of binary versions != source versions
<pitti> merely rebuilding a source package can lead to binaries with different behaviour
<pitti> (different toolchain, different library ABIs you build against, etc)
<desrt> it's true... but probably not in a security-update context....
<pitti> desrt: sadly it is
<desrt> the platform is quite stable by this time
<pitti> desrt: because we do not rebuild the entire archive against itself right before release
<desrt> oh.
<desrt> right.  good point.
<pitti> so the binaries in a stable release might be built against an older toolchain, etc.
<mdz> desrt: all of the binaries need to be built by the same source, to preserve sanity
<mdz> desrt: there is a concept of binary versions != source versions, called "binary NMU"
<mdz> but this is legacy stuff which should be avoided; it's the cause of much pain
<desrt> arf
<desrt> rebuilding the entire tree in the week before release would probably be an extremely fun way to screw yourself :)
<keescook> does someone here have irc op powers?  someone's client went crazy on #ubuntu-mythtv
<desrt> keescook; better to ask in #freenode
<pitti> desrt: and you would need to rebuild it at least twice (more if you are not strict on the ordering) :)
<pitti> tkamppeter: ghostscript NEWed
<Keybuk> kyle: can I ask a really tedious question? :P
<kylem> yes.
<Keybuk> kylem: I'm already asking it on #c
<Keybuk> :p
<kylem> ok.
<kylem> :P
<Keybuk> ok, compiz just reached a massive milestone
<Keybuk> I switched to it to have a fiddle, it lost some of my preferences *but* I was able to set them back again
<Keybuk> I can almost think of using this as my window manager <g>
<ion_> :-)
<ion_> Which version?
<kylem> is it smart enough to suck out your metacity prefs yet?
<Keybuk> gutsy
<Keybuk> not yet
<Keybuk> and the hold-down-Super-and-drag-windows doesn't work
<Keybuk> and I'm not sure, but I can't change the list of plugins; might be a gconf-editor bug
<Keybuk> ah no, it keeps editing the plugin list back to fix its order and missing out the one I added
<Keybuk> super-and-drag => conflicts with screenshot/allscreens/options/initiate_button
<dsk> hi
<dsk> how do i distinguish between a PAE kernel or a non-PAE kernel?
<dsk> 2) ubuntu 7.04 has non-PAE kernel by default.. right?
<kylem> dsk, correct.
<kylem> zgrep CONFIG_HIGHMEM64G /proc/config.gz
<dsk> ummm config.gz is not enabled :(
<kylem> anyway, i think the only flavour is server-bigiron with PAE on.
<dsk> correct ...
<dsk> but it raises a big doubt then
<dsk> ubuntu has xen-hypervisor and xen-hypervisor-pae
<dsk> but xen-image is single
<zul> the server config for xen has PAE enabled
<dsk> and we know that we can't mix pae and non-pae kernels
<dsk> zul: but hypervisor can be pae / non-pae but xen-image is single package
<dsk> you see my point here, right?
<zul> xen-image server flavour
<dsk> xen-image-2.6.19-4-generic  xen-image-2.6.19-4-server
<dsk> now which one is pae and which non-pae ?
<zul> yes the second one works with pae
<dsk> and the first one is non PAE then ?
<zul> correct
<dsk> zul: cool ... now i get it ...
<dsk> means of i install xen-image server then automatically i will also install xen hypervisor pae one... right?
<zul> no..install the ubuntu-xen-server metapackage
<dsk> ok lemme try
<Seveas> <dsk> ummm config.gz is not enabled :( <-- for ubuntu kernels config can be found in /boot/config-*
<dsk> Seveas: right but i was thinking of determining that from the vmlinuz files themselves!
<Seveas> dsk, ah
<dsk> because i have a lot of kernels lying around
<dsk> FC6 ones :(
<Seveas> heh
<dsk> which don't have the corresponding configs :(
<dsk> Found Xen hypervisor 3.0-i386-pae,  kernel: /boot/vmlinuz-2.6.19-4-generic
<dsk> Found Xen hypervisor 3.0-i386,  kernel: /boot/vmlinuz-2.6.19-4-generic
<dsk> :(
<dsk> how come the same kernel is getting used, i am unable to understand that
<zul> dsk: ask in #ubuntu-xen
<zul> this channel isnt for support
<dsk> zul: right
<dsk> zul: nobody there  :)
<HlTMAN> hi
* pitti whistles happily while finally watching launchpad-crash-digger grind through the gutsy crashes
<pitti> seb128, bdmurray: ^ :)
<pitti> many of them are useless due to obsolescense, sorry; but with the new auto-tagging it should improve now
<pitti> but it generally works, see bug 114994
<ubotu> Launchpad bug 114994 in brasero "[apport]  brasero crashed with SIGSEGV in g_str_hash()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114994
<pitti> slomo: yay, we can finally sync texlive-bin
<slomo> pitti: yep, i already asked seb128 to sync it ;)
<pitti> (from incoming)
<pitti> slomo: I'll do it tomorrow if seb128 doesn't get to it today; it's not that urgent
<slomo> pitti: thanks, i just don't want to forget about it :)
<pitti> it won't magically cure the ia64 FTBFS, though
<slomo> no... does amd64 build now?
<slomo> at least those two build failures look like something broken in the toolchain
<pitti> lamont: btw, do you still care for ia64? I don't have a porter box login; texlive-bin FTBFSes due to a weird libtool issue, and it is a transitive build-dep for quite a lot of stuff
<ion_> Is libkpathsea already built from texlive? I didnt get around to doing that yet. :-\
<seb128> pitti: I'll sync it, I've just been lazy to do the extra steps to sync from incoming ;)
<pitti> slomo: hm, indeed; 6ubuntu1 built
* seb128 hugs pitti for the gutsy retracer
<seb128> now we need to get a gutsy crash bug ;)
<pitti> seb128: the retracer just grinded through a dozen of them
<pitti> it's still enabled for Kubuntu :)
<seb128> waouh
<seb128> ah, k
<pitti> and for people who flipped the gconf key
<seb128> because we got no desktop ones
<seb128> most of people attach the crash from /var/crash
<slomo> pitti: will you enable SIGABRT again for gutsy in apport? :)
<pitti> seb128: 112579, 116399, 113295
<lamont> pitti: ia64 ubuntu?
<pitti> lamont: yes, gutsy
<lamont> I'll look at tetexlive-bin
<pitti> lamont: (texlive-bin, not tetex)
<pitti> lamont: that would rock, thanks
<pitti> seb128: hm, if you suffer from that, maybe we should flip it on again?
<seb128> pitti: those 3 examples are b0rked :(
<slomo> ion_: yes, i enabled it a week ago or something and it's enabled in debian too now
<pitti> seb128: we still don't have a dup detector, nor automatic rejection for bad retraces
<pitti> seb128: yep, too old :/
<pitti> anyway, I have to run to Taekwondo now; cu tomorrow!
<seb128> pitti: no, thanks, I've just spent a full week catching up on bugs, I need to get other things done
<seb128> apport can wait
<seb128> pitti: have fun, see you
<pitti> 'k
<ion_> slomo: Alright.
<Keybuk> what does the compiz plane plugin do?
<ogra-classmate> makes your laptop hover by using the fans ?
* Keybuk doesn't own a hoverbook
<mc44> Keybuk: it does the sliding viewports instead of a cube
<mrsn0> the plane is quite nice, not sure about compiz but in beryl you can drag + drop from each "window"
<Keybuk> they're not sliving though
<Keybuk> sliding either
<Keybuk> they just fade from one to the other
<Keybuk> *giggle* lots of silly bugs
<Keybuk> nautilus and the panel only appear on the first desktop
<Keybuk> the ssh-askpass window vanishes on login
<Keybuk> etc.
<Keybuk> getting better though
<highvoltage> mdz: when you said "avoid no-op meetings", did you mean no-op as in no IRC ops, or as in http://en.wikipedia.org/wiki/NOP? if it was both, then it's a very nice pun. NOOP meetings suck :)
<mdz> highvoltage: the latter
<hughsie> hey guys. just wondered what was the plan for gutsy with pm-utils?
<seb128> Keybuk: 
<seb128> cd: 236: can't cd to /sys/class/net
<seb128> dpkg: error processing udev (--configure):
<seb128> Keybuk: some builds are breaking on this error
<Keybuk> seb128: oops
<Keybuk> eh?
<Keybuk> why does that fail the buildds
<Keybuk> it's
<Keybuk> cd /sys/class/net || return
<Keybuk> oh, needs to be return 0
<Keybuk> how idiotic
<Keybuk> seb128: uploaded fix
<seb128> Keybuk: thanks ;)
<mvo> cjwatson_: I updated the AptFirefoxFileHandler spec based on your suggestions. thanks again, I think its easier and cleaner now
#ubuntu-devel 2007-05-24
<ajmitch> morning
<jmg> anyone know how to print a range in awk?
<Hobbsee> morning all
<bhale> hi Hobbsee 
<Hobbsee> bhale: :)
<micahcowan> ping BenC
<keescook> g'night folks
<ajmitch> night keescook 
<keescook> cya ajmitch 
<Hobbsee> night keescook 
<keescook> bye Hobbsee
<keescook> oh, ajmitch, did you happen to snag the SELinux initramfs stuff off your laptop?
<ajmitch> keescook: I should grab it now 
<ajmitch> it's on there somewhere :)
<ajmitch> keescook: dget http://ajmitch.net.nz/debuild/selinux/selinux-basics_0.3.0ubuntu1.dsc
<ajmitch> I haven't really changed anything except adding in the hook 
<ajmitch> so don't upload it as-is :)
<BenC> micahcowan: pong
<keescook> ajmitch: thanks (though the tar.gz is missing.)
<ajmitch> hm, shouldn't be, I put it there
<keescook> the ubuntu1 tar.gz was missing
<ajmitch> it's there now :)
* ajmitch just scped the wrong one
<keescook> +mount -t proc ${rootmnt}/proc ${rootmnt}/proc
<keescook> +umount /root/proc
<keescook> should that last one be umount ${rootmnt}/proc  ?
<Hobbsee> keescook: you dont appear to be giong to bed... :P
<keescook> Hobbsee: yeah, there does seem to be that problem.  :P
<ajmitch> keescook: quite likely, this was more along the lines of an experiment :)
<Hobbsee> :P
<keescook> ajmitch: very cool.  Now I can experiment too.  :)  thanks!
<ajmitch> have fun!
<ajmitch> nb: it won't work if you have / & /usr on separate partitions
<djf_jeff> hi, maybe not at the right place but I have a small question : is there a reason why libevent is still at the version 1.1a and not the lastest?
<Hobbsee> djf_jeff: because no one has updated it?
<djf_jeff> Hobbsee: I already guess this ;) Just want to know if there was a compatibility reason for this
<Hobbsee> no idea
<djf_jeff> Hobbsee: ok, thank you, checking the package page on the debian website show some reasons, I should have check there first
<Hobbsee> no problem :)
<micahcowan> BenC, did you see my recent response on my patch submission?
<BenC> micahcowan: yeah, but at the same time, I'd rather patches like that make their way down through -mm and finally to Linus' tree
<micahcowan> BenC, okay, understood. It's currently in -mm. I'll let you know when it's in the main tree.
<BenC> micahcowan: if it makes it into 2.6.22, it'll get into gutsy
<micahcowan> BenC, yeah, that's what I figured. It's not like we don't have plenty of time. :) Just want to keep progress going on it so I can eventually close the bug.
<micahcowan> Thanks, Ben.
<tepsipakki> morning
<tepsipakki> how come does MoM claim a package to be on the normal merge list when the tarballs differ?
<tepsipakki> the package being x-x-v-suncg6
<Burgundavia> is powernowd not run by default for a reason?
<Hobbsee> Burgundavia: it's in universe...
<Hobbsee> iirc
<Burgundavia> hmm
<Burgundavia> nope
<Burgundavia> installed by default
<Mithrandir> Burgundavia: we use the ondemand governor by default.
<Burgundavia> hmm
<Burgundavia> which doesn't scale my celeron M
<Burgundavia> guess that is a bug
<Mithrandir> sounds like a bug, yes
<Burgundavia> would that be a laptop-detect bug, or a kernel one?
<dholbach> good morning
<Burgundavia> morning dholbach
<Hobbsee> morning dholbach 
<dholbach> hey Burgundavia, hey Hobbsee
<pitti> Good morning
<Hobbsee> hiya pitti!
<Burgundavia> Mithrandir: what should I report the bug against. It doesn't look like the proper module is being loaded
<pitti> hey Hobbsee 
<Mithrandir> Burgundavia: if there's a kernel that's not being loaded, but should be, it's a kernel bug.
<Mithrandir> morning Martin, Daniel
<tepsipakki> morning folks, I'll repeat the earlier question; any idea why MoM shows x-x-v-suncg6 to be on the main merge queue when it should be on main-manual (different tarball)?
<pitti> hi Tollef
<pitti> tepsipakki: that should only happen if it ever shared a tarball with Debian; an earlier version perhaps?
<StevenK> I note that MoM still shows python-xml for main.
<tepsipakki> pitti: no, same version (1.1.0)
<Fujitsu> StevenK: Is it not in main? It seems to be here...
<StevenK> Fujitsu: Compare the versions in LP versus MoM for python-xml.
<Fujitsu> Hm, right.
<hydan> what's the status of zfs being ported?
<dholbach> grrrrrrr network-manager grrrrrrrrr
<Burgundavia> dholbach: has it been hardlocking your X as well?
<dholbach_> Burgundavia: no, not that - but it seems it can only connect to my wireless once, if I want to reconnect or if it disconnects for some reason, I have to remove the key from gnome-keyring-manager, then re-add it again
<dholbach_> back on cable network *GRRRRR*
<Hobbsee> it just hates you
<dholbach> maybe somebody is going to updated nm to the newest version in gutsy and all will be good
<dholbach> maybe
<Hobbsee> dholbach: you volunteering?
<dholbach> Hobbsee: maybe not
<Hobbsee> aww
<pitti> dholbach: is 0.7 actually released now?
<dholbach> pitti: 0.6.5
<pitti> dholbach: if someone beats me to it hard enough I might give it a try
<pitti> fixing the broken zeroconf negotiation is on my wishlist for a long time anyway
* dholbach doesn't beat poor pitti
<Jim7J1AJH> Where should I go to find out about python-central and python-support?  (I packaged my app on Feisty, but want to make versions installable on Dapper.  I'm wondering if I should have stuck with the dummy package and underlying python2.n- binaries scheme.)
<pitti> Jim7J1AJH: dapper didn't have central/support and the new-world python policy yet
<pitti> Jim7J1AJH: so I'm afraid that's the case
<Jim7J1AJH> Thanks.  I didn't think to check that until after packaging.
<doko_> dholbach, seb128: will you do the glade merge?
<dholbach> doko: yes
<pitti> dholbach: hm, ISTR that you already talked about the solution of that '<fdopen>' attachment problem (bug 115347); do you already have something in mind, API-wise?
<doko> dholbach: thx
<ubotu> Launchpad bug 115347 in apport "retracer needs to hint at MIME type text/plain" [Low,In progress]  https://launchpad.net/bugs/115347
<dholbach> doko: did you have a chance to find out why and how the python-dbg packages are broken?
<tepsipakki> doko: I've done the syslinux-merge, grabbed an updated patch from suse and the gfxboot works with the new syslinux. I've been in touch with colin about it
<pitti> slomo: argh, texlive-bin still has this weird 'multiple _init/_fini' problem; argh
<doko> tepsipakki: very cool, I did move that one to the end of my merge list ...
<tepsipakki> doko: heh, can't blame you :)
<dholbach> pitti: hum... shouldn't MultipartPostHandler pass the mime-type?
<pitti> tepsipakki: rock! I'm TIL for it, but traded it with cjwatson
<pitti> dholbach: I'll think about it, I just want to avoid double work, since I remember you saying something about it
<dholbach> pitti: I don't know what I should have said about it :)
<pitti> ok; nevermind then :)
<dholbach> MultipartPostHandler already does   contenttype = mimetypes.guess_type(filename)[0]  or 'application/octet-stream'  - maybe it doesn't get called?
<pitti> I'll look into it
* pitti hugs Keybuk and seb128
* seb128 hugs pitti
* Keybuk hugs back
<Keybuk> morning
<dholbach> heya seb128
<seb128> hi dholbach
* Keybuk hugs dholbach 
* dholbach hugs Seor Keybuk back
<Keybuk> seb128: was the Debian menu supposed to have turned up?
<tepsipakki> pitti: about syslinux&no-stack-protector; it seems that upstream has set -fno-stack-protector in some of the Makefiles, but not in all of them. Do you think the rest should still have that?
<seb128> Keybuk: no
<seb128> Keybuk: and it's not on my desktop
<pitti> tepsipakki: as long as it builds, it's fine
<pitti> tepsipakki: i. e. just try ;)
<tepsipakki> pitti: ah, ok
<pitti> tepsipakki: you'll get a linker failure about a missing __stack_chk_fail() if it's missing somewhere
<tepsipakki> I've built it but maybe the gentoo-patch was applied then
<tepsipakki> yep, I'll try dropping that
<Keybuk> seb128: odd; I clicked the Revert button in Edit Menus by accident, and it turned up
<seb128> Keybuk: looks like an alacarte bug then
<Keybuk> yeah could be
<Keybuk> I removed the .local/share/applications/X-Debian-blah-blah.desktop it created, and it went away again
<slomo> pitti: yes... no idea why :)
<dholbach> doko: glade merge done
<Keybuk> when did Ctrl+Shift+Unicode break?
<ion_> Ctrl-Shift-Unnnn
<Keybuk> you have to put a U now?
<pitti> Keybuk: since edgy or so
<pitti> Keybuk: yep, Ctrl+Shift+u, then enter the digits
<seb128> Keybuk: 
<seb128> 	* gtk/gtkimcontextsimple.c: Rework the Unicode hex input
<seb128> 	code. Now we only steal a single key combination, Ctrl-Shift-U,
<seb128> 	instead of sixteen. 
<seb128> that's since dapper
<Keybuk> :-)
<Keybuk> fortunately I don't remember the numbers of many Unicode characters,
<Keybuk> and those I do, I don't feel the need to type very often
<pitti> seb128: too bad that it doesn't work in xchat
<Keybuk> wfm
<pitti> Keybuk: 
<Keybuk> ctrl-shift-U then type the numbers
<Keybuk> it's nice that you don't need to hold down ctrl-shift afterwards
<seb128> pitti: weird, it should work in any GTK+ application
<pitti> oh, indeed, it just looks confusing
* pitti 's happily
<Keybuk> now if only we could fix Mono's lame-arse-broken keybindings, I'd be happy
<seb128> ;)
<Keybuk> (shift-delete, control-insert & shift-insert don't work)
<pitti> mvo: can you please take a look at bug 107474? when would apt.Cache()[pkg] ._lookupRecord() fail?
<ubotu> Launchpad bug 107474 in apport "[apport]  apport-retrace crashed with AssertionError in install_missing_packages()" [Undecided,Needs info]  https://launchpad.net/bugs/107474
<pitti> mvo_: can you please take a look at bug 107474? when would apt.Cache()[pkg] ._lookupRecord() fail?
<ubotu> Launchpad bug 107474 in apport "[apport]  apport-retrace crashed with AssertionError in install_missing_packages()" [Undecided,Needs info]  https://launchpad.net/bugs/107474
<mvo_> pitti: yes
<mvo_> pitti: it could fail if a) no version can be found in the cache b) if it can't find a indexfile for it. the most likely cause is that there is no version, but that is strnage because there should be at least the CurrentVer from /var/lib/dkg/status
<doko> pitti: would you mind doing the pbbuttonsd merge?
<pitti> doko: no, I wouldn't
<doko> not sure if we really want to drop the i386 packages
<pitti> doko: ... mind doing it
<pitti> doko: I'm not sure to which extend it is useful on the x86 apples
<pitti> I'll have a look
<pitti> mvo_: hm, that sounds a bit strange; would that happen if someone dpkg -i's a package?
<pitti> mvo_: NB that it is not a KeyError, apt.Cache() has an entry for it
<mvo_> pitti: that is fine, apt will look into its own lists/ dir and into the dpkg status file
<pitti> ah, so if I dpkg -i a package which is not in the lists, apt.Cache() will pick up the entry from /v/l/dpkg/status
<pitti> ?
<mvo_> pitti: yes
<pitti> but _lookupRecord() would fail in that case?
<mvo_> pitti: no, it should pickup the record from /v/l/dpkg/status
<pitti> mvo_: (that's why I added that assert, since I could not think of a situration where the function would fail)
<mvo_> pitti: let me do a bit more research
<mvo_> pitti: it happens for virtual packages too. they have no version. and it can happen if a package is denoted in dpkg status but no information can be obtained about it (e.g. old conflicts etc)
<pitti> mvo_: ah, good
<pitti> mvo_: but usually virtual packages generate a KeyError
<pitti> mvo_: but if it's a removed-but-not-purged package, that could happen
<mvo_> mvo_: yes
* pitti resolves the loop in mvo_ talking to himself :)
<mvo_> pitti: there seems to have been a amanda package but its gone now. that seems to cause the issue
<mvo_> pitti: heh :)
<pitti> mvo_: alright; thank you!
<mvo_> cheers
<carlos> mvo_: hi
<mvo_> hey carl
<mvo_> hey carlos
<carlos> mvo_: We did a merge this week to fix the problem with that huge file from ddtp
<mvo_> carlos: cool! so I can try to import that again?
<carlos> mvo_: I think it's going to be deployed today or tomorrow
<carlos> let me check, I think I just left it 'blocked' so It's just a matter of change its status once the change lands on production
<carlos> mvo_: indeed, it's blocked
<carlos> mvo_: if you don't have updates, you don't need to upload it again
<carlos> I will care to get it imported
<pitti> bdmurray, seb128, asac, mvo: FYI, with today's upload, apport drops the '[apport] ' bug title prefix and instead sets tags like apport-crash, apport-packaging, apport-bug, etc.
<carlos> mvo_: btw, do you have time to talk about the languages you are adding to ddtp ?
<seb128> pitti: cool
<carlos> like ru_RU, sv_SE and others...
<mvo_> carlos: I think I have some new stuff
<carlos> mvo_: then go ahead and upload it
<carlos> will override what is now there
<carlos> but will be still blocked
<carlos> I will unblock it once we are able to import it
<mvo_> carlos: why is it still clocked?
<carlos> mvo_: because the patch is not yet on production
<carlos> so we still have that problem
<carlos> until the code is actually deployed
<asac> pitti: cool
<pitti> cu later
<asac> cu
<mvo_> carlos: aha, ok. I misunderstood that
<mvo_> carlos: what talk about languages to import do you mean exactly? I remember you pointed me to a feature request about language-selector for fallback locales, but I do not remember a ddtp discussion
<carlos> mvo_: new topic
<carlos> mvo_: I saw you are uploading ru_RU.po, sv_SE.po files  and others like that 
<carlos> when you shouldn't...
<mvo_> I see
<mvo_> I will check that
<mvo_> that could be a problem with the import script
<carlos> mvo_: except for zh_*, pt_BR and en_* you should not use the country code at all
<carlos> at least those are the most common that are valid
<mvo_> carlos: thanks, I check it
<carlos> mvo_: ok, thanks
<cjwatson> carlos: is it likely that Rosetta will stop letting people create those at some point?
<cjwatson> there's a lot of junk like de + de_DE + de_AT etc. in various templates
<cjwatson> which I routinely filter out by eye when doing imports, but that's hardly ideal
<carlos> we already prevent them to do it by default
<carlos> automatic approvals are not handled in those cases
<carlos> and the UI doesn't allow you to create it directly, unless you navigate by hand to its URL
<carlos> but kiko wants to remove that too
<cjwatson> e.g. https://translations.launchpad.net/ubuntu/feisty/+source/debian-installer/+pots/debian-installer has en_AU, en_CA, en_NZ, en_GB, en_US
<carlos> cjwatson: usually, what is there is just because we didn't cleanup old ones
<carlos> cjwatson: well
<carlos> en_* is allowed
<cjwatson> fr and fr_FR, de and de_AT and de_DE, pt and pt_PT, es and es_ES
<cjwatson> en_* is the worst of it
<carlos> not all of them, but most of them are
<cjwatson> especially because the language packs don't currently filter out the msgid == msgstr case
<cjwatson> so it takes up an awful lot of unnecessary space on Ubuntu CDs
<cjwatson> there are a small number of cases where en_* translations are indeed useful, but they fall victim to translation completism rather badly
<carlos> cjwatson: hmm, I guess the problem there is that we are copying it with every new distro opening
<carlos> cjwatson: hmm, English should be handled different, I know
<carlos> so we only ship msgstr that are different from msgid
<carlos> but we don't have yet such feature
<carlos> about the others, I will request its removals
<carlos> mvo_: btw, now that you talked about language-selector. Should I assume that the change you did to the bug report is because it's something you should fix in language-selector?
<carlos> mvo_: just wondering whether I could reject it for Rosetta
<mvo_> carlos: its something that l-s can fix, not sure what to do with rosetta
<carlos> mvo_: well, if you can fix it quite easily with ln -s we don't need to ask for translations 
<carlos> which is a better solution
<carlos> mvo_: I'm going to close our task then
<carlos> mvo_: thanks
<mvo_> carlos: ok, thanks
<seb128> Treenaks: around? you were sort of leading the pppoe BOF at UDS, right? ;) Did you write a spec about it?
<Mithrandir> doko: is it possible to permanently turn off the OOo recovery thing?
<ogra> seb128, is there a gconf-key to adjust the startu notification deay ?
<ogra> *delay
<ogra> *startup
<seb128> ogra: what do you mean by "startup notification"?
<seb128> the delay is "until the app start"
<ogra> the clock cursor
<ogra> no, it switches back on slow systems before the app starts
<seb128> no, it runs until the app start
<ogra> not here
<seb128> that would be a bug then
<seb128> how long does it take for your app to start?
<ogra> i have about 10 seconds delay until the ff window shows up after the cursor changed back
<doko> Mithrandir: hmm, env var OOO_DISABLE_RECOVERY might do it
<doko> If set this stops the recovery dialog prompting you as OO.o starts up - instead the recovery files are just silently accumulated.
<ogra> (the classmate has a slow flashdisk)
<Mithrandir> doko: ok, thanks.
<seb128> ogra: libstartup-notification doesn't use gconf anyway, so no
<Hobbsee> hi all
<zul> cool: http://direct2dell.com/one2one/archive/2007/05/24/15994.aspx
<enrico> If, in rc.S, mountkernfs is run before mountall, how can /var/run and /var/lock be mounted properly if /var is mounted from a separate partition?
<enrico> This is on feisty, where the network doesn't come up because ifup believes that the network is already up because /var/run isn't mounted from tmpfs but persists from the previous boot
<cjwatson_> enrico: the installer ensures that /var/run and /var/lock exist on /, so that they're mounted there
<cjwatson_> and then IIRC we do a mount --move trick to preserve them when /var gets mounted
<enrico> cjwatson: I see
<enrico> cjwatson: indeed recreating those two directories fixed the problem.  You may want to add two explicit mkdirs to mountkernfs, as I'd say that when people move the /var contents to a different partition, they'd tend to remove everything left in it, without suspecting that those two directories are still needed
<cjwatson> unfortunately we can't, as / is read-only when mountkernfs runs
<cjwatson> or at least may be
<Keybuk> I actually have a cunning plan
<Keybuk> we can add the mkdirs to the umountfs script instead ;)
<Keybuk> or umountroot
<Keybuk> so if you shutdown a machine, when /var is unmounted, if the dirs don't exist then, they're created
<Keybuk> (before / is made read-only again)
<cjwatson> Keybuk: heh, neat idea
<keescook> hiya pitti
<pitti> hey keescook; early for you
<keescook> pitti: indeed.  I drove my wife to the airport early, figured I'd stay up and try to help get the kernel update sorted.  :)
<StevenK> keescook: For which release?
<keescook> StevenK: yes.  :)
<StevenK> Oh.
<pitti> keescook: I'm not sure about it either; you got my mail with the log except?
<pitti> keescook: cprov wasn't there yet when I left, let's try now
* StevenK wonders if he has another ABI bump to look forward to.
<keescook> StevenK: feisty is getting an ABI bump, but not the others.
<pitti> keescook: how come that we have so many ABI bumps now?
<StevenK> Oh feisty I can deal with.
* pitti smells non-security patches in feisty-security
<StevenK> pitti: You can smell those? :-P
<pitti> StevenK: very few security patches need to bump the ABI
<StevenK> That's a point.
<keescook> pitti: funny, I could barely find the security patches in the feisty kernel update.  I think the changelog is 2 pages long.  :)
<pitti> and TBH I'd rather avoid smuggling complicated updates into -security, without a proper SRU
<pitti> keescook: we should not accept those; they need staging in -proposed even more than the other SRUs we are doing
<keescook> yeah, I was really surprised to find that stuff.
<StevenK> Gratious kernel changes so the ABI can turn even? :-P
<ogra> Mithrandir, why do you disable readahead on the liveCD exactly ? because all ram is already taken or because squashfs preforms badly with it ?
<Mithrandir> it blew up with squashfs
<ogra> well, on which side ?
<ogra> i have plenty of ram in my classmate image, but still use squashfs in the back
<Mithrandir> "blew up" as in kernel oops
<ogra> ah, k
<ogra> but i guess you only tried with tmpfs /cow ?
<Mithrandir> tmpfs and real filesystems there, yes.
<keescook> it really confuses me to see "cow" as a meaningful file.  I (used to) use it as my "foo"-like temp file name.  :)
<mvo> siretart: do you have experience with cryptsetup? I need some help debuging a problem with luksFormat in feisty
<tkamppeter> someone has added Plug'n'Print (printer auto-install) to GNOME? See bug 116616. It seems not to recognize whether there is already a print queue.
<ubotu> Launchpad bug 116616 in gnome-cups-manager "Cups runs into a printer detection loop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116616
<slomo> mjg59: hi... you're aware that your gst-plugins-base patch for the alsa stuff breaks API and ABI? :) imho we should better wait until upstream found a good solution for this... and until now this is still under discussion
<siretart> mvo: sort-of
<mvo> siretart: in a nutshell luksFormat is not working and I wonder why. opening existing luks device works fine apparently. I get  loads of stat64("/dev/mapper/temporary-cryptsetup-7931", 0xbff94848) = -1 ENOENT (No such file or directory)
<mvo> stock feisty
<tkamppeter> no one here who knows who has added printer auto-installation to GNOME?
<siretart> mvo: I didn't see this, but it looks like a typical device node creation race, which was introduced in feisty
<mvo> siretart: wonderful, any idea what I could do to a) debug it further or b) workaround the problem?
<tkamppeter> pitti, do you know perhaps from the UDS Sevilla talk who has added printer auto-installation?
<pitti> 'added'?
<siretart> mvo: that's indeed a good question. in theory, libdevmapper (which cryptsetup hopefully uses) is patched to not create the device node
<siretart> mvo: since feisty, there should be some udev rules creating them
<siretart> to debug the problem you first need to check if that is correct, and if yes, craft udev rules to create the nodes
<tkamppeter> pitti, in Ubuntu up to Feisty nothing happened when I connected a USB printer. I had to call the printer setup tool manually.
<siretart> mvo: are you using pitti's script to format an usb stick?
<pitti> tkamppeter: right
<tkamppeter> pitti, and now (probably Gutsy or some Feisty/Gutsy mix-up) a user reports bug 116616
<ubotu> Launchpad bug 116616 in gnome-cups-manager "Cups runs into a printer detection loop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116616
<pitti> tkamppeter: and I'm not aware of anyone else working on that
<mvo> siretart: I tried both (luksformat and cryptsetup) 
<tkamppeter> Unfortunately I cannot see the screenshot of the notification window as librarian seems to be down.
<siretart> mvo: that's indeed strange.
<siretart> mvo: it looks to me that cryptsetup expects libdevmapper to create the devicenode. Keybuk changed libdevmapper to not do that anymore
<tkamppeter> Or did GNOME have plug'n'print all the time, only deactivated by default?
<siretart> mvo: so maybe he can help a bit out here
<mvo> siretart: thanks, that is quite helpful
<tritium> How is /etc/papersize set?  A new feisty install with en_US locale has a4 set, and openoffice insists that I use a4 paper, despite cups and gnome-cups-manager settings to the contrary.
<Keybuk> siretart: depends
<tritium> (contrary being letter)
<Keybuk> siretart: in edgy, devmapper created the devices nodes and udev ignored them
<Keybuk> in feisty, devmapper waited for udev to create the devices nodes (spinning in a loop)
<cjwatson> tritium: known bug, fixed in gutsy ubiquity
<cjwatson> reconfigure libpaper1 to fix it
<Keybuk> in gutsy, devmapper creates the device nodes, and udev turns it into a symlink to a device node with better permissions
<tritium> cjwatson: great.  Thanks.
<cjwatson> bug 104160
<ubotu> Launchpad bug 104160 in ubiquity "/etc/papersize incorrecly configured" [Medium,Fix released]  https://launchpad.net/bugs/104160
<Keybuk> (the symlink thing may not work if something lstat()s and checks the type *shrug* if so, it can always just make the device node)
<pitti> tkamppeter: gnome-volume-manager supports it, but we never set the 'autoprinter' gconf key
<pitti> tkamppeter: just because so far we did not have anything sensible to put in
<tritium> I wanted to know what to report a bug against, but I guess I don't have to :)
<tkamppeter> Note that OpenOffice saves printer defaults per-document, so if you continue on a document with paper size set to A4 it will continue with A4, also if you have changed the paper size option in another document in the meantime.
<tritium> tkamppeter: I rarely create openoffice documents.  I mostly open attachments in my email.
<tkamppeter> pitti, can it then simply be that the reporter of the bug turned the feature on by himself?
<tritium> My hope is to not have to change paper size to letter each time I want to print an attachment.
<pitti> tkamppeter: yes, that's likely; a gconftool -R output from the g-v-m settings will let us know
<siretart> Keybuk: uuh, that's interesting
<siretart> Keybuk: is that somewhere documented, like in UbuntuUdevRoadmap? 
<Keybuk> siretart: ?
<siretart> because it's very unconvinient to look for all these tiny bits of information from the changelogs of the various packages 
<Keybuk> it's documented in UdevMdadmEvmsGutsy or whatever that spec name is :p
<tkamppeter> tritium, also imported documents have printer option settings embedded, but I do not know what happens if all print queues of the sender's PC have different names to your print queues.
<keescook> gah! failed to start lvm on boot again.  grr
<Keybuk> udev roadmap is an ancient spec
<Keybuk> in theory, you shouldn't care what happens behind the scenes
<ssam> Hobbsee, i asked a few days ago about doing an sru for goffice to fix bug #109204 are you free to ask a few questions?
<ubotu> Launchpad bug 109204 in gnumeric "Gnumeric strange colors (purple charts) on bigendian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109204
<Keybuk> since we've tried to preserve the libdevmapper API
<Keybuk> (device node exists when the function call returns, WIN)
<tkamppeter> Perhaps you should start OOo without any document and then go into "Print" or "Print Setup" to set defaults for new or imported documents.
<siretart> Keybuk: in practice, mvo is fighting with cryptsetup to work at all! 
<tritium> tkamppeter: thanks.  They're almost always MS docs.
<Keybuk> cryptsetup has never worked
<Keybuk> IME
<Hobbsee> ssam: i'm around, yes.
<siretart> it did perfectly in dapper
<ssam> Hobbsee, :-) is a private message better than here
<Keybuk> other things didn't work in dapper
<siretart> and every new ubuntu release broke it more. I couldn't keep up with all the changes ubuntu was doing to udev and devmapper
<Keybuk> e.g. HAL seeing devices created by cryptsetup
<Keybuk> it's only being broken because we're trying to fix it
<Keybuk> and we're messing around with things we don't understand that much
<Keybuk> because the people who do understand aren't helping
<tkamppeter> tritium, note also that the document itself has a paper size (to set somewhere in the "Format" menu).
<Hobbsee> ssam: either
<tritium> tkamppeter, cjwatson: dpgk-reconfigure libpaper1, and selecting letter, worked.  MS doc attachments open up with correct printer settings now.
* Hobbsee hasnt done many SRU's, though, just knows about them
<siretart> so the solution is to revert our changes we have no clue about?
<Keybuk> no
<Keybuk> because that leaves things in a broken state
<Keybuk> cryptsetup devices wouldn't be mounted because udev/HAL/upstart would never find out about them
<Keybuk> that's what we're attempting to fix
<tkamppeter> tritium, can you report a bug against the tool for I18n configuration, setting/changing the locale should do this dpkg-reconfigure libpaper1 automatically.
<Keybuk> which requires that udev in some part knows about the device
<Keybuk> which requires that we solve the "when does mknod() get called?" race
<tritium> tkamppeter: sure, I'll do that.  Thanks for the help.
<Keybuk> and once solved, we get lots of goodies
<Keybuk> like you can then do lvm on a cryptsetup'd md device
<Keybuk> or some such madness ;)
<mvo> I would be happy to be able to do it on a regular CF card for now :) I think I give up for now, it just eats too much time
<Keybuk> mvo: have you tried in gutsy?
<mvo> Keybuk: early this week I did, let me check if I have the latest code
<tritium> tkamppeter: which is the tool for I18n configuration?
<tkamppeter> Iritium, I do not know, unfortunately, go into the "System" -> "Administration" menu to start it and then look with "ps" for its executable name.
<mvo> Keybuk: under gutsy I seem to have the same problem
<Keybuk> interesting
<Keybuk> ok
<Keybuk> let's debug!
* Keybuk puts on his debugging hat
<mvo> Keybuk: it might be something specific to cryptsetup
<Keybuk> what dm-* are in /sys/block ?
<mvo> Keybuk: I also run 2.6.20 on gutsy the newer one does not boot for me
<Keybuk> kernel shouldn't matter much
<Keybuk> also what command(s) are you running, and do you have strace of them?
<mvo> Keybuk: no dm-* in /sys/block
<mvo> Keybuk: dm-crypt, dm-mod, dm-mirror are loaded
* Keybuk leans towards "nothing wrong with devmapper and cryptsetup is just busted"
<mvo> Keybuk: I use cryptsetup luksFormat /dev/sdc1
<mvo> Keybuk: entirely possible
<mvo> :)
<Keybuk> can you strace that for me?
<mvo> Keybuk: sure. I will upload the strace in a moment. I did it earlier and noticed that "ioctl(4, DM_TABLE_LOAD, 0x80b7508)      = -1 EINVAL (Invalid argument)" looked suspicous
<Keybuk> oh
<Keybuk> are you sure you're running .20 ? :p
<Keybuk> that looks a lot like .22 :p
<mvo> uname -r tells me 2.6.20-15-generic
<Keybuk> interesting
<Keybuk> BenC: 2.6.20-15-generic has the bd_claim patch, right?
<BenC> yeah
<ogra-classmate> BenC: any news on the ralink front ?
<ogra-classmate> i got my image nearly ready
<BenC> ogra-classmate: was trying to get around to testing the tarball last night, but didn't, so today for sure
<ogra-classmate> only the suspend issue, usplash and the wlan driver are missing
<ogra-classmate> great
<BenC> I think our whole issue may have just been firmware...so I'm trying to see what to do about that
<ogra-classmate> do we ship firmware for it ?
<ogra-classmate> i didnt see any
<BenC> no, that's the problem :)
<ogra-classmate> ah
<BenC> but it also doesn't use firmware-loader, and has a hardcoded firmware location
<ogra-classmate> ouch
<mvo> Keybuk: http://people.ubuntu.com/~mvo/tmp/cryptsetup.strace
<mvo> Keybuk: the same behvaiour on three machines (two feisty, one gutsy)
<Keybuk> mvo: right
<Keybuk> that ioctl is the problem
<BenC> I can include the firmware, but I need to hack the driver to use a `uname -r` based location
<Keybuk> is sdc1 mounted?
<ogra-classmate> BenC: ah, right
<mvo> Keybuk: it is! and that is the only problem it seems. OMG
* mvo wonder why he has not noticed that earlier
<cjwatson> tritium: great
<cjwatson> tritium: language-selector is the thing tkamppeter is getting at, I think
* mvo takes a hard look at the cryptsetup code to fix that issue for the future
<lamont> pitti: ping
<pitti> hey lamont
<lamont> pitti: re texlive-bin ftbfs on ia64...
<lamont> 1) decide wether or not we want libcairo.la to be part of the development environment
<lamont> 2) either remove it from libcairo2-dev and rebuild a few things, or fix dependencies so that libcairo2-dev comes in.
<lamont> note that rebuilding a few packages on i386 will trigger this issue there, too.
<pitti> lamont: in general we want to get rid of .la files
<lamont> right
<lamont> libcairo2-dev has libcairo.la, and libcairo2-dev wasn't installed for the build
<lamont> and something (/me didn't look which) was built with a current enough libcairo2-dev
<Mithrandir> pitti: Any reason not to have something like pkgstriptranslations which cleans .la files, then we can later remove them?
<pitti> Mithrandir: seb128 knows more, but I think that there's a cdbs rule somewhere which does that
<lamont> fwiw, our bootstrapping of hppa/feisty working towards gutsy ran into this very issue
<Mithrandir> pitti: there is, but we don't use it universally
<lamont> anyway, that one isn't ia64 specific and I have an urgent boss-task, so I'm gonna disappear
<seb128> Mithrandir: that's basically what /usr/share/gnome-pkg-tools/1/rules/clean-la.mk do
<pitti> lamont: so we need to find all reverse build depends of libcairo2-dev which are build depends of texlive-bin? sorry, this entire libtool stuff is just black magic to me
<seb128> Mithrandir: I'm not sure if .la are useful for some packages though
<pitti> lamont: thank you for the heads-up!
<lamont> the trivial way is to install all the build deps and then 'grep libcairo.la /usr/lib/*.la'
<Mithrandir> seb128: they're useful for static builds.
<seb128> right
<lamont> then see what package delivered that file
<seb128> so we don't want to do it for everything
<Mithrandir> but we don't have many of those, and even fewer where something provides .la files for it.
<Mithrandir> so we have stuff like sash which depends on.. libc6.
<seb128> I've to go, bbl
<mvo> pitti: could you please have a look at #116633? a small additon to luksformat, but my perl-foo is weak
<pitti> mvo: I'm used to writing "while (<MOUNT>) { die 'bla' if /$device/; }", but if you tested your's, that's alright as well, I guess
<pitti> mvo: "$line =~ $device" actually works? I had expected /$device/ to mark it as a regexp
<ion_> 0) <MOUNT> is bad, use <$mount> (and my $mount earlier), 1) Perhaps one of $_ eq $device, /\Q$device\E/, (split)[0]  eq $device suits you better (depending on exactly what youre trying to achieve).
* pitti sighs at TIMTOWTDI
<ion_> Each of the three examples i pasted do completely different thing.
<mvo> pitti, ion_: my perl is pretty bad :) I tested it and it work for me(tm). but I'm more than happy if someone with better perl skilz can update the patch to be more perl-ish
<ion_> does
<mvo> ion_: the idea is just just check if the $device is in /proc/mounts 
<cjwatson> /\Q$device\E/ would be reasonable then
<cjwatson> \Q ... \E is a bracketing construct that escapes whatever's inside it to avoid regexp metacharacters in $device being interpreted
<ion_> If you want to compare the first column to the string $device, (split)[0]  eq $device
<ion_> You could also use Keybuks getmntent.c: getmntent -mq "$device" && echo yeah
<Burgundavia> mjg59: ping re: laptop cpu freq oddities
<mvo> ion_, cjwatson: thanks! 
<mjg59> Burgundavia: Mm?
<mvo> ion_: i updated it yet again, hope its better now
<Burgundavia> mjg59: busy trying to track down why this bug exists: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/116562
<ubotu> Launchpad bug 116562 in linux-source-2.6.22 "celeron M system refuses to scale" [Undecided,Rejected]  
<mjg59> Celerons don't scale
<Burgundavia> mjg59: my celeron m claims to and apparently does
<mjg59> How?
<Burgundavia> via the p4-clockmod module
<mjg59> p4-clockmod is a net-loss in energy consumption
<mjg59> Under almost every single possible circumstance
<Burgundavia> http://pastebin.ca/507496
<mjg59> Yeah, there's no est bit
<mjg59> So no speedstep
<mjg59> clockmod drops the frequency, but not the voltage
<Burgundavia> ahh, ok
<mjg59> Which results in a linear decrease in power consumption, but also a linear increase in time taken to do anything
<Keybuk> mvo: if you're writing it in Perl, why are you using regex and not getmntent() ?
<mvo> Keybuk: I usually stay away from perl. but I'm happy to use that instead
<Keybuk> (Perl having access to the C standard library)
<gicmo> Soo, what do I do if (after upgrading to gutsy) my fonts are HUGE, Xorg reports that I have a dpi of (142, 148) and the gnome font dialog says 145
<gicmo> but those fonts are WAY to big
<mvo> gicmo: lucky you, mine are way too small
<ion_> keybuk: I took a quick look at whether perl itself or the POSIX module provides getmntent, with no luck.
<gicmo> change to fontsize (currently 10) or tweak the dpi?
<ion_> keybuk: No luck with perldoc -q mount or mnt either. I didnt look into it any further, though.
<gicmo> mvo: haha ;-) .. well my one look like a almost blind person had set it up
<gicmo> on the macpro machine its similar for some fonts
<gicmo> but on the laptop, ugh,
<gicmo> Setting every font to 8 helps but still not ideal
<ion_> Monitors reporting their physical dimensions (so that Xorg can calculate the DPI value automatically) is great. Its a shame all monitors dont do that, and even bigger shame that some monitors lie.
<ion_> A new strip about Dell & Ubuntu at ELER. :-)
<wasabi> Keybuk: Ya remember that conversation we had at some point about evms/md/lvm and the mess of all of them, and using evms for everything including partitions... what became of that? Did it just disappear because nobody has time to look at it?
* wasabi rebooted his linux system for the first time in 2 months and once again confronted the issue.
<wasabi> evms seems to be rather silent lately... as in I guess nobdoy is working with it.
<wasabi> upstream-wise
<Keybuk> wasabi: evms doesn't even work on plain 2.6
<Keybuk> so it's a bit of a moot point really
<wasabi> Hmm. Say that again?
<Keybuk> evms doesn't even work on plain 2.6
<wasabi> I meant with more context. ;)
<wasabi> Thought evms was in linus' tree.
<Keybuk> it tries to make devmapper devices for existing block devices
<Keybuk> e.g. /dev/mapper/sda /dev/mapper/sda1 /dev/mapper/sda2 etc.
<wasabi> Yes, it does.
<Keybuk> and fails if they're mounted
<wasabi> Well, not `sda`, just `sda1`
<wasabi> it does the partition mapping in userspace using dm... and yes, it redoes it.
<Keybuk> right
<Keybuk> and breaks
<wasabi> The conversation I seem to remember having at uds-mtv was about using evms for that, and removing the in-kernel support.
<Keybuk> because sda is already claimed by the internal partition stuff
<Keybuk> and sda1 is already mounted
<Keybuk> tbh, given that evms seems undermaintained, and we have almost no expertise in it, that idea scares the shit out of me
<wasabi> Which would give the benefit of a default install using DM< and thus being able to migrate a default install to RAID1.
<wasabi> Jeff seemed to like that.
<wasabi> Yeah. It's looking pretty quiet on that front now... was just wondering what happened with that all. :0
<ion_> What benefits does evms have compared to plain md + lvm?
<wasabi> ion_: A sane UI and API.
<wasabi> Err, s/sane/single/
<Keybuk> nobody seems to know evms well enough to really own it
<wasabi> Yeah. Seems to be the case.
<wasabi> ion_: It uses md and lvm and dm. It provides one API unifying the terms container, segment, and all that jazz... and it comprehends it all for complex operations.
<ion_> Alright, thanks.
<Keybuk> the fact the evms upstream basically say "la la, don't use 2.6, or apply this patch to revert a kernel feature" is kinda worrying too
<wasabi> For instance, it shows you a file system, and lets you resize it, and considers all that is involved. 
<wasabi> Whether the FS supports it, online of offline, whether it's mounted, what hte underlying md and lvm stack looks like, and does it all in one move.
<ion_> Thats quite nice.
<Keybuk> yet is missing a "hey, evms, there's this new block device, do something with it" command <g>
<wasabi> It's nothing new, really. It's just comprehensive.
<wasabi> Keybuk: Totally. It's probably just waiting for somebody to take ownership.
<wasabi> Hell, I don't particularily care if whatever solves the problem even is EVMS... but as I see it it's a pain in the ass to deal with md and lvm seperatly.
<Keybuk> yeah
<Keybuk> I'm kinda hoping the devmapper stuff in gutsy is gonna work
<wasabi> And I think at least the concept of evms is a wonderful idea.
<wasabi> Whether the current code base is good, I don't know.
<Keybuk> evms sounds like it should be done inside the kernel :p
<wasabi> Why?
<wasabi> The basic device mapping should be done in the kernel, and is.
<wasabi> THe management API, no way.
<Keybuk> the whole md/lvm/evms thing seems inelegant to me
<Keybuk> it's layers and layers of complexity, built on the kernel block layer
<Keybuk> there should be disks
<wasabi> There are pieces which should be converted to dm, no doubt.
<Keybuk> and there should be filesystems
<wasabi> md for instance.
<Keybuk> where filesystems span/mirror/stripe across however many disks as necessary
<wasabi> zfs-style.
<Keybuk> yeah
<wasabi> zfs is interesting.
<Keybuk> that seems to be the right kind of solution
<Keybuk> merge md/dm/lvm/evms into one thing
<ion_> That would be nice.
<wasabi> Sure. Well, either way... on my systems that use pure EVMS, things run great. I remove lvm and md tools. evms does it all, and it's golden.
<Keybuk> wasabi: right, pure-evms works; but mixed evms-and-non-evms is broken because of the bd_claim stuff
<wasabi> bd_claim... new stuff to lock a block device?
<wasabi> I see.
<Keybuk> not exactly new
<Keybuk> we've historically patched it out of the kernel to support evms
<Keybuk> but the wisdom of patching out a kernel feature to support a program we barely support is questionable
<wasabi> So what is hte long term plan for this type of functionality, at least in Ubuntu?
<wasabi> That is, a nice UI for doing RAID and various LVM task.
<Fjodor> I can't seem to register a bug with launchpad. Is it in trouble, or am I doing something wrong?
<Keybuk> there is no long term plan that I'm aware of
<Keybuk> or even a short term plan
<wasabi> The problem with the current EVMS approach is a subset of users Really Likes It (me) because it is seriously usable. But with support for it waning, we're left with nothing but command line md and lvm tools.
<wasabi> Which is certainly a downgrade.
<Keybuk> the question is why these users aren't stepping up to help maintain it ...
<wasabi> That is a good question. ;)
<Fjodor> Anyways, I seem to have hit a bug with gcc-4.1.2 (as shipped with feisty), but since I can't seem to register it on launchpad, would someone be willing to do so instead on my behalf (plus possibly look into it ^-^)?
<Keybuk> Fjodor: why can't you register it?
<Keybuk> https://launchpad.net/ubuntu/feisty/+source/gcc-4.1/+filebug
<Fjodor> Keybuk: Thanks. I just seemed to hit timeout errors...
<Fjodor> Trying at this place now
<Fjodor> Keybuk: Done. Klose has requested preprocessed code in other similar bugs. Would you happen to know how I make those?
<Fjodor> bug 116648 btw
<ubotu> Launchpad bug 116648 in gcc-4.1 "internal compiler error: Illegal instruction" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116648
* Starting logfile irclogs/ubuntu-devel.log
* #ubuntu-devel  [freenode-info]  channel flooding and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<Keybuk> Fjodor: -generic is the correct kernel
<seb128> geser: there is a new kiwi upstream version in case you want to update it also ;)
<Keybuk> -386 is only for real 386s
<ogra-classmate> Keybuk: not really true ... the classmate here (900 mhz celeron) crawls badly with -generic and flies with -386
<Keybuk> that's not a real celeron, though, right?
<ogra-classmate> well, /proc/cpuinfo doesnt indicate it could be something else
<ogra-classmate> model name      : Intel(R) Celeron(R) M processor          900MHz
<ogra-classmate> cpu family      : 6
<ogra-classmate> the cache size is a joke though, cache size      : 64 KB
<geser> seb128: I'll perhaps look at it on the weekend
<seb128> cool
<Fjodor> Keybuk: I am getting some weird errors here, though. And nothing in dmesg suggesting hardware errors
<Keybuk> have you run a memory test?  you can do that from the ubuntu CD
<Fjodor> That would be worth trying. Have to get it out of the closet first though. Thanks for the suggestion
<Keybuk> (it might be a gcc bug, but it's worth testing other things while you wait for a toolchain maintainer to get to the bug)
<Fjodor> Keybuk: Indeed
<Fjodor> Thanks
<Fjodor> Still going to try the -386 kernel though. IIRC, K6-2 had some very peculiar quirks and inconsistencies that people may have been forgetting about since it's heyday
<wereHamster> can someone with wine installed please check if wine uses DT_RPATH? (I don't have ubuntu, so please don't tell me to install it and check myself ;) )
<Seveas> wereHamster, try #ubuntu-wine :)
<wereHamster> nobody there :(
<Seveas> be patient :)
<wereHamster> .. will I have more luck in #ubuntu?
<ogra-classmate> if -wine == 0 you have 1269 more chances in #ubuntu :)
<Keybuk> Mithrandir: see, this bit works
<Keybuk> wing-commander scott# hcitool scan
<Keybuk> Scanning ...
<Keybuk>         00:1A:75:92:A8:B7       Keybuk's W880i
<Keybuk> wing-commander scott# rfcomm connect rfcomm0 00:1A:75:92:A8:B7
<Keybuk> Connected /dev/rfcomm0 to 00:1A:75:92:A8:B7 on channel 1
<Keybuk> Press CTRL-C for hangup
<Keybuk> as does this bit
<Mithrandir> rfcomm bind is probably what you want.
<Mithrandir> and you need a gprs chat script and pppd peers file.
<Keybuk> right, that's where I get stuck
<Mithrandir> possibly also a username and password
<Mithrandir> I can send you mine, no idea if they'd work for you
<Keybuk> and don't I want a 3G chat script?
<Mithrandir> my phone changes from gprs to 3g and back by itself
<Mithrandir> on the fly
<wereHamster> another question.. what's the status of DT_RPATH use in ubuntu's packages? is that allowed or deprecated?
<Mithrandir> unless you have a good reason to use rpath, avoid it.
<ogra-classmate> doko: i'm not registered, cant answer pm ... see bug 116566
<ubotu> Launchpad bug 116566 in gcompris "[Sync Request]  gcompris 8.3.1-3 from Debian unstable" [Wishlist,Fix released]  https://launchpad.net/bugs/116566
<doko> ogra-classmate: ok, thanks
<Mithrandir> Keybuk: http://err.no/tmp/gprs.tar contains my gprs script and my chatscripts.  You probably need to google for the username and password for your provider.
<Mithrandir> (I can provide mine, but it won't help you one bit)
<Keybuk> it says leave blank
<Mithrandir> I think I had to put something there, BICBW
<ogra-classmate> Mithrandir: well, if he used the right country prefix he could use your login data :P
<Mithrandir> ogra-classmate: that could get expensive.
<Keybuk> 	OK		'AT+CGDCONT=1,"IP","internet","",0,0'	\
<Keybuk> what does that mean?
<ogra-classmate> heh, indeed
<ompaul> ogra-classmate, mind if I pm you - given my "status" you can reply to me
<Mithrandir> the next line tries to call the gprs profile, AIUI
<Mithrandir> *99#
<Mithrandir> my phone is a nokia and not SE, though
<ogra-classmate> dholbach: two, max three at a time, else i wont get it done with my other work
<ogra-classmate> ompaul: pm ogra after the meeting, -classmate isnt registered
<ompaul> okay
<dholbach> ogra-classmate: I'll add you to the list with two and add something that says that they should be interested in edubuntu
<ogra-classmate> (i cant answer from here atm)
<dholbach> ogra-classmate: http://wiki.ubuntu.com/MOTU/Mentoring/Mentor
<ogra-classmate> dholbach: laserjock is on my list already
<dholbach> ogra-classmate: yeah, but he's not a new contributor who wants to become MOTU
<dholbach> ogra-classmate: make sure that you have some easy tasks at hand which you can hand out to people
<ogra-classmate> right
<dholbach> I added you to the list
<ogra-classmate> thanks :)
<Keybuk> May 24 21:20:34 wing-commander chat[6234] : send (AT+CGDCONT=1,"IP","internet","",0,0^M)
<Keybuk> May 24 21:20:34 wing-commander chat[6234] : expect (OK)
<Keybuk> :-/
<pitti> Seveas: so, with 0.81 I got rid of that [apport]  prefix; I guess that's what you filter on ATM?
<Keybuk> that's as far as it gets
<pitti> Seveas: it was commonly requested to remove this and replace it with tags
<pitti> Seveas: so now it uses apport-<problemtype>, like apport-crash, apport-package, apport-kernel, etc.
<Seveas> pitti, please poke some launchpad people to add tags to the RFC822 output of bugs on http://launchpad.net/bugs/bugid_here/+text
<Seveas> otherwise I can't filter on that
<pitti> depend on what you use; python-launchpad-bugs supports tags
<pitti> s/depend/depends/
<Seveas> I use only the RFC822 format pages
<Keybuk> see, I don't think that rfcomm0 is working
<Keybuk> since minicom doesn't help
<pitti> hmm, https://bugs.launchpad.net/ubuntu/+bug/116387/+text does not seem to work here
<ubotu> Launchpad bug 116387 in Ubuntu "austrian repository mirror broken" [Undecided,In progress]  
<Seveas> it only works for /bugs/id/+text
<pitti> aah
<pitti> Seveas: sweet, I didnt' know about that; right, that needs support for tags
<Seveas> pitti, so please poke LP people :)
* pitti pokes Bjorn
<Keybuk> lesson #1
<Keybuk> bind to the right port
<Mithrandir> yeah, and occasionally, your phone will switch them around just to confuse you
<Keybuk> at+cgdcont?                                                                     
<Keybuk> +CGDCONT: 1,"IP","general.t-mobile.uk","0.0.0.0",0,0                            
<Keybuk> +CGDCONT: 2,"IP","general.t-mobile.uk","0.0.0.0",0,0           
<Keybuk> cool
<Keybuk> so the phone already has those programmed into it
<Mithrandir> yeah, they're on the sim card or something
<Riddell> infinity2: could you give back kdelibs, kdebase, kdegames (ia64), kdeartwork (ia64), kdeutils (ia64), kdeaddons (ia64) and kdegraphics?
<Riddell> or, maybe not if you're sick
<ogra> ompaul, ?
<ompaul> ogra, pm
<ogra> shoot
<bryce> yay http://www.dell.com/open/
<Burgwork> indeed
<mc44> and ubuntu.com is a dell advert :)
<bryce> I like that the laptops are $200 cheaper than the windows version
<Burgwork> I think this attempt mike actually stick
<ion_> bryce: Wow. I was afraid that theyd charge the same price.
<mc44> shame dell don't point to any ubuntu community support options but instead to their own forums
<Keybuk> ?
<ion_> Re: Dell and Ubuntu, http://geekz.co.uk/lovesraymond/wp-content/images/ep067.jpg (somewhat offtopic, sorry)
<ogra-classmate> enoseb :(
<_3oo3> can quispiam relatum mihi ut pizza peruro?
<_3oo3> EGO sum unfamiliar per is cella. Quam operor vos utor restruum.
<ion_> English, please.
<_3oo3> quis?
<ion_> Contrary to the common misconception, not everyone on the Internet speaks your native language.
<azeem> plus latin isn't very common as a native language these days
<ogra-classmate> hehe
<mc44> _3oo3 is a troll
<ogra-classmate> mc44: but unlikely the most others that seems to be an educated one :)
<mc44> ogra-classmate: we have a higher standard of troll in the ubuntu community :D
<pochu> mc44: lol :)
<ogra-classmate> right *g*
<Amaranth> dude is that latin?
<pochu> It is.
<ajmitch> as said about 5 minutes ago, yes
<ajmitch> or some form similar 
<Amaranth> if i read everything said on IRC i wouldn't have time for anything else :P
<_3oo3> Est illic a channel pro latin orator?
<azeem> Amaranth: just ignore everybody but me
<_3oo3> mc44: quis?
<Keybuk> sodomy non sapiens
<_3oo3> Keybuk: quam rudis
<_3oo3> est illic a #ubuntu-dev_ln?
<ajmitch> if you're that bored, you can translate some stuff on rosetta into latin
<pochu> Do we have latin lang-packs?
<Burgwork> likely
<ajmitch> pochu: yes
<ajmitch> the translation is rather incomplete
<ogra-classmate> only for cds , iso-latin-1
* ogra-classmate hides
<_3oo3> quare mos nemo succurro mihi?
<_3oo3> !
<Keybuk> dragostea din tei
<_3oo3> Deus Frendo vos omnis!
<ion_> Babelfish doesnt support Latin. I want my money back!
<ajmitch> amusing
#ubuntu-devel 2007-05-25
<calc> hello
<ajmitch> hi
<calc> so a close to standard config dell E1505 is $649 vs $728 but it has a intel 950 vs ati x1400
<calc> of course for linux intel is better than the ati binary only junk anyway
<calc> too bad it appears the linux stuff is hidden on dell's site like it has been for the past ~ 7-8 years
<calc> or at least i can't find it on their page without knowing the direct url to go to
<calc> hmm actually i was a bit blind its on the main page, but its a temporary main image thing
<calc> so when it goes away it won't be easily accessible anymoe
<calc> er anymore
<calc> ah i found the permanent way to access it for a user by accident
<calc> you have the use the menu bar at the top, if you select laptops from the center of the screen it doesn't mention anything about the freedos/ubuntu hardware
* calc gives dell a passing grade though it still isn't as obvious as he would like
<Burgundavia> umm, look at dell.com now
<jmg> Burgundavia: nothing on frontpage
<ajmitch> jmg: it does also redirect by country
<Burgundavia> it is part of a rotating banner
<Burgundavia> ubuntu is one of 4 options
<ajmitch> choose 'united states', and I get a big "By Popular Demand. Ubuntu Has Arrived"
<jmg> ajmitch: oic
<Burgundavia> doesn't redirect for me
<ajmitch> Burgundavia: but that's because canada is part of the US, right?
<Burgundavia> bloody aussies
<ajmitch> :)
<Burgundavia> :)
<calc> ajmitch: rotates for me in the US also
<calc> but it is accessible if you go to the top menu bar drop downs
<Burgundavia> which ones?
<calc> look for "open source" on the desktop and laptop menus at the top
<calc> oh yea you don't see those until you pick an item off the front page first
* ajmitch doubts they'll be supplying them in NZ for awhile
* calc notes he is in the US
<calc> i'll probably end up getting a gateway from best buy when they are on sale, they seem to be the best bang for the buck right now
<calc> http://www.gateway.com/retail/mt6831.php <- they put that on sale for ~ $900 USD every few weeks it seems
<StevenK> Heh, heh. Gateway. Gateway tried to come out here about year ago. Within six months they were gone.
<ajmitch> gateway bought a local pc dealer & then disappeared
<calc> hehe
<calc> the E1505N isn't too bad of a deal though
<calc> Hobbsee: hi
<Hobbsee> heya calc :)
<dholbach> GOOD MORNING!
<pitti> Good morning
<crimsun> are uploads being queued?
<pitti> crimsun: how do you mean?
<pitti> (yes, they always land in a queue until soyuz accepts them, every 5 mins)
<crimsun> oh, nm, just saw the accept.
<crimsun> pitti: I didn't think I missed the processor at :55 (.upload's timestamp is :53)
* pitti nags Riddell about bug 64695; by policy it needs to be fixed in gutsy before I accept it into feisty-updates
<nags> pitti, guess that message is not for me ;)
<pitti> nags: nope; get a nick which is not an English verb :-P
<ubotu> Launchpad bug 64695 in kdebase "If GDM is the default display manager KDE logout dialog is missing shutdown and restart options" [Medium,In progress]  https://launchpad.net/bugs/64695
<Fujitsu> Nice lag, ubotu.
<ompaul> Fujitsu, it is having other problems at the moment, I've called the doctor for ubotu 
<pitti> slomo: yay, Debian bug 425863 solves the amd64 FTBFS of texlive-bin
<ubotu> Debian bug 425863 in texlive-bin "FTBFS: teckit/libtool yields multiple definition errors" [Serious,Closed]  http://bugs.debian.org/425863
<pitti> slomo: so I'll see to fixing that .la problem  so that it'll finally build for ia64, too
<StevenK> pitti: I've got a stupid question about scribus if you've got a sec.
<pitti> StevenK: "don't ask to ask, just ask" :)
<Fujitsu> !ask
<StevenK> pitti: Bah. :-P
* Fujitsu greases the bot.
<StevenK> pitti: One of the changelog entries you added for scribus was, "Scribus.pot: Add strings from desktop file.", I'm just wondering if you can give me a cluebat?
<pitti> StevenK: ah, sure
* StevenK waits for "*whack*" :-P
<pitti> StevenK: do you know what a .pot is?
<StevenK> pitti: Sure. I managed to hack gettext support into Linda.
<StevenK> I even have scars from it.
<pitti> StevenK: so, since hoary we use langpacks for translating .desktop files
<pitti> StevenK: i. e. we add the gettext domain to the *.desktop files and have gettext translate Name/Comment, instead of (or, rather, in addition to) using the static translations in them
<dholbach> I'm sure StevenK knows what pot is ;-)
<StevenK> dholbach: Bah.
<pitti> StevenK: that's why we need the Name/Comment C strings in the POT, so that Rosetta sees them
<StevenK> pitti: Sure, I've added the X-Ubuntu-Gettext-Domain to the .desktop, it's just how to get them from the .desktop into the .pot
<pitti> StevenK: sorry; I just wanted to know at which level I start the explanation
<pitti> StevenK: that might have been one of the packages which are not intltool'ized, thus I just copied the strings manually, I think
<pitti> ideally the build system would take the desktop.in and have it in POTFILES
<pitti> so if scribus is intltoolized now, that would be indeed much better
<StevenK> No POTFILES{,.in}, so I doubt it.
<pitti> but if it does not rebuild the .pot during package build, then copying the strings manually works
<StevenK> I don't think it does, no mention of .pot in debian/rules.
<pitti> so that hasn't changed then
<Riddell> pitti: kdebase and hwdb-client updated in gutsy with patches from -updates
<pitti> Riddell: yay, thanks
<pitti> Riddell: (I already accepted them in feisty-updates)
<Riddell> thanks
<StevenK> pitti: The build system jumped from autobork to cmake, just to make the merge more interesting.
<pitti> lol
<StevenK> And the 2.4Mb patch on patches.u.c was oh so helpful, too.
<slomo> pitti: sounds good, thanks :) you might also want to sync the new texlive-bin that was uploaded yesterday
<pitti> slomo: right, that's what I meant
<slomo> pitti: ah the patch is in the new upload already?
<pitti> slomo: but before doing that I need to understand that .la problem and fix it, so that it won't FTBFS on ia64 again
<pitti> slomo: yep
<slomo> cool :)
<StevenK> pitti: So, copy over {Name,Comment,GenericName} ?
<Riddell> Mithrandir: could you give back some packages where the build-deps didn't want to install at the time?  kdelibs, kdegames (ia64), kdeartwork (ia64), kdeutils (ia64), kdeaddons (ia64) and kdegraphics 
<pitti> StevenK: yes
<StevenK> Riddell: Do you mind if I borrow^Wsteal your kaffeine merge?
<slomo> pitti: thanks for caring for this :)
<Riddell> StevenK: ask tonio about that, he's the kaffeine fanboy
<StevenK> pitti: Thanks so much for your help. :-)
<StevenK> Tonio_: Mind if I look at the kaffeine merge?
<pitti> seb128: alright, so libcairo.la is mentioned in libgnomecanvas-2.la, libnotify.la, libpangocairo-1.0.la, libgmodule-2.0.la, and libpoppler.la
<pitti> StevenK: you're welcome, thanks
<pitti> seb128: that means we need to rebuild all those source packages before texlive-bin can build?
<seb128> pitti: why?
<seb128> pitti: what is the bug?
<pitti> seb128: still the 'libcairo.la' FTBFS of texlive-bin on ia64
<Riddell> StevenK: I'm pretty sure he's already working on it, but do go ahead with any other kde package
<seb128> pitti: one of those -dev should Depends on libcairo-dev and doesn't
<pitti> seb128: ah, I see
<seb128> pitti: if you mention libcairo.la you have to use the corresponding Depends
<pitti> seb128: libgnomecanvas2-dev, for example
<StevenK> Riddell: Sure, I'll look at one once I've taken my dirty mitts off of scribus.
<seb128> pitti: right
<seb128> pitti: should we clean the .la rather than adding extra Depends?
<Tonio_> StevenK: not at all, but I have to test a patch first
<pitti> seb128: neither does libnotify-dev
<StevenK> Tonio_: Would you rather I left it?
<pitti> seb128: I think I should rather ask you this question
<Tonio_> StevenK: well the point is that I already have the package done here :)
<seb128> pitti: yeah, I'm all for cleaning the .la
<StevenK> Tonio_: Ah, yeah, well.
<seb128> pitti: I'm taking care of it now
<Tonio_> StevenK: I'm just waiting a bit for upload
<StevenK> Tonio_: Okay, what about exiv2?
<pitti> seb128: I would just like to have a working texlive on ia64, since it causes a whole lot of pacakges to ftbfs 
<seb128> pitti: easier way is to upload texlive with a Build-Depends on libcairo-dev
<pitti> seb128: hm, that would mean reintroducing ubuntu delta
<seb128> pitti: wait
<Tonio_> StevenK: nothing about that, you can work on the package if you want :)
<pitti> and texlive doesn't need cairo, so that doesn't sound justified; it only needs libpoppler
<pitti> seb128: ^ so since libpoppler.la mentions libcairo.la, but libpoppler-dev doesn't depend on libcairo-dev, should I upload a new popopler with the -dev dependency in the meantime?
<seb128> pitti: yes, do that and then give a retry to texlive
<pitti> seb128: that would sound more appropriate to me
<seb128> right, I was just looking at the build log to see where to add the missing depends
<pitti> seb128: right; I'll just sync the new version from Debian afterwards which also cares about the amd64 ftbfs
<pitti> seb128: thanks
<seb128> libpoppler-dev seems to be correct
* pitti hugs seb128
* seb128 hugs pitti
<pitti> seb128: hm, while I'm at it, shall I just merge poppler?
<StevenK> Tonio_: Great, thanks.
<seb128> pitti: yeah
<pitti> dholbach: stealing poppler merge from you
<seb128> pitti: we had a discussion with dholbach some days ago
<Riddell> that libpoppler depends on cairo is a bug, that's what libpoppler-glib is for
<seb128> pitti: Debian renamed the libs
<dholbach> pitti: fine with me
<seb128> Riddell: it's not a real Depends, that's .la being annoying
<pitti> Riddell: it's just meant to be a temporary fix until all the .la files disappear, AFAIUI
<Riddell> ok, that makes me happy :)
<seb128> Riddell: and the Depends will be added to the -dev which should not make a difference for kubuntu CD, etc
<Riddell> yep
<pitti> -Package: libpoppler-glib1
<pitti> +Package: libpoppler1-glib
<pitti> erk
<pitti> -Package: libpoppler-qt1
<pitti> +Package: libpoppler1-qt
<pitti> -Package: libpoppler-qt4-1
<pitti> +Package: libpoppler1-qt4
<pitti> seb128: so it's these three we need to do transitions for
<seb128> right
<seb128> the rdepends are small though
<pitti> yep, and it even seems we can sync poppler
<seb128> cool
<pitti> Debian doesn't install the .la file any more
<pitti> so let's do it correctly right from the start
<seb128> excellent
<pitti> only thing I wonder about is 003_glib_pkgconfig_fix.patch
<pitti> ah, that's in Debian, too, just different patch name
<carlos> seb128, pitti: Do you think is 'safe' to update to Gutsy today?
<pitti> carlos: it works for me at least
<carlos> ok
<carlos> that's enough
<pitti> I upgrade every day
<carlos> :-)
<seb128> carlos: should be fine
<carlos> thansk
<Tonio_> siretart: ping ?
<carlos> pitti: btw, next week we should be able to start exporting Gutsy language packs from Launchpad. Do you need to do anything special to handle that?
<pitti> Riddell: are you fine with the poppler library transition happening now? (lib package name changes)
<pitti> carlos: yay!
<pitti> carlos: no, just tell me, then I'll set up the cronjobs accordingly
<carlos> ok
<Riddell> pitti: no time like the present, what's the name change?
<pitti> Riddell: (rebuilds of krita, kdegraphics, and okular)
<pitti> Riddell: libpoppler1-qt -> libpoppler-qt1, libpoppler1-qt4 -> libpoppler-qt4-1
<Riddell> fine with me
<pitti> Riddell: I can care for that as well, I just want to tell you to avoid conflicts with your work
<pitti> Riddell: should be no-change rebuilds, unless you want to update any of those three ATM anyway
<Riddell> pitti: however it seems that kdegraphics needs an svn version of poppler to be able to still use poppler
<pitti> Riddell: not sure; when I sync the Debian package it would be more or less like the current gutsy one, except for the lib name change
<pitti> Riddell: i. e. if it's broken after that rebuild, it's probably broken now already
<pitti> Riddell: anyway, I won't clean up archive cruft in the next few days, so we have some time for the transition
<pitti> Riddell: oh, there's a kdebase upload in accepted; too bad that it'll miss the poppler upload :/
<Riddell> pitti: kdebase doesn't use poppler
<pitti> erm, right; sorry
<ogra> seb128, dholbach, so whats that about gnuchess being replaced by gnome-games ? what do i have to do to build apps that build-depend on gnuchess (like gcompris http://librarian.launchpad.net/7824279/buildlog_ubuntu-gutsy-i386.gcompris_8.3.1-3_FAILEDTOBUILD.txt.gz) ?
<seb128> ogra: keep using gnuchess
<seb128> ogra: that's not because gnome-games ship it that you can't use the standalone version
<ogra> hmm
<ogra> i just realized, there was never a gnuchess in main, so it never was build depended on it
<ogra> now gnome-gam,es provides it
* ogra curses about gcompris new size ... 100M for a source package is simply to much
<dholbach> mdz: can you make ubuntu-dev a member of motu please? else I can't offer mentoring for ~motu (this mail would go to universe-bugs@ and not to all ubuntu-dev members)
* dholbach is not a member of ~motu :-/
<dholbach> and best to make ~motu-council an administrator of ~motu, so we can do polls and stuff
<StevenK> ogra: Compare that to linux-restricted-modules. :-P
<mdz> dholbach: does launchpad allow a A to be a member of B when B is also a member of A?
<mdz> dholbach: I think we should describe your problems on launchpad@ and discuss the best way to fix them, rather than trying some hacks
<mdz> the bugmail thing in particular is already a hack that we've said should work differently
<StevenK> Personally, I dislike having two groups.
<dholbach> StevenK: me too
<Amaranth> glatzor: why did you reassign bug 116751 to compiz?
<ubotu> Launchpad bug 116751 in beryl-core "Upgrades of Edgy systems that used the former Beryl packages fail" [Undecided,Confirmed]  https://launchpad.net/bugs/116751
<Amaranth> ah, i see, the compiz-quinn packages might be to blame
<Amaranth> otherwise to get compiz on edgy they'd have to be using a 3rd party repo
<Fujitsu> ogra: That's why you have two CDs these days.
<Amaranth> that log really sucks, i wish it's just show the output of apt-get dist-upgrade :P
* mvo does the uucp merge
<ogra> Fujitsu, well, this release would have been the first one since edubuntu exists where we managed to get a proper package from debian which we could just sync
* Hobbsee_ waves
<Fujitsu> RUN!
* LongPointyStick attacks Fujitsu 
<Fujitsu> It's the attack of the clones.
* Fujitsu runs faster, but is still attacked.
* LongPointyStick attacks Fujitsu, and leaves him brutally murdered in the corner of #ubuntu-devel
* Hobbsee sharpens LongPointyStick 
<glatzor> Amaranth: seb128 asked me already some minutes ago.
<glatzor> Amaranth: He wanted to reassign it to beryl
<seb128> I did
<Hobbsee> ick, beryl.
* ogra hands Hobbsee a mop and a bucket and points to the corner
* mvo does tftp-hpa
* Hobbsee delegates it to seb128.
<ogra> heh
<seb128> no way
* LongPointyStick points in the direction of seb128...
<Amaranth> Dude, run
* LongPointyStick ponders where seb128 should be poked.
* seb128 hides
* ogra looks for another bucket
* Fujitsu becomes undead and consumes LongPointyStick.
* LongPointyStick searches seb128 out, and murders him brutally, and covers him in the dead Fujitsu 
<Fujitsu> Aw... :(
<LongPointyStick> Fujitsus must stay ead.
<LongPointyStick> er, dead.
<Mithrandir> LongPointyStick: stop killing people!
<LongPointyStick> why?
<Fujitsu> We are violent tonight, aren't we?
<Fujitsu> LongPointyStick: We have few enough human resources as it is.
* LongPointyStick abducts Simira, adn brings her to australia.
<Fujitsu> Ooooooh, nasty.
<LongPointyStick> see, not killing people.
<LongPointyStick> not everyone, anyway.
* Fujitsu 's soul departs to haunt #ubuntu-motu forever, away from the terror that is LongPointyStick.
<pitti> Mithrandir: libhildon1-0-dbg_1.0.5-1ubuntu5_i386.deb is empty; to fix that, maybe you can remove it altogether? We don't need -dbg packages after all
<elkbuntu> whelp.. good to see the CoC as effective as usual in here :
<LongPointyStick> Nowhere is safe!
<pitti> Mithrandir: and while you are at it, could you please rename libhildon1-0 to libhildon-1-0 to match the soname?
<seb128> -1-0 is ugly
* Hobbsee glances at https://bugs.launchpad.net/ubuntu/+bug/116789
<ubotu> Launchpad bug 116789 in Ubuntu "ubuntu-users@lists.ubuntu.com mailing list is not working" [Undecided,Unconfirmed]  
<Mithrandir> seb128: I blame upstream.
<seb128> why do they need to version the name in the first place?
<Hobbsee> looks suspiciously pebkac - but it's an interesting thing to report in a place that's bugs in ubuntu
<Mithrandir> pitti: I'm not sure I want to drop -dbg, since I'd like to avoid diverging too much from upstream
<pitti> Mithrandir: fine for me, but the package should not be empty
<mvo> Keybuk: I take bpalogin if you don't mind (from the merges list)
<Mithrandir> pitti: that I can agree with. :-)
<pitti> Mithrandir: if you want to keep the name, I'll accept them; if you want to match the soname (prefered IMHO), I'll reject the current binaries
<Mithrandir> I'll see if I can get upstream to change the soname, and if not, I'll change the package name.
<pitti> Mithrandir: alright, thanks
<mvo> Riddell: I took your xdg-utils merge
<Keybuk> mvo: sure
* mvo takes toshset and dwells in some fond memories for that package
<Riddell> mvo: thanks
* Hobbsee_ waits for the ghost to kick in...
<Hobbsee> there we go.
<pitti> Hobbsee: /ns ghost Hobbsee <yourpassword>
<Hobbsee> pitti: i use it so often that nwo i just use /ghost
<Hobbsee> :)
<Keybuk> Amaranth: ping?
<Amaranth> Keybuk: pong
<Keybuk> Amaranth: curious about the new compiz "git" version
<Keybuk> is this still a pre-beryl-merge thing?
<Amaranth> compiz isn't merging :)
<Amaranth> the 'merge' is compiz-extra and beryl
<Riddell> Mithrandir: could you give back kdeedu, it should be buildable now
<Amaranth> since the compiz-extra guys had like 3 original plugins and all the beryl plugins ported to compiz
<Keybuk> right, but that merge depends on some compiz things in git, no?
<Amaranth> it does
<Keybuk> is that in this git package?
<Amaranth> this should have what they need, yes
<Keybuk> when do we expect compiz-extra to contain the beryl guys stuff?
<Mithrandir> Riddell: given-back
<Riddell> thanks
<bonii> I am using Acer Aspire 1641 NWLMI laptop with Feisty. It has got acerhk module loaded but though the wireless hardware switch works for on and off its led doesnt glow. Can someone help me out. I was pointed to this channel from #ubuntu
<Amaranth> Keybuk: compiz-extra can probably be removed from the archive at this point
<Amaranth> Keybuk: afaik there are no plans to maintain a 'compiz-extra' tarball any longer
<Keybuk> ok
<seb128> Amaranth: is the current compiz-extra compatible with the new compiz or should I remove it now?
<Keybuk> so how do I get the beryl plugins for compiz?
<Amaranth> seb128: it's not
<dholbach> mdz: I'm just trying to solve the universe-bugs@ thing differently. You seem to be ubuntu-bugs@ admin - is lists.u.c just slow or do you have to approve every subscriber to the list manually?
<Amaranth> seb128: my compiz-core package has a Breaks in there for it
<mdz> dholbach: that list is open subscription
<mdz> dholbach: I have no idea if any part of the process is slow
<dholbach> mdz: don't worry - I'll try to be patient and wait then :)
<seb128> Amaranth: will you update compiz-extra with the new plugins or get a new package?
<gnomefreak> bonii: please join #ubuntu and ask your question.
<Amaranth> seb128: new set of packages from the beryl guys
<seb128> k, I'll remove compiz-extra then
<Fujitsu> Yay! Good to see that bug source disappear for now.
<Amaranth> hehe
<bonii> gnomefreak: That is what I had done but there someone pointed me here saying it might be a module problem and the developers may help me out
<gnomefreak> not in the last 4 hours
<Keybuk> Amaranth: when do we expect the new set of packages?
<gnomefreak> bonii: they shouldnt have sent you here for support anyway
<Amaranth> Keybuk: i dunno, whenever they do a release
<Amaranth> or at least have a working build system
<Keybuk> I'll talk to Robert later and find out, I guess :)
<seb128> Amaranth: compiz-extra removed
<Amaranth> i don't really want to package 0.0.0+git20070525 so i'm hoping they do a release soon :)
<Keybuk> any particular reason?
<seb128> I'm fine packaging git ;)
<seb128> s/fine/ok
<seb128> if that's usuable
<maswan> Anyone have the 2.6.15-28.53 linux-image[s]  still around? I can't seem to find them anywhere in the archive[s] , is there some special archive somewhere perhaps?
<seb128> maswan: launchpad library
<Amaranth> well, they don't even have a working build system yet so that's not much of a concern right now
<Amaranth> but mostly just because i don't know what to name the packages :)
<Fujitsu> launchpad.net/ubuntu/+source/linux-source-2.6.22/2.6.15-28.53, probably.
<Amaranth> i know i'm not calling them compcomm-plugins-foo
<Keybuk> compcomm?
<maswan> thanks, awesome. hopefully we can go back to something that works for the time being then
<Keybuk> compiz-beryl-plugins?
<Fujitsu> Except for the .22 being wrong.
<Amaranth> Keybuk: that's the temporary name
<Amaranth> it's not beryl anymore either :)
<Amaranth> i was thinking renaming compiz-plugins to compiz-plugins-core and calling the compcomm stuff compiz-plugins-foo
<Amaranth> supposedly eventually non-essential plugins will move from compiz to the compcomm guys so the name will eventually make sense :)
<Keybuk> *nods*
<Keybuk> I'd still rather we had some package, with a temporary name, containing some plugins sooner
<Keybuk> and sorted out issues like the name later
<Keybuk> since that way we're spending more of the release cycle testing, debugging and fixing problems
<Keybuk> and less waiting on a plugin drop
<maswan> Fujitsu: well, that was quite easy to guess when I got a 404. :) Found it, hopefully we'll have a kernel again that doesn't fall over every 5 minutes.
<cjwatson> maswan: bug #?
<maswan> cjwatson: Working on it
<Amaranth> Keybuk: as soon as they have a working build system and such i'll make packages
<Keybuk> Amaranth: I'm getting white boxes where there should be drop-shadows
<Keybuk> any ideas?
<Amaranth> heh, seems like only nvidia doesn't get that now
<Amaranth> i have no idea what's wrong, the hacky fix we had in feisty is still there
<maswan> cjwatson: It happened to be a resonably important production system, so workaround first, bug reports later. :)
<maswan> cjwatson: Now I'm just waiting for launchpad to unbreak, and I'll get you a bug #. :)
<seb128> Keybuk: should we use the milestone for gutsy bugs rather than abusing critical?
<pitti> seb128: I'd love to, except that the gutsy milestone was removed for some reason
<pitti> seb128: we probably should create gutsy tasks
<seb128> pitti: get a driver adding it back? ;)
<seb128> no we shouldn't
<seb128> tasks are for backport
* pitti agrees
<seb128> pitti: I think we had no gutsy milestone
<seb128> we just need to get one created
<pitti> seb128: we did have one, it was renamed 'obsolete' and then removed
<seb128> pitti: hum, weird, what happened to bugs using it?
<Keybuk> seb128: we've been told we can't use it for this
<seb128> !?
<Keybuk> so bug importance will have to do for now
<seb128> heh
<seb128> how come we can use milestone?
<seb128> s/can/can't
* mvo wondered that too
<seb128> I'll have to use a note on my desktop to keep track of bugs now? that's plainly stupid ....
<Hobbsee> seb128: it's progress - means you cant have unlimited bugs to keep progress of.
<pitti> the purpose of milestones is different from the purpose of tasks, at least in my interpretation
<pitti> tasks -> version tracking; milestones -> release management
<seb128> tasks are for backport
* Keybuk doesn't know
<Keybuk> it's confused the buggery out of me :p
<seb128> there is not point to use a gutsy task since bugs apply to gutsy by default
<pitti> seb128: well, 'version tracking' for bugs we want to backport, yes
<Keybuk> we weren't using it the way the Malone people thought we should be, or something
<seb128> Keybuk: who decided the change? can we discuss that somewhere?
<seb128> well, the normal way would be to provide us an another way before removing the one we are using
<Keybuk> *shrug* indeed
<Keybuk> I really don't know the full story though
<seb128> Keybuk: who knows?
<Keybuk> the summary I have is "use Importance for now"
<seb128> I don't want to use importance
<Keybuk> pitti knows more than I?
<seb128> I've plenty of polish bugs I want to look at for gutsy
<seb128> I'll no mark hundred of bugs critical just to keep them on my list
* mvo (ab)uses "later" for this currently, but he really wants a 7.10 milestone
<persia> A tag might work, if you just want a list of bugs, but that is probably a different type of Malone abuse.
<pitti> persia: it would be even worse, since less structure
<seb128> and anybody can abuse from tags
<seb128> where milestone has access control
<Keybuk> the access control for milestone is ubuntu-drivers, no?
<seb128> no
<Keybuk> the problem with the milestone is it's what the release manager uses
<pitti> it was broader, not sure how broad; ubuntu-qa maybe?
<seb128> I think it's ubuntu-core-dev
<seb128> might be qa
<Keybuk> so if anyone can post to the milestone, then the release manager suddenly has 1,000 "must be fixed for release" bugs
<pitti> all I know is 'it worked for me'
<pitti> Keybuk: let's as Mithrandir, but I don't think that happened so far
<seb128> Keybuk: well, it used to be that only trusted people could set it
<pitti> to the contrary, we were often encouraged to milestone bugs
* pitti apologizes to Keybuk for complaining to him; wrong target
<seb128> the "must be fixed" is important bugs milestoned
<Keybuk> seb128: we defined that really late in the cycle as a hack around the problem that anyone could target to a milestone
<seb128> I've plenty of low importance bugs milestone as my "todo for next stable"
<seb128> Keybuk: I don't think it was an open setting, it has always been restricted
<seb128> maybe to ubuntu-qa which is too much
<Mithrandir> Keybuk: while it has been abused slightly in the past for non-rc items, it's always been my position that I'd much rather have too many bugs nominated and have them turned down than miss important bugs.
<seb128> but it was not open
<Keybuk> Mithrandir: do you know where the ubuntu-7.10 milestone went, ooi?
<Mithrandir> we ended up defining critical + high + milestone as RC, where critical + milestone is "will hold up", high + milestone as "fix or document workaround".
<Mithrandir> Keybuk: no, I thought I added one, but I can't have, or launchpad have turned forgetful.  I can't see the knob I've used to add them in the past, so I wonder if that's linked to -drivers.
<pitti> Mithrandir: I'm 100% sure that there had been an ubuntu-7.10 milestone in the past
<Mithrandir> then LP ate it
<pitti> since I added it to a few bugs, and now they have a tag 'ubuntu-obsolete-milestone'
<seb128> I've asked on #launchpad
<Mithrandir> even more so since I haven't been able to find a way to remove milestones in the past.
<Keybuk> the interesting thing in this period is defining release criticalness on a per-feature basis
<Keybuk> Critical Milestoned bugs on a package before FF should mean that if the bug isn't fixed, the feature is dropped
<Hobbsee> Mithrandir: then someone needs to feed launchpad more often!
<Mithrandir> Keybuk: maybe not as categorically, but as a rule of thumb, yes.  We expect new features to have bugs, even serious ones.
<Keybuk> right, I'm trying to define a way to make certain bugs highly visible
<Keybuk> the metacity->compiz migration bugs, specifically
<seb128> high importance, ubuntu-7.10 milestone
<Keybuk> because these are blockers for switching people from one to the other
<Keybuk> seb128: why high and not critical
<Mithrandir> from the rumours I've heard, sabdfl doesn't like how we're using milestones.  I'm not sure how he wants them to be used, though.
<Keybuk> high has other things mixed in, and Malone doesn't show the milestone in the compiz bugs list
<seb128> I'm fine with critical if that's really the importance and not a way to workaround the lack of milestone
<Keybuk> fundamentally I want to be able to show Mark a list of bugs when he asks how's it going
<Keybuk> and they should be obvious
<seb128> I still want the milestone to list bugs I've to work for gutsy
<seb128> s/work/work on
<Keybuk> yeah, I use milestone for that myself for Upstart :p
<seb128> Mithrandir: well, I'm fine not using milestone if there is an another way to list bugs I want to work on for gutsy
<Keybuk> personal milestones/tags? :p
<pitti> doko: wvstreams accepted; will you care about the soname transition?
<Keybuk> I don't think LP can list "all bugs assigned to me and tagged FOO though?"
<seb128> Keybuk: tag are open
<seb128> anybody can change them
<seb128> and I don't want random user changing my TODO :p
<carlos> seb128, pitti: Fonts are quite small with Gutsy... Do you have the same problem?
* pitti looks at the NEW queue and blinks
<pitti>   210842 | S- | iceape               | 1.1.1+u1-0ubuntu1    | nine days
<pitti>          | * iceape/1.1.1+u1-0ubuntu1 Component: main Section: net
<pitti> I thought we didn't want that?
* pitti blacklists
<seb128> carlos: yes, g-s-d is looking at the screen DPI now
<Mithrandir> pitti: asac wants it, in universe.
<seb128> pitti: I think we want
<pitti> carlos: yes, I had; I just increased their size a little and then forgot about it
<Mithrandir> Keybuk: afaik it can.
<seb128> pitti: the mozilla team want all of them to universe IIRC
<pitti> Mithrandir: erk @ even more firefox copies without security updates
<carlos> so it's supposed to use the right value now?
<pitti> asac: what's the point of iceape?
<seb128> carlos: we will make that better, not sure what is right way for now though
<seb128> carlos: yes
<Mithrandir> pitti: indeed.
<carlos> ok
<maswan> cjwatson: 116815
<Mithrandir> Keybuk: I'm wondering if it's really a usecase for bugs that depend on other bugs.
<Mithrandir> Keybuk: like "blocked" in the debian bts.
<Keybuk> Mithrandir: or a use case to have "custom bug lists"
<Keybuk> and define milestones using them
<Mithrandir> or nicknames for lists of bugs.
<Keybuk> so anyone can create a bug list, and nominate the person/team who can accept bugs into the list
<Keybuk> anyone can propose to any list
<Keybuk> release could have milestone lists owned by the RM
* pitti empties binary NEW, yay
<Keybuk> individuals and teams could have their own lists of interesting bugs
<Keybuk> etc.
<Mithrandir> Keybuk: yes, and you can have more than one list, and list of lists.
<Mithrandir> so I could have an uber-list of all my -archive and -mobile bugs, but I could also have those separate, as well as any casper bugs, any pkg-config bugs, etc.
<Keybuk> yeah
<Keybuk> and I could have a personal todo
<ajmitch> yay, waiting for root fs
<Keybuk> seb128: btw, feel free to renominate these bugs any way you want - just as long as there's an LP url I can use to see them all :p
<asac> pitti: what point do you want to know :)
<pitti> asac: why do we need even more copies of mozilla code in universe which more or less just differ in the name and will never get security updates?
<Hobbsee> pitti: testing?
<Hobbsee> MOTU council would probably vote them out, though
<asac> pitti: more or less i want it to mentor mozillateam contributors on packaging mozilla applications
<ajmitch> no wonder, I no longer have the right lvm stuff in initramfs, but evms is there & gives different device names
* pitti mumbles something about PPA
<asac> pitti: we don't have seamonkey
<asac> so what do you mean with "just differ in name" 
<pitti> asac: ah, right, the iceape was the 'old' complete suite, not firefox
<asac> pitti: exactly
<pitti> asac: well, the argument of 'unmaintained copies' still holds, but if you wish...
<asac> pitti: further the iceapps are the perfect playground to test things like building against xulrunner et al
<mvo> infinity: I take your scim-chewing merge if you don't mind
<cjwatson> how badly do we reckon livefs builds will fail today?
<Keybuk> Amaranth: hmm, plane isn't working properly for me
<StevenK> How badly did they fail last time?
<cjwatson> hmm, http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html suggests it won't be pretty :)
<cjwatson> StevenK: not at all, since that was the final build for feisty
<Keybuk> Amaranth: I have 12 desktops, configured in 3 rows, and the switcher shows them properly
<Fujitsu> Is this the first gutsy run, or has something particularly special happened?
<cjwatson> the first run
<Keybuk> Amaranth: but I can only use Ctrl+Alt+Up and Ctrl+Alt+Down to move between two of them
<Keybuk> Amaranth: and the switcher doesn't update
<cjwatson> hmm, probably need to upload ubuntu-meta
<Amaranth> Keybuk: because you have 2x2 viewports and 12 workspaces
<Keybuk> Amaranth: this means nothing to me ...
<Keybuk> Amaranth: in metacity, I had 12 desktops in 3 rows
<StevenK> cjwatson: When was that generated? kdepim ought to be fixed.
<Keybuk> Amaranth: that wasn't migrated properly to compiz, but I could set the number of desktops again in the switcher
<Amaranth> Keybuk: you want to change number_of_desktops to 1 and change the hsize and vsize to 4x3
<cjwatson> StevenK: there's a timestamp at the top
<Keybuk> Amaranth: ?
<StevenK> So there is.
<Keybuk> Amaranth: the switcher doesn't offer those settings
<Amaranth> Keybuk: the switcher applet needs to be patched to know about viewports
<StevenK> Perhaps I need to order glasses.
<Amaranth> this is in gcon
<Amaranth> err, gconf
<Keybuk> Amaranth: which keys do I need to change?
<Amaranth> number_of_desktops, hsize, and vsize
<Keybuk> ok
<Keybuk> interesting
<StevenK> cjwatson: a kdepim upload (4:3.5.7-1ubuntu2) was uploaded 21 hours ago, and ought to fix some of those problems.
<cjwatson> StevenK: if it fixes it, it hasn't built *shrug*
<StevenK> According to LP, it has.
<cjwatson> britney does not have a habit of being wrong
<cjwatson> it's almost invariably the packages
<StevenK> Hrm. Binary NEW, maybe.
* Hobbsee checks for kdepim breakage
<Keybuk> Amaranth: ah yes, that's much better
<cjwatson> no kdepim in NEW
<Hobbsee> bah.  not too much kde stuff there.
<Hobbsee> cjwatson: no, it's uploaded now.  some of the kde stuff was given back too
<StevenK> I daresay kdebase, kubuntu-meta, and kdepim are all related.
<cjwatson> bear in mind that it is often not the fault of the uninstallable package
<Hobbsee> StevenK: kubuntu-meta isnt
<cjwatson> networkstatus-dev (the uninstallable in question) is timestamped 27 March
<Hobbsee> cjwatson: can you tell me when that'll be run again?
<Hobbsee> (yay for being mid kde-change)
<cjwatson> Hobbsee: hourly; see the timestamp at the top
<Hobbsee> cjwatson: ah, sorry, thanks.
* StevenK mades a note to kill one of his uni group, and looks at one of the uninstallables.
<Keybuk> Amaranth: also 0.5 still betrays the "windows mapped before compiz are invisible" bug
<cjwatson> it's running at the moment actually
* Hobbsee calculates...an hour and a half since some of kde was given back.  probably not time for it to build yet, and run the tool.
<cjwatson> a publication cycle is needed there too
<cjwatson> if it's in progress, don't worry about it
<Hobbsee> exactly
<StevenK> This guy seems to be one of those people who has the mistaken assumption that all web pages need to look great 640x480 and no other size.
<Hobbsee> some of it is, i'm not quite sure how much
<Keybuk> is there some composite-related option needed on intel chips
<Keybuk> EXAA or something?
<Hobbsee> not for 965, iirc
<cjwatson> easiest way to diagnose britney problems is to debootstrap a gutsy chroot and try 'apt-get install <uninstallable>'
* Keybuk has 945
* Fujitsu has a 915, and doesn't need anything special.
<Keybuk> just seeing if there's a way to fix the white box issue
<ogra-classmate> Keybuk: which driver are you using?
<Keybuk> intel
<Hobbsee> cjwatson: looks like networkstatus-dev is an obsolete binary from kdepim
<ogra-classmate> i noticed in feiswty the -intel driver doesnt work on the 915 of the classmate, havent tried the gutsy one yet though
<cjwatson> Hobbsee: ok, it can safely be ignored in the uninstallables list then; it'll get hoovered up at some point
<Hobbsee> cjwatson: cool - wasnt sure if you wanted to do the hoovering now :)
<cjwatson> pitti: sexy-python needs an inclusion report; gnome-app-install uses it now
<pitti> yup, that doesn't sound too scary
<ogra-classmate> Keybuk: the 810 doesnt have the whitebox issue for me, but you need the resolution tool from universe
<Lure> Hobbsee: networkstatus-dev is needed for building knetworkmanager
<ogra-classmate> *i810
<Lure> Hobbsee: I suspect something was lost during 3.5.7 switch
<Hobbsee> Lure: it has no source...or my apt-cache is buggered.
<Hobbsee> Lure: debian doesnt seem to know about it either
<Lure> Hobbsee: Tonio_ has added this in feisty
<Lure> Hobbsee: yes, because they do not care about it
<Hobbsee> ah
* Hobbsee wonders if and how she missed it, then.
<Lure> Hobbsee: this was part of feisty specs
<Lure> Hobbsee: see https://wiki.ubuntu.com/KubuntuFeistyNetworking
<Hobbsee> Lure: doesnt mention -dev, but OK
<Lure> Hobbsee: it was part of kdepim change Tonio_ did
<Lure> Hobbsee: it was new heaer files needed to compile knetworkmanager
<Hobbsee> i'm saying i wonder how it got missed in the merge.
<Hobbsee> (not how it origianlly got there)
<Keybuk> ogra-classmate: which version of compiz?
<otavio> Hello folks. I'm preparing a release of laptop-detect to Debian but I'd like to know if the laptop-detect-udeb is being use by Ubuntu Installer? (it's not on d-i)
<doko> pitti: not today
<cjwatson> otavio: no, it's not
<pitti> doko: no, not that urgent, just eventually
<cjwatson> (it's in universe, so can't be)
<pitti> mr_pouit: erk @ install/disksearch:: rule of your disksearch source package
<pitti> mr_pouit: (similarly, debian/dirs); I recommend to intltoolize that package, so that you get some sane 'upstream' rules for msgfmt'ing and installing po/gmo files
<pitti> mr_pouit: please also clean the orig.tar.gz a bit (*.gmo and *.pyc)
<ogra-classmate> Keybuk: feisty final
<cjwatson> The following packages have unmet dependencies:
<cjwatson> The following packages have unmet dependen  python-qt4: Depends: python-sip4 (< 4.6) but 4.6-1ubuntu1 is to be installed
<cjwatson> KDE folks, what's up with that?
<StevenK> Oh bugger!
<StevenK> I merged python-sip4, so I'll deal with -qt4.
<cjwatson> thanks
<siretart> I just got two mails from archive@ubuntu.com: the first one is 'Accepted boxbackup', the 2nd one is 'boxbackup rejected'
<Riddell> StevenK: thanks, it should just need a sync from Debian
<siretart> is this something I need to worry about? (it is a sync from debian)
<StevenK> Riddell: Right, I'll check properly after the MOTU meeting.
* Hobbsee clearly needs a highlight on "kde folks"
<StevenK> Heh
<otavio> cjwatson: ok, good. I'll drop the udeb then
<Hobbsee> right, ignoring kdebluetooth-irmcsync, kdegraphics-kfile-plugins, krita needs fixing for the poppler stuff, networkstatus-dev needs fixing due to a botched merge (yay, me), pyqt4 we know about, as well as the rdeps, and sparc kdelibs we're ignoring
<Hobbsee> not too much to action there, at least :)
<Hobbsee> pitti: can we borrow you in -meeting please?
<allee> Hobbsee: fwiw: kdebluetooth-irmcsync is gone in kdelbuetooth-dbus-integration branch
<pitti> joined
<Hobbsee> allee: right, so it's an old binary, and Tonio_ hasnt done the merge yet?
<Hobbsee> pitti: thanks
<allee> Hobbsee: there's only a kdelbuetooth-dbus-integration in svn. No release yet.  I've made some experimental debs on my disk. That's all
<Hobbsee> allee: ahhh, gotcha.
<Keybuk> ogra-classmate: that's fine for me
<Keybuk> ogra-classmate: it's only today's git compiz that has the white box issue
<pitti> Fujitsu: please fix sixpack-bibtex.orig.tar.gz to include a COPYING file; I accept the source new because the current sixpack package does not have either, but it's imperative that it gets fixed
<Fujitsu> pitti: OK, I'll try to whip one up.
<pitti> Fujitsu: just take it from /usr/share/common-licenses and check that the files are actuually GPLed :)
<Fujitsu> Yeah, the last bit is generally the problem.
<pitti> Fujitsu: hm, the 'other' sixpack has the very same problem; very confusing
<Fujitsu> Heheh, I love these ambiguities.
<saispo> BenC: ping ?
<BenC> saispo: pong
<saispo> hi :)
<saispo> kernel source for feisty are not accessible with git on kernel.org now ?
<pitti> yay, texlive-bin built on all arches!
* pitti bounces
* StevenK giggles
<seb128> pitti: I'm remove-package evince-gtk
<Keybuk> saispo: http://kernel.ubuntu.com/git
<seb128> pitti: evince does multibuild now with a gtk variant
<pitti> seb128: ++
<pitti> seb128: oooh, great!
<seb128> ;)
* pitti -> lunch, bbl
* seb128 work breaks as well
<pkl_> saispo: git is now on kernel.ubuntu.com, git-clone git://kernel.ubuntu.com/<project>, for feisty, replace <project> with ubuntu/ubuntu-feisty.git
<robertj> someone on the payroll really ought to get in touch with dell to have them add a "tell me more" (or whatever dell calls it) link to the canonical support offerings that tells you what the difference is between basic and standard support
<robertj> the information is there on the first page, but usually they have links inside the customization area for each machine that fill you in on details
<robertj> apparently the preferred term is "Help Me Choose", you can see it on the pages before and after maintanance selection when customizing a machine
<muxecoid> Help me pick an IDE for C/C++ please. My reqs for IDE: 1. GUI C, C++ support. 1.1. Method/function trees. 1.2. Autocompletion offering completion options of proper type. 2. Automatically generates configure scripts for make (maybe jam?). 2.1. Create tarballs easily. 2.2. Adding non-source files to the project. 3. GUI for Revision control support. 3.1. Store different versions/branches in different dirs and switch easily between them. 3.2. GUI for c
<saispo> BenC, pkl_, Keybuk : ok, big thanks :)
<maswan> BenC: I can only give you a dmesg of .53 running on that machine, still interested?
<Hobbsee> muxecoid: #ubuntu
<Hobbsee> muxecoid: please see the /topic
<BenC> maswan: really need dmesg from the new one to see if there's some incriminating evidence before the crashes, but .53 is a good start
<muxecoid> Sorry, I just want to know what IDe is used by ubuntu developers :)
<maswan> BenC: I can give you that today, I can try to reproduce this under artifical load on .55 on monday.
<Hobbsee> muxecoid: vi, emacs.
<BenC> maswan: thanks
<muxecoid> Thanks.
<Fujitsu> Hobbsee: Good one!
* Hobbsee headdesks
<thom> ed would've been a better answer
<Hobbsee> haha
<StevenK> Hah
<Hobbsee> "thou shalt read the topic, or thou shalt have an appointment with the pointy stick"
<StevenK> Is that the offical motto of ubuntu-ops?
<Hobbsee> nah...
<Hobbsee> i dont think we have one
<Hobbsee> besides, i'm not on the council anymore.
<Hobbsee> not even proposed for it :)
<ogra-classmate> BenC: i'm online with the ralink ;)
<robertj> when a spec is marked review, who is it that actually does the review?
<Hobbsee> smurf and co, i believe
<robertj> just wanted to make sure it magically happened and I wasn't supposed to poke someone
<Fujitsu> It depends if it's a slightly sane (probably targetted) spec.
<Hobbsee> not sure
<robertj> Fujitsu: Proposed for gusty, low priority
<Hobbsee> robertj: are you writing it?
<Hobbsee> s/writign/implementing/
<robertj> Hobbsee: maybeish
<robertj> Hobbsee: there is some gtk+ stuff I can do it will just take time but I have a possible volunteer
<Hobbsee> ah
<robertj> the other is changes to the pam stack and adding reqs to ubuntu-minimal
<persia> Mithrandir: please give back gmsh on ia64 (thanks pitti)
<Hobbsee> i suspect you can just implement it without approval, but dont quote me on that
<robertj> Hobbsee: apart from the gtk+ stuff there isn't really anything to implement I don't think. It should be like a 3 line diff
<Hobbsee> cool
<robertj> https://wiki.ubuntu.com/SimpleSambaIntegrationSpec
<Hobbsee> i'd suggest just doing it, then
<pitti> persia: due to texlive?
<persia> pitti: Yes.
<pitti> Mithrandir: please hold on with give-backs on ia64 due to texlive; it's not yet in the arhcive
* persia apologises profusely for excessive excitement
<pitti> persia: curious; libkpathsea 2007-9 is there for ia64, but not texlive-base-bin
<Fujitsu> Binary NEW?
<pitti> ah, no
<pitti> it's in universe on ia64
* pitti moves
<pitti> done
<BenC> ogra-classmate: firmware working?
<pitti> BenC: good morning
<BenC> pitti: Hey
<pitti> BenC: ISTR that we still need to talk about kernel crashes and apport?
* robertj files #116846
<robertj> <ahem> bug #116846
<ubotu> Launchpad bug 116846 in pam "patch to add directory inclusion for pam config file" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116846
<ompaul> I will be back as soon as I can be
<ompaul> woops wrong window
<otavio> cjwatson: Hi. Is possible to sync laptop-detect with the new sid one?
<ogra-classmate> BenC: compioled from the latest serialmonkey CVS hourly tarball ... no NM support, but works
<BenC> pitti: yeah...the current situation is that pulling vmcore works...but it's a map of the entire memory area, so a command needs to be run on it to shrink it down (will be included in kexec-tools, so if vmcore is there, so should this command)
<cjwatson> otavio: it'll go onto the merge list automatically
<ogra-classmate> btw compiling stuff on the classmate isnt as bad as you would expect :)
<cjwatson> otavio: (http://merges.ubuntu.com/main.html)
<ogra-classmate> BenC: the Makefile from the ralink tarball was broken somehow
<pitti> BenC: IIRC that vmcore file should be picked up by the apport init script (maybe indirectly) and be converted to a proper apport file, right?
<cjwatson> otavio: if all the changes have been incorporated, whoever looks at it will verify that and ask for a sync
<ogra-classmate> moving the firmware to /etc/Wireless/... didnt helpp either
<otavio> cjwatson: AFAIK they all were merge
<otavio> cjwatson: if something is missing I'd like to push on it to avoid diverting without reason
<BenC> pitti: right, but unless you want a 1G file in attachment, it's useless as-is :)
<pitti> BenC: right; I mean, it is no problem to call any script during that process
<BenC> pitti: apport should pick up that it's there, and if the user wants to include it with the bug report, then apport should preprocess it with a command to bring it down to something reasonable like 70Megs
<pitti> BenC: well, it'll slow down boot a bit, but *shrug*
<BenC> pitti: I'll email you details today
<pitti> BenC: ok, thanks; I'll think about it when I understand the details better
<cjwatson> otavio: sure, understood; somebody will look at it once the new version is on the merge list
<pitti> BenC: is there an easy way to get a core of a running kernel? that would be nice for the testsuite
<cjwatson> otavio: we are working our way steadily through that list at the moment, and don't otherwise need reminders :-)
<BenC> pitti: actually, there is...the command that processes vmcore, can also process /proc/kcore the same way
<pitti> BenC: aah, that vmcore file is nothing else than a copy of /proc/kcore? nice
<BenC> pitti: so for the testsuite you could use /proc/kcore instead of /var/crash/vmcore
<pitti> that sounds fine
<BenC> pitti: Basically, but not exactly
<pitti> I'm just keen on having tests for everything I add to apport
<otavio> cjwatson: ok
<ogra-classmate> BenC: so what do i do with that working driver now? (even though i'd appreciate NM support)
<BenC> ogra-classmate: I'll get the driver packaged up in linux-driver-backports for feisty
<ogra-classmate> did you manage to get the driver from the ralink tarball building?
<BenC> the tarball I got with NM support
<ogra-classmate> i didnt manage to get that to build here
<Hobbsee> Lure: ping?
<Lure> Hobbsee: pong
<Hobbsee> Lure: do you know if networkstatus-dev just needed to be added back, as is, to kdepim, or if more was to be added?
<Lure> Hobbsee: just need to be added back (it is juct couple of .h files afair)
<Hobbsee> Lure: great, okay, willfix.
<Lure> Hobbsee: see feisty package: http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=networkstatus-dev&version=feisty&arch=i386
<Hobbsee> yeah, i found it
<pitti> doko: yay, ia32-libs is in anastacia
* pitti demotes
<sbalneav> cjwatson: Could you help me with a bit of an ssh coding question?
* siretart makes a note to merge ia32-libs and ia32-libs-sdl
<seb128> pitti: did you accept evince-gtk?
<pitti> seb128: accept? it's not in NEW
<cjwatson> sbalneav: I can trry
<cjwatson> try
<seb128> I mean the new binary from evince
<pitti> seb128: no, why? evince-gtk exists since dapper
<seb128> pitti: ah, it failed to build
<sbalneav> Should we /query, or do it here?
<seb128> pitti: right, but it's built by an another source package now (and there is a new -dbg)
<doko> pitti: cool. finally
<pitti> seb128: if a binary moves between sources it doesn't need NEWing
<pitti> seb128: ah, for the -dbg then
<sbalneav> Here's the issue: slow terminals are having problems with ldm being written in python
<sbalneav> so we need to reimplement in C
<seb128> pitti: I was just wondering why it's not in NEW, and the explanation is "cc: /build/buildd/texlive-bin-2007/build/source/inst/lib/libkpathsea.so: No such file or directory"
<seb128> pitti: I hate .la
<cjwatson> sbalneav: here's fine
<sbalneav> we plumb the connection in ssh
<mneptok> seb128: San Francisco is nicer
<pitti> seb128: erk, which packages' fault is that?
<seb128> pitti: hum, in fact doesn't look like a .la problem. I would blame texlive-bin
<seb128> gicmo: Alter! How is gutsy going for you? ;)
<sbalneav> However, I need to control ssh via the terminal (for passing the password), mainly becaus the ssh-askpass mechanism doesn't work if you're sshing into a machine with an expired password (i.e. pam's going to ask you for a new one)
<seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=167030
<seb128> ups
<ubotu> Gnome bug 167030 in gconf "/tmp not cleaned up, which causes bad results if user's UID changes" [Critical,New]  
<seb128> pitti: http://librarian.launchpad.net/7834709/buildlog_ubuntu-gutsy-i386.evince_0.9.0-1ubuntu1_FAILEDTOBUILD.txt.gz
<gicmo> seb128: pretty good so far!
<seb128> rock on ;)
<gicmo> some font minor font issues
<gicmo> but fixed that
<sbalneav> so what I need is the C magic necessary to control ssh like how something like expect would do it
<seb128> gicmo: the font size issue is g-s-d looking at the screen DPI now
<seb128> gicmo: that's the changes federico did
<seb128> I'm not sure which that gives an ugly result
<cjwatson> sbalneav: I'd be pretty wary of that, because you're going to end up relying on human-readable text which might well change between ssh versions
<pitti> seb128: I don't know; the command specifies /build/buildd/texlive-bin-2007/build/source/inst/lib/libkpathsea.so explicitly as part of the linking
<sbalneav> cjwatson: agreed, but I don't feel like trying to fix ssh-askpass functionality to handle pam password expires :) that's a little beyond my ken.
<pitti> seb128: and of course that doesn't exist
<seb128> pitti: it must get it from a .pc or something
<seb128> pitti: I'm trying to figure where
<seb128> texlive-bin 2007-9 (tar) [70,7MB] 
<seb128> hum
<pitti> seb128: libkpathsea-dev ships a .la file, let me check
<seb128> I've -8 atm
<seb128> $ grep buildd /usr/lib/libkpathsea.la
<seb128> libdir='/build/buildd/texlive-bin-2007/build/source/inst/lib'
<seb128> hate hate hate
<StevenK> Fun.
<seb128> pitti: ^
<pitti> seb128: shall I upload a -9ubuntu1 and kill the .la?
<Mithrandir> pitti: please.
<seb128> yes please
<sbalneav> cjwatson: any suggestions?
<cjwatson> sbalneav: I'm just looking at a few things
<sbalneav> cool, thx
<Mithrandir> I think we should make shipping .la files RC.
<pitti> ok, I'll do that and send it as a bug towards Debian
<pitti> they are fast with accepting patches
<seb128> k
<seb128> I'm pondering make cdbs debhelper rule use clean-la.mk by default
<Mithrandir> seb128: doit.
<mthaddon> Launchpad is going down in 15 mins for a code update. Estimated downtime is 10 mins or less.
<pitti> seb128, Mithrandir: uploaded
* seb128 hugs pitti
<bonii> j #fedora
<cjwatson> sbalneav: from the ssh end, you just need to make sure to invoke ssh with -t
<sbalneav> ok
<cjwatson> sbalneav: the trick is going to be getting hold of the tty though
<cjwatson> actually, it might be easier to allocate a pty/tty in the wrapper, and make sure that ssh inherits that as its controlling tty
<pitti> seb128: ok, sent to BTS; with some luck we can sync it again in a few days
<sbalneav> cjwatson: any pointers to some example code on that? :)
<cjwatson> you can use openpty to allocate it, and ioctl(TIOCSCTTY) to make it the controlling tty
<cjwatson> sshpty.c in openssh itself would be one place to look
<cjwatson> you can then read from / write to the master end of the pty
<sbalneav> Thankee!
<cjwatson> you shouldn't then need to use ssh -t, since it'll have a tty already
* Hobbsee starts to wonder if there's anything cjwatson *doesnt* know.
<cjwatson> sometimes all you need is to be able to look stuff up faster than the next guy ...
<sbalneav> That'll get me pointed at the right direction.  excellent.
<Hobbsee> heh
<Keybuk> sweet
<Keybuk> keybuk.compiz_clue++
* Keybuk successfully compiled and installed the beryl wall plugin into gutsy's compiz-core
<seb128> Keybuk: what videocard do you have?
* seb128 has white borders around menus since the compiz upgrade on his ATI
<Keybuk> seb128: -intel
<Keybuk> I have the same bug
<Keybuk> heh
<Keybuk> expo is kinda broken
<mvo> WTF wiki.ubuntu.com just ate my changes
* mvo radiates anger towards it
<mvo> "The authentication database is temporarily unavailable. Anonymous access only.You are not allowed to edit this page."
* Hobbsee suggests mvo offers more sacrifices to the launchpad gods
<Hobbsee> mvo: [00:29]  <mthaddon> Launchpad is going down in 15 mins for a code update. Estimated downtime is 10 mins or less.
<Keybuk> ah, expo is broken unless it's loaded before fade
* mvo grumbles grumbles grumbles
<mvo> thans Hobbsee
<pitti> mvo: back button doens't help?
<pitti> mvo: btw, you might want to take a look at editmoin. It's 100% pure love
<ogra-classmate> pitti: POST data
<mvo> pitti: I use it a lot, just not this time
<mvo> pitti: maybe back helps once LP is back, currently it keeps telling me editing is impossible
<mvo> pitti: I don't know if it still knows about my changes
<pitti> hm, this is still not packaged
<ogra-classmate> sponsor a MOUT ;)
<ogra-classmate> MOTU
<pitti> ogra-classmate: oh, I was going to do it myself now, since spending 4.5 hours on the NEW queue bored me
<pitti> but if someone is interested in packaging it, sure
<Hobbsee> pitti: s/bored me/ made me insane/?
<pitti> Hobbsee: just avoid the letter 'q' for a while :)
<Hobbsee> pitti: q?
<ogra-classmate> heh
<pitti> Hobbsee: the alias for 'queue'
<crimsun> binary NEW will have something in it soon ;)
<Hobbsee> is "q" accept or something?
<cjwatson> Hobbsee: it's the tool to manipulate the queue
<Hobbsee> ahhh, i see
<cjwatson> queue override, queue accept, queue reject, etc.
<Hobbsee> gotcha
<Hobbsee> + queue block_this_uploader_from_the_archive
<Keybuk> seb128: it only seems to affect panel and transients though
<Keybuk> if I set the shadowing to toplevel only in the decoration prefs, it's fine for those windows
<kylem> maswan, hey, i'll have a test kernel for you in a bit.
<maswan> kylem: thanks, but I'm not going to be onsite until monday most likely.
<kylem> ok.
<kylem> basically your setup is ultra-crackful.
<kylem> like, afs... wtf. :)
<maswan> heh. :)
<maswan> anyway, I'm already late for dinner, so later in a bit. :)
<pitti> ogra-classmate: so, it's packaged now :) just waiting for niemeyer to release a good upstream tarball with a license
<gnomefreak> are we getting rid of gimp or is this a bug?
<pitti> gnomefreak: poppler transition going on
<gnomefreak> ah ok
<ogra-classmate> pitti: ah, cool
<maswan> kylem: hmm. do you think our setup is crackful enough that noone else is likely to get bitten by this? (if it is just us, I'll just postpone it totally to monday, otherwise I'll try testing it tomorrow)
<kylem> maswan, yeah, i'm pretty sure... ben pointed out you see your first oom (on a 1page (4K) allocation) within 5 minutes of boot on .53
<maswan> kylem: well, normally it is a bit smoother than that, this was under max load (booting with lots of queued things, as compared to tasks dropping in now and then), but yes.
<pitti> seb128, Mithrandir: hmm, I uploaded new texlive-bin almost two hours ago, and no sign of it in Soyuz
<seb128> did you get an accepted mail?
<pitti> hm, no
<ogra-classmate> did you upload to debian ? :)
<pitti> nope :)
<pitti> oh, yay
<pitti> 15:30:04 DEBUG   Considering changefile texlive-bin_2007-9ubuntu1_source.changes
<pitti> 15:30:04 DEBUG   Overriding distribution: ubuntu
<pitti> 15:30:04 DEBUG   Finding fresh policy
<pitti> 15:30:04 ERROR   Unhandled exception from processing an upload
<pitti>  -> http://librarian.launchpad.net/7835045/yVsG6yuaidYPcjD3NeIWVsBdyq0.txt (ERROR:  column "gotchi_heading" does not exist at character 109
<pitti> cpro1: ^ any idea?
<ogra-classmate> hackergochies are part of the upload process now ? wow
<seb128> pitti: distribution "ubuntu", is that normal?
<ogra-classmate> :)
<pitti> seb128: last time I checked that's the distro we all use :) but I don't know, I guess so
<seb128> pitti: k, just to be sure you didn't use "ubuntu" instead of "gutsy" to the changelog entry ;)
<seb128> iz soyuz bog
<pitti> Distribution: gutsy
<desrt> WORD
<pitti> desrt: dude! how are you?
<desrt> pretty fine
<desrt> chillin' in the sun
<seb128> it's too hot here
<seb128> 31C
<desrt> 27C here
<pitti> oh, shit
<pitti> seb128: it just occured to me that we cannot quite sync poppler yet, I need to add Conflicts:/Replaces: to the new libraries for the old names
<pitti> seb128: ok, it's in accepted now
<seb128> pitti: Debian renamed it as well, they didn't use the Conflicts, Replaces?
<cjwatson> pitti: I put https://wiki.ubuntu.com/MainInclusionReportSexyPython in the queue, btw
<cjwatson> (since it existed already)
<pitti> ah, thanks
<pitti> seb128: I don't see how that works without; you cannot install them side-by-side, since the .so name is identical
<seb128> pitti: I'm just wondering why Debian didn't use a Conflicts,Replaces
<seb128> they changed the naming for Debian so they should need it as well
<pitti> seb128: indeed
<seb128> maybe not the qt4 package though
* Treenaks burns himself on gutsy-current :)
<Treenaks> oh well.. I guess this'll fix itself
<seb128> I'm sure they would be happy to apply the diff so we can sync though
<seb128> hi Treenaks
<seb128> Treenaks: did you read my question about pppoe yesterday?
<pitti> seb128: yep, I'll send it to them
<seb128> pitti: thanks
<pitti> seb128: uploaded and sent
* seb128 hugs pitti
<pitti> ugh, what a Friday; just archive stuff and package fixing, nothing productive...
<seb128> pitti: archive is productive
<seb128> you unblock other people ;)
<astro73_> I have code, how do I turn that into a package for ubuntu?
<ion_> Try #ubuntu-motu
<astro73_> k, thanx
<ogra-classmate> hmm, sylpheed has no .desktop entry ? :/
<carlos> mvo_: ddtp template for universe is approved now, it should be imported soon
<TheInfinity> hello ... one question ... i'm active in (k)ubuntu support a little bit and most questions we get are about video drivers. the user can't repair anything if installation failes, they dont know how to use vi and xorg.conf and they dont get help via console so that they have to switch to windows - or saying that *ubuntu is crap. iperhaps a solution ... would it be possible to have 2 xorg.confs?
<TheInfinity> if it fails loading the main file it loads something like an failsafe file to give the user a gui?
<Lure> TheInfinity: check this https://blueprints.launchpad.net/ubuntu/+spec/bullet-proof-x
<mrsn0> TheInfinity i do similar on another network, 10 says 99% of issues are ati ? ;)
<TheInfinity> ah ok somewhere else had this idea, too - good :)
<TheInfinity> mrsn0: the last ones we get were nvidia
<TheInfinity> most because of not good reading of the user
<mrsn0> the new restricted drivers manager in feisty seems to help lots of new users
<TheInfinity> but if xorg does not start the GUI-user sits there and thinks "ooohhh ok"
<mrsn0> but for people with 8800gtx or recent ati cards, i mention 'envy' to them in the mean time
<mrsn0> i look forward to unbreakable X :D
<ogra-classmate> well, with restricted-manager it shouldnt happen that the user sits in fron of a not starting xserver
<ogra-classmate> it does a ton of checks before switching the driver
<TheInfinity> ogra-classmate: i just had this some minutes ago so i got this idea - but i was not the first, this whitepaper is the right direction i think :)
<mrsn0> indeed
<TheInfinity> users try it manually when it does not work automaticly ...
<TheInfinity> because they want to try things (which they dont understand)
<ogra-classmate> TheInfinity: 1i'm talking about the guio tool to switch to a proprietary driver, not about the spec
<ogra-classmate> that spec is three or more releases old
<TheInfinity> hmm .. i'm kubuntu user ... is it possible that this gui is not that perfect in kubuntu?
<TheInfinity> i never used it because i like vi ;)
<ogra-classmate> TheInfinity: restricted-manager as we ship it in feisty
<ogra-classmate> i dont think its in kubuntu at all yet
<TheInfinity> ok i just wonderes about it ...
<TheInfinity> so this should be the first thing to do
<ogra-classmate> there are only so many developers that can port stuff over ;)
<ogra-classmate> so kubuntu is a bit behind with some new things usually
<ogra-classmate> (which is not a bad thing since the most evil bugs were squashed in ubuntu then )
<TheInfinity> somehow a pitty because germany is KDE country and lots of people search alternatives for suse which becomes not really better ....
<ogra-classmate> TheInfinity: only because germans dont know whats good for them ;) 
<TheInfinity> *g*
<ogra-classmate> ich versuch seit gnome 1.2 die leute zu ueberzeugen ;)
<ogra-classmate> but at some point i gave up :)
<TheInfinity> i use kde for myself - its all a question of getting used to it and personal likes and dislikes
<ogra-classmate> right
<TheInfinity> ok that means answering video driver questions until guty
<TheInfinity> thats a good aim ;)
<ogra-classmate> well, you could help porting the app over :) Riddell surely needs every helping hand
<tsmithe> ogra-classmate, classmate eh. how's ubuntu on it?
<ogra-classmate> tsmithe: not at all :P
<ogra-classmate> its edubuntu ! ;)
<TheInfinity> ogra-classmate: after my vordiplom i'll try *g*
<ogra-classmate> and its great 
<tsmithe> ok. how's /ed/ubuntu on it? :P
<ogra-classmate> a tad slow but fully functional
<tsmithe> is it just a smaller, lower-powered normal x86 laptop?
<tsmithe> or is it funky?
<ogra-classmate> evolution doesnt like my 2gig mailbox though
<ogra-classmate> its a standard celeron M 900 with 256 M ram and 2gig flshdisk
<tsmithe> hehe
<tsmithe> so it's not too bad then
<ogra-classmate> nope
<ogra-classmate> i even compiled some things on it todat
<tsmithe> bit more ram might be nice tho..
<ogra-classmate> *today
<TheInfinity> ogra-classmate: kmail does not like mine, too - thats something which i find somehow a pitty ... no real groupware client like outlook running with linux ...
<tsmithe> ogra-classmate, :S how was that?
<ogra-classmate> tsmithe: great, i got my wireless card working now
<tsmithe> it's not an intel wireless standard jobby?
<ogra-classmate> TheInfinity: well, eveo is usually the only thing apart from mutt that can handle mine, but i'm running all that on a 2 gig usbflash drive (including OS and /home)
<ogra-classmate> tsmithe: you would think so ....
<ogra-classmate> but apparently thats to expensive :P
<tsmithe> so what is it then?
<tsmithe> (please not broadcom :P)
<ogra-classmate> price is the most essential criteria for this thing
<ogra-classmate> ralink
<TheInfinity> ogra-classmate: i just was in conflict with the idea of having shared adressbooks, shared kalenders with sending schedule entrys around and so on + linux - bad for a guy who always sayd outlook is crap ;)
<tsmithe> hmm i've had awful troubles with ralink..
<ogra-classmate> evo sint so far away from outlook
<ogra-classmate> tsmithe: me too ... still not solved 100% but nearly
<TheInfinity> ogra-classmate: it becomes better and better, yes
<TheInfinity> i hope it will soon be a real alternative for users who are used to outlook
<tsmithe> ogra-classmate, do you have a good link for docs? (i'd rather use the ralink than my acx100 if i could)
<TheInfinity> this would break one one the main office arguments for windows
<ogra-classmate> tsmithe: well, i just compiled the tarball from serialmonkey.org
<tsmithe> heh ok
<ogra-classmate> tsmithe: but intel is helping a lot with that, the ralink driver will get a lot better soon
<tsmithe> oh cool
<ogra-classmate> read:gutsy
<tsmithe> indeed
<tsmithe> it's good to have their folks working with us
<ogra-classmate> yeah, totally
<carlos> mvo_: your .pot file is now imported
<ompaul> ogra-classmate, you got something called email, you may have heard of it :)
<johanbr> ogra-classmate: There was just a question in #ubuntu-kernel why the ralink driver isn't in the Gutsy kernel build. Has it been taken down for improvements?
<ogra-classmate> johanbr: BenC is actively working on it
<BenC> johanbr: it is there, but it's in linux-ubuntu-modules
<ogra-classmate> ompaul: yeah i just got sylpheed running on this tiny thing and yours was the first mail i got, thanks
<johanbr> Oh, I see. Thank you.
<ompaul> ogra-classmate, :) hope you can follow my ramblings
* ompaul flies over to ogra-classmate to set up imap so he can trash boxen at a rate of knots :)
<ogra-classmate> ompaul: i could follow them qafter several liters of beer, so i suspecdt i'll mange the same while being sober ;)
* ompaul chuckles
<ogra-classmate> i'm using imap ....
* ompaul is trying to be funny please don't stop me :)
<ogra-classmate> but over all i have 200000 messages in about 50 folders
<ogra-classmate> somehow the flashdrive is to slow for that ... but sylpheed works somehow
* ompaul only has about 50k
<ompaul> video updates only 
* ompaul ponders
<mvo_> carlos: super! thanks
<luisbg> hey ompaul 
<ompaul> luisbg, hey, I asked you something about 5 days ago, check your messages, if you can't find it I'll find my logs
<ogra-classmate> i wonder if balsa has still an upstream
<ogra-classmate> its a beautiful small mail app ....
<luisbg> ompaul, yeah, wanted to talk to you about that
<ompaul> luisbg, pm me 
<ompaul> we are slightly off topic for here :)
<luisbg> true
<luisbg> elmo, ping
<glatzor> hello bryce
<bryce> heya glatzor!
<glatzor> bryce: displayconfig now has got an --xconfig option that allows to specify an alternative config file. Furthermore it now survives a config file without any screens, monitors and graphics cards.
<glatzor> bryce: quite trivial changes. I added a fallback xorg.conf to my repository too.
<glatzor> bryce: displayconfig will try to detect the gfx card and if it fails it adds a vesa card
<glatzor> bryce: bzr co http://glatzor.de/bzr/displayconfig-gtk/sebi
<glatzor> bryce: sudo ./displayconfig-gtk --data-dir=data -xconfig=data/xorg.conf.fallback
<glatzor> small typo. should be: --xconfig=data/xorg.conf.fallback
* mvo_ hugs glatzor
<rodrigo> please, how do i know how the package was configured?
<glatzor> mvo_: aren't you supposed to be on vacations?
* glatzor hugs mvo too
<mvo_> glatzor: tomorrow :)
<ogra-classmate> glatzor: oooh, can we have it without -gtk as well ?
<rodrigo> what options was used on "./configure"... 
<glatzor> mvo_: still two hours to work :)
<ogra-classmate> glatzor: i.e. scriptable
<ogra-classmate> that would give me a major improvement in ltsp
<mvo_> glatzor: haha, right
<glatzor> ogra-classmate: for sure. all the magic is done by the guidance backend.
<mvo_> glatzor: I did not notice that its that late already
<ogra-classmate> cool
<bryce> glatzor: excellent
<mvo_> displayconfig rock da house
<glatzor> ogra-classmate: bryce: but I am not sure how update-to-date the used pcitables are.
<bryce> glatzor: I had a question on the MonitorDB -- where does this info come from?  It seems a tad out of date and I'm wondering if there's an easy way for us to refresh the data, other than manually poking in values for unsupported monitors?
<bryce> glatzor, great to hear of the fixes in displayconfig-gtk.  If I have time today I'll try to roll out a new package, and play with it some more
<mvo_> bryce, glatzor: I push a displayconfig-gtk/ubuntu branch to the displayconfig-gtk group so that we can all work on a shared tree 
<mvo_> bryce: the data comes from kde guidance, I'm not sure where that comes from, but it would be cool if we could write a converter to get the information form discover and the fedora display-settings into dc-gtk
<bryce> bdmurray, cool thanks for the obsolete bug cleanup work :-)
<bryce> mvo, yeah I agree
<bryce> mvo, any idea where guidance gets the data?
<mvo_> bryce: unfortunately not :/ we should just ask them :) very friendly people
<glatzor> bryce: I am writing an email to simon at the moment
<Lure> bryce: just pink sebas or _Sime in #kubuntu-devel
<glatzor> bryce: mvo_: So no problem to add a further question :)
<Lure> s/pink/ping/
<mvo_> thanks glatzor
<bryce> mvo, discover may be a good way to work around if no info is in the db, but I don't know if we can trust it 100%, so getting up-to-date data into MonitorsDB would be ideal
<mvo_> *nod*
<bryce> I've wondered if we could write scripts to scrape the pdf's from manufacturer's sites
<bryce> or alternatively if we could set up a web form for users to enter data for missing monitors, that can be reviewed and added
<mvo_> I wonder how much data is already out there in other free packages? e.g. SaX or the fedora thing
<mvo_> geting data directly from the users is good too
<bryce> mvo, *nod* that's a thought too
<bryce> this is why I'm curious about the origins of the info from guidance
<bryce> as a test, the past couple days I've been reviewing the reports of monitor misdetections in LP; often their monitors aren't in this database, which makes me worry since much of the reason for the GUI tool is to resolve exactly those issues
<bryce> I've also found at least two vendors (Apple and Acer) that have monitors with no published H/V frequencies I can find online at all, which is quite troubling
<bryce> (well, these are laptop LCD's, not monitors exactly)
<glatzor> bryce: mvo: http://www.linuxfibel.de/xconfigurator.htm (monitors) and http://wiki.mandriva.com/en/Tools/XFdrake (cards)
<glatzor> bryce: both tools are mentioned in the beginning of the files
<bryce> ahh
<glatzor> bryce: oh sorry, I did not pay attention to the language of the first document :)
<bryce> hehe, damn us monolingual usians ;-)
<bryce> actually I took a couple years of german in high school, but that was long ago
<bryce> I only remember the curse words
<mvo> glatzor: that one is still used in fedora?
<glatzor> mvo: bryce: I will cc you the mail.
<glatzor> mvo: needs to be checked
<bryce> cool thanks
<mvo> glatzor: thanks!
<mvo> ok, I think I should start packing now, the train goes tomorrow morning
<glatzor> mvo: have a nice trip!
<mvo> thanks glatzor!
<glatzor> mvo: and come back relaxed :)
<mvo> glatzor: I will (I hope)
* mvo waves
<bryce> cya mvo, have fun!
<mvo> thanks bryce! 
<glatzor> bryce: the KDE wiki page mentions a reconfiguration on runtime feature of x. do you know anything about this one?
<glatzor> https://wiki.kubuntu.org/KubuntuGutsyGuidance
<Lure> glatzor: xrandr 1.2?
<bryce> glatzor: yeah sounds a lot like xrandr
<bryce> I don't know of any other runtime reconfiguration in recent Xorg
<glatzor> bryce: seems that I have to finally use Launchpads bzr repositories directly and not let it mirror mine.
<glatzor> :)
<bryce> heh
<glatzor> bryce: do you know of any launchpad policy changes?
<bryce> no I don't
<glatzor> bryce: this morning I could reject bugs of gnome-app-install ...
<glatzor> but now it only tells me that I am not the assigned person, the maintainer nor the reporter
<bryce> hrm
<glatzor> Additionally out of the same reasons I cannot assign the bug to me :)
<glatzor> Kind of boot strapping problem :)
<bryce> yeah I don't know if there have been changes; I haven't seen any announcements about new launchpad releases or policy changes
<bryce> join #canonical-sysadmin
<bryce> maybe ask on #canonical-sysadmin?
<glatzor> bryce: Oh, I am a fool. My login was not remembered :)
<glatzor> bryce: It is getting late here in Europe :)
<\sh> it is late in europe ;)
<bryce> aha :-)
<glatzor> \sh: I had a late shift today and arrived one hour ago back at home. So I have got a small lag in my day time.
<glatzor> bryce: should we add a dialog that asks the user if he or she wants to run displayconfig to a different source repository or should I add one to displayconfig?
<glatzor> bryce: I pushed my changes to the ubuntu branch. Would be nice if you could verify the fallback xorg on your computer.
<bryce> ok cool
<glatzor> The fallback xorg.conf of displayconfig to be exactly.
<bryce> by source repository what do you mean?
<glatzor> bryce: https://code.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu
#ubuntu-devel 2007-05-26
<glatzor> see you bryce!
<astro73_> would you (plural) find a dh_installupstart script useful?
<Hobbsee> morning all!
<Hobbsee> what does one do with http://librarian.launchpad.net/7834592/buildlog_ubuntu-gutsy-i386.freemind_0.7.1-6_FAILEDTOBUILD.txt.gz ?  It's failing as j2re1.4 and j2sdk1.4 are build-deps, and the licence file isnt being accepted on the buildds.
<Hobbsee> ?
<desrt> that's a funny situation
<Hobbsee> yes :)
<Hobbsee> i'm not sure how anything else handles it
<desrt> i'm not sure that there is anything else that builddeps on packages with license agreements
<Hobbsee> it's a bit of an odd build-dep, yes.
<Fujitsu> batik fails for the same reason, but I hadn't bothered to look at why.
<sontek> hey, I was wondering if any of you guys knew what the package is called for the onscreen display for media buttons on laptops
<Hobbsee> sontek: kmilo for kde
<sontek> Hobbsee: i'm using gnome :)
<Hobbsee> then i have no idea, as i dont.
<Hobbsee> suspect google might answer your question though
<sontek> Hobbsee: yeah, i'm slowly running through
<sontek> haven't been able to find anything yet
<sontek> I found an app called "keytouch" thats looking promising
<sontek> I just like to know what apps I'm using :P
<marcin_ant> hi all
<marcin_ant> I got a question. Some time ago I reported a bug #113310 "dbconfig-common cannot create database for package"
<ubotu> Launchpad bug 113310 in dbconfig-common "dbconfig-common cannot create database for package" [Undecided,Confirmed]  https://launchpad.net/bugs/113310
<polopolo> Hello
<marcin_ant> and in ubuntu this bug is still unresolved - and more it's even undecided (lazy developers, bad developers ;) )
<polopolo> Marcin_ant you have more change if you join the channel #ubuntu_bugs and then say you're problem
<marcin_ant> so I wrote about it to dbconfig-common developers list
<marcin_ant> and seanius solved this bug and released new dbconfig-common version - 1.8.34
<marcin_ant> that I can confirm that works poperly in ubuntu
<marcin_ant> polopolo: ehh ok but wtf it this channel for?
<marcin_ant> I just would like to ask what to do to upgrade dbconfig-common in ubuntu?
<crimsun> 1.8.34 is already in gutsy.
<marcin_ant> crimsun: so I will have to wait for next ubuntu release to have this bug fixed?
<crimsun> you can ask for a backport to feisty-backports
<marcin_ant> crimsun: ok - ask where?
<crimsun> marcin_ant: https://launchpad.net/feisty-backports/+filebug
<polopolo> !bugs
<ubotwo> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
<marcin_ant> polopolo: I just reported this bug and then nothing happened
<marcin_ant> polopolo: so you cannot call my irc activity as bug report
<cjwatson> astro73_: only once we're actually starting to use upstart jobs and have a feel for what common actions should be abstracted away; I don't think it's a good idea to do up-front before that
<marcin_ant> polopolo: if this bug is solved in upstream (thanks to my dbconfig-common-devel list activity) I just wanted to tell you about it and ask what can I do to make this solution available to all Feisty users
<polopolo> marcin_ant look bug#70938
<polopolo> !bug 70938
<ubotwo> Sorry, I know nothing about that - try http://help.ubuntu.com/community/
<ubotu> Launchpad bug 70938 in cacti "installer does not create cacti database (dup-of: 113310)" [Undecided,Confirmed]  https://launchpad.net/bugs/70938
<ubotu> Launchpad bug 113310 in dbconfig-common "dbconfig-common cannot create database for package" [Medium,Fix released]  https://launchpad.net/bugs/113310
<cjwatson> marcin_ant: https://wiki.ubuntu.com/StableReleaseUpdates
<marcin_ant> crimsun: are you aware that your development and procedures are overcomplicated? and they are not easily available even for launchpad users?
<cjwatson> like Debian, we do not upgrade wholesale to new upstream versions in stable releases
<crimsun> marcin_ant: I fail to see how the references both cjwatson and I have provided are overcomplicated.
<cjwatson> marcin_ant: the procedures are not meant to be easily available; they're meant to protect our users against instability from updates that weren't properly checked
<cjwatson> (there have been serious problems with that in the past)
<cjwatson> oh, sorry, dbconfig-common is in universe, so https://wiki.ubuntu.com/MOTU/SRU instead
<cjwatson> "wtf is this channel for"> coordination among Ubuntu developers
<marcin_ant> cjwatson: ok I agree with you but to be honest I think that all these development procedures should be easy available for launchpade registered users
<Fujitsu> marcin_ant: They are publicly available...
<Burgundavia> marcin_ant: they are: via the publicly editable wiki
<marcin_ant> cjwatson: not spreaded in various wiki places
<cjwatson> sorry, but that's the way it is
<Fujitsu> They're not spread.
<cjwatson> launchpad is for collaboration - it doesn't replace the wiki
<marcin_ant> ok I don't have time for argue with you
<marcin_ant> I just want to help from time to time
<marcin_ant> and I don't want to waste my time for digging your procedures
<marcin_ant> I just reported bug in dbconfig-common, and in fact I reported it also to upstream and this bug is now fixed
<cjwatson> marcin_ant: http://wiki.ubuntu.com/UbuntuDevelopment is a central reference for all of that
<Burgundavia> if that page lacks something, please tell us specifics so we can fix it
<marcin_ant> please do something to make this solution available for Feisty users
<marcin_ant> thank you
<Burgundavia> marcin_ant: just to be absolutely clear: you want the development information moved from the Ubuntu wiki to Launcphad?
<Burgundavia> is that your proposal to fix the issue?
<cjwatson> nominate the bug for feisty. https://bugs.launchpad.net/ubuntu/+source/dbconfig-common/+bug/113310/+nominate
<ubotu> Launchpad bug 113310 in dbconfig-common "dbconfig-common cannot create database for package" [Medium,Fix released]  
<marcin_ant> Burgundavia: sorry I don't have time to talk now - maybe at the evening
<Fujitsu> And preferably start the SRU procedures, by creating a debdiff.
<marcin_ant> Burgundavia: but all I want to say is that if there is bug reported in launchpad
<marcin_ant> Burgundavia: and there is solution in upstream, then someone should at least change this bug from Undecided to... something different
<Burgundavia> someone means you
<Burgundavia> the paid staff are limited and community just as so
<marcin_ant> Burgundavia: or note that fix is available but will be released with next release
<Fujitsu> Priority doesn't have anything to do with the upstream status.
<Burgundavia> and the best way to win over people is with honey :)
<marcin_ant> Burgundavia: maybe me - but in fact I don't know what your release procedure is
<Burgundavia> then you ask
<Burgundavia> at this point we told you
<marcin_ant> Burgundavia: and I don't have privileges to change from "undecided" etc.
<Burgundavia> for that you can also ask
<marcin_ant> Burgundavia: anyway I got package for Feisty and I use this for myself maybe I will find some time to report this to feisty backports...
<marcin_ant> sorry I have to go now.
<Burgundavia> ugh
<jmg> [ 1225.200228]  SCSI device sde: 4022272 512-byte hdwr sectors (2059 MB)
<ompaul> Burgundavia, can you mute ubotwo ?
<Burgundavia> not here, not an op in this chan
<ompaul> ahh we need someone too :)
* mode/#ubuntu-devel [+o cjwatson]  by ChanServ
<ompaul> I lost my login to it :-( and I don't own it so I cant just go in through the back door :)
<cjwatson> +q, yes?
<ompaul> yes
<ompaul> or op me for two second
* mode/#ubuntu-devel [+b %ubotwo!*@*]  by cjwatson
<ompaul> thats the one :)
<ompaul> cheers colin
<cjwatson> something translated +q to +b, but whatever :)
* mode/#ubuntu-devel [-o cjwatson]  by cjwatson
<ompaul> the % is the mute
<cjwatson> polopolo: btw, #ubuntu-bugs isn't really a good place for users to ask about bugs
* ompaul wanders off to stop the bot from spouting rubbish
<cjwatson> it's more for coordination among bug triagers
<polopolo> ah, I'm new :P
<mdke> is it usual to assign untriaged bugs to Ubuntu Drivers?
<mdke> I'm not sure there is much I can help with on bug 116972
<ubotu> Launchpad bug 116972 in Ubuntu "Hp LaserJet 1005 wont work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116972
<mdke> I dunno if that is the result of a button which launchpad has, like "nominate for release" or somethin
<Fujitsu> mdke: No, that should never be done, AFAIK.
<Fujitsu> The nomination might do that now, but I don't think so.
<mdke> so someone has assigned them manually?
<Fujitsu> Yes, polopolo did.
<mdke> ok
<EnolaGay> hi all
<EnolaGay> Is apport-gtk fixed in Feisty or is it scheduled for Gutsy?
<EnolaGay> +planned to get
<Hobbsee> hi all
<Hobbsee> hi `23meg 
<`23meg> hi
<`23meg> is anyone informed on the status of the work on encrypted block device support in Ubiquity?
<Hobbsee> `23meg: does the corresponding spec say who's involved?
<Hobbsee> on the wiki page?
<`23meg> yes, cjwatson, who seems to be away :)
<Hobbsee> well, it is the weekend
<EnolaGay>  Is apport-gtk planned to get fixed in Feisty or is it scheduled for Gutsy?
<Hobbsee> EnolaGay: ask pitti  about that
<EnolaGay> Hobbsee: I know but he isn't here too :)
<Hobbsee> likely gutsy, though.  unless it's a SRU candidate
<Hobbsee> depending on what hte bug is, and how important the fix is
<Hobbsee> etc
<EnolaGay> But without the fix most users won't post any crash report.
<Hobbsee> hiya Lure 
<Hobbsee> EnolaGay: after seeing some of the recent reports filed...i'm not sure we watn them to.
<Lure> hi Hobbsee
<Lure> Hobbsee: do you work on kdepim/networkstatus issue?
<EnolaGay> Sounds a little bit sarcastic ;)
<EnolaGay> So it is not a bug but a feature.
<Hobbsee> Lure: heya.  which one?  networkstatus, or networkstatus-dev?
<Lure> Hobbsee: -dev
<Hobbsee> EnolaGay: i dont use apport-gtk, so i dont know.  but it was planned to turn it off during feisty, i thought.  ask pitti.
<EnolaGay> Maybe apport-gt should just check if there is already a similar bug report.
<Hobbsee> Lure: patch done.  some people are reporting trouble with upgrades, so i havent gotten it uploaded yet
<Hobbsee> Lure: kontact/knoda desktop file overwrite, it seems.
<Hobbsee> EnolaGay: there's plans for that, but not in apport
<Lure> Hobbsee: just checked, this is already a problem with current package
<Hobbsee> Lure: the file overwrite?
<EnolaGay> Hobbsee: Ok, I am going to ask pitti but I thought apport is a great idea. Thanks.
<Lure> Hobbsee: trying to overwrite `/usr/share/services/kontact/knodeplugin.desktop'
<Hobbsee> Lure: yes - /usr/share/services/kontact/knodeplugin.desktop hasnt been distributed since 3.5.5 or so.
<Lure> Hobbsee: but where? in kontact or knode?
<Hobbsee> Lure: i've put in a preinst for knoda to delete that file, but havent tried it
<Hobbsee> in kontact
<Hobbsee> it's in knode only
<Lure> Hobbsee: problem is that kontact also ships it
<Hobbsee> which version of kontact?
<Lure> 3.5.7-1ubuntu2
<Hobbsee> it's not listed in the kontact.install, which is confusing me
<Hobbsee> knode.install:/usr/share/services/kontact/knodeplugin.desktop
<Lure> Hobbsee: it is listed in dpkg -L on installed system ;-)
<Hobbsee> and the changelog is the only thing that grep finds
<Hobbsee> Lure: this is true - which appears to have been put there from a pre kde 3.5.5 version
<Hobbsee> so i'm not sure if a preinst of knoda to remove it is the right solution, or what
<Lure> Hobbsee: 3.5.7 for feisty does not ship it (just checked in chroot)
<Hobbsee> yep
<Hobbsee> Lure: i'll admit now, i dont understand why this file is still here.
<Hobbsee> unless nothing has removed it previously
<Lure> Hobbsee: it is a ghost file ;-)
<Hobbsee> Lure: how's the best way to remove it though?
<Lure> Hobbsee: not sure what Riddell did for feisty...
<Hobbsee> Lure: he didnt.  same bug.
<Lure> Hobbsee: but my feisty package does not have knode desktop file!?
<Lure> Hobbsee: just .la/.so files are there
<Hobbsee> Lure: in knoda, or kontact install file?
<Lure> Hobbsee: kontact
<Lure> I do not have knode installed on feisty
<Hobbsee> Lure: that's correct - because it's not there, because it's only a ghost file, like you said.
* Hobbsee thinks sh'es talking in circles here.
* Hobbsee headdesks at #ubuntu+1
<Hobbsee> Lure: it's only in knoda.install now
<Hobbsee> Lure: i'm assuming that one can just remove the ghost file in a preinst or something, and the problem goes away.  but i've not dealt with them before, i'm not sure.
<Hobbsee> Lure: sorry if i'm being short with you.  work was...well, interesting.
<Lure> Hobbsee: ;-) - I am a bit slow too (mostly in bed for last 4 days :-( )
<Hobbsee> eek :(
<Lure> Hobbsee: problem seems to be that kontact.install packages whole /usr/share/services/kontact subtree, including knodeplugin.desktop
<Hobbsee> Lure: ahhh...
<Hobbsee> Lure: so it does.  hand me the duncecap please.
<Lure> Hobbsee: I was staring there also for 10 minutes and did not notice it... ;-)
<Hobbsee> hehe
<LjL> ubotwo part
<ompaul> cjwatson, you can now unban the standby bot :-) cheers
<ompaul> ubotwo
<Fujitsu> What was killing the bot before?
<Hobbsee> ompaul: which now?
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [-b %ubotwo!*@*]  by Hobbsee
<bhale> -|- 19 - #ubuntu-devel: ban %ubotwo!*@* [by cjwatson, 13093 secs ago] 
<ompaul> Fujitsu, the other one had a regex issue, 
<bhale> tihs one
<bhale> Hobbsee: oh :)
<Hobbsee> got it :)
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<ompaul> thanks
<Hobbsee> no problem
<ompaul> cjwatson, guess Hobbsee beat you to it
<Hobbsee> he's not here, i dont think
<Fujitsu> That's what Hobbsee does.
<Hobbsee> it's saturday lunch
<Hobbsee> Fujitsu: yes, i beat people up.  it's a good skill.
<Fujitsu> I noticed.
<mneptok> i beat people off. i'm more popular than Hobbsee.
<Hobbsee> mneptok: only on the "i wish to kill you" scale.
* Fujitsu kills mneptok to prove Hobbsee's point.
<mneptok> Hobbsee: you need to pay more attention to bathroom grafitti
<Fujitsu> mneptok: Wise words/
<Hobbsee> i'm probalby in the wrong bathrooms.
<mneptok> Hobbsee: that's .... not a drinking fountain.
<ogra-classmate> heh
<Fujitsu> ogra-classmate: How's the Classmate going?
<Hobbsee> hi ogra
<Hobbsee> those classmates look cool
<Hobbsee> hi spam
<Fujitsu> Why's he spam now?
<ogra-classmate> running evolution, gaim and epiphany alongside with no probs atm
<Hobbsee> because he's greeneggsandspam.
<Hobbsee> which shortens to spam
* Fujitsu complains about Epiphany leaking memory like something that leaks a lot of memory.
<mneptok> Firefok? ;)
<ogra-classmate> well, it seems to be a lot better than firefox here
<mneptok> s/k/x/
<Fujitsu> 1.5GiB of RAM after a few days just isn't cool.
<jsgotangco> Hobbsee: err its greeneggsnospam
<ogra-classmate> and it renders pages way better suited for the display size
<Hobbsee> jsgotangco: ahhh
<Hobbsee> jsgotangco: which still shortens to spam
<jsgotangco> gahh
* Fujitsu should probably head off to bed soon.
<Hobbsee> wow, some one must have gone thru the -devel moderation queue
<Hobbsee> Fujitsu: it's not that late...
<Fujitsu> Hobbsee: I've been up way to late lately; I slept in until 11:30 this morning.
<Hobbsee> awwww
<Hobbsee> start getting up at 3am.
<Hobbsee> you see all the europeans, before they go to bed.
<Fujitsu> Unfortunately I can't really turn nocturnal.
<Hobbsee> sure you can
<Hobbsee> just go overseas
<Hobbsee> you're in the air for long enough that you can change what timezone your body is in to whatever you like.
<Fujitsu> Heh, parents'd love that :P
<Hobbsee> mine didnt die :P
<Fujitsu> That I know well.
<Fujitsu> But you're ancient!
<jsgotangco> lol
<Hobbsee> Fujitsu: you're a male.  you're a *lot* safer going overseas.
<Fujitsu> True, that.
<Fujitsu> Anyway, goodnight.
<Hobbsee> night!
<Hobbsee> if a bug counts as grave in debian, and hasnt been fixed by the upstream, is it worth at least thinking about removing the package from teh archive?
<Hobbsee> hasnt been fixed since 05
<persia> Hobbsee: Which bug?  Could it be fixed locally?
<Hobbsee> persia: debian's marked it as upstream, upstream hasnt fixed it.  
* Hobbsee grabs the bug #
<Hobbsee> persia: https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/45763
<ubotu> Launchpad bug 45763 in checkinstall "checkinstall hid my root partition " [High,Unconfirmed]  
<Hobbsee> i suspect it's not worth fixing, based on what it is.
<persia> Hobbsee: That bug is fixed in Debian with checkinstall 1.6.1-1.  Can't we just merge/sync?
<Hobbsee> persia: is it?
<Hobbsee> it's already merged
<persia> Hobbsee: Read the Debian bug report :)
<Hobbsee> i did, it said "we cant reproduce this, file upstream"
<Hobbsee> iirc
<persia> Hobbsee: See the very last post :)
<persia> (yes, it was unreproducible, upstream)
* Hobbsee marks as fixed
<Hobbsee> ah, gotcha
<Hobbsee> didnt get that far, for some reaon
* desrt yawns extensively
<Hobbsee> morning desrt, are we keeping you up?
<desrt> i'm not sure how that would work, so i suspect the answer is no
<desrt> just late night + early morning
<Hobbsee> heh
<desrt> today i have hacking to do!  yay.
<Hobbsee> yay!
<wereHamster> which package does provide /usr/lib32/libX11.so on a amd64 system?
<wereHamster> .. and /usr/lib32/libXv.so{.?}
<tsmithe> dpkg -S is handy
<wereHamster> do I have to have the package installed?
<wereHamster> .. because I don't
<wereHamster> I want to find out which one I have to install
<Lutin> tsmithe: dpkg -S requires a package to work on. apt-file would be a better solution
<tsmithe> hmm yes
<tsmithe> that's why i didn't attempt it here :P
<wereHamster> don't have apt-file :(
<tsmithe> thanks for that command
<Lutin> wereHamster: then install it :)
<wereHamster> .. assuming I'd have to 'apt-file update' first.. which doesn't work on a livecd
#ubuntu-devel 2007-05-27
<Uzuul> hello
<Uzuul> how can I request an official ubuntu mailing list (for the Ubuntu Media Center project)?
<Burgundavia> Uzuul: via rt
<Uzuul> Burgundavia: rt?
<Burgundavia> rt@admin.canonica.com
<Burgundavia> canonical.com, rather
<Uzuul> Burgundavia: thanks a lot ^_^
<noria> what happened with "alsaconf" from debian?
<crimsun> noria: stopped shipping it. See the alsa-driver changelog for the rationale.
<Hobbsee> morning all
<noria> okay, will do
<lifeless> moin
<Hobbsee> hey lifeless!
<lifeless> Hobbsee: heya. I'm *nearly* home :)
<lifeless> Hobbsee: just got on 18 hour leg to go :)
<lifeless> ok, plane time. tchau
<Hobbsee> lifeless: ouch!  have fun :)
<Hobbsee> oo.o is dead :(
<Pumpernickel> o.o
<Toxicity999> Hmm?
<Hobbsee> ah.  nope, i'ts only sorta dead - dies after trying to do a data recovery
<Hobbsee> "this page uses frames, but your browser doesnt support them yet"
<Hobbsee> oookay then!
<mpt> http://www.google.com/search?q=%22this%20page%20uses%20frames%20but%20your%20browser%20doesn't%20support%20them%22
<Hobbsee> mpt: ?
<Hobbsee> mpt: i know what hte message means for a browser - but to get that in openoffice writer, for a .doc?
<mpt> huh, that's interesting
<mpt> Hobbsee, Word 2000 lets you edit Web pages that use frames
<mpt> Which, iirc, also means that it lets you use frames even for documents that never end up as Web pages
<mpt> I assume Word XP and Word 2007 do the same
<mpt> So either Word, or a Web page editor the document was in before Word, may have inserted that boilerplate in the <noframes> element
<mpt> and then someone using Word saved it as a Word document rather than as a Web page.
<mpt> And then OpenOffice.org didn't see the frames for whatever reason (perhaps it doesn't support them? perhaps the frame contents got corrupted?), and ended up showing just the <noframes> contents.
<Hobbsee> mpt: wonderful...
<Hobbsee> crazy word...
* Hobbsee curses dead uni wifi and such, which causes such problems.
* LongPointyStick descreens
<Lure> can somebody give-back kdegraphics to pick up right depends on new poppler?
<Hobbsee> evening all
<pygi> hi Hobbsee 
<Hobbsee> :)
<pygi> how are you?
<Hobbsee> good - home from work, finally
<pygi> Hobbsee, nice ^^
<noria> does any of you come to LinuxTag in germany?
<\sh> noria, yes
<noria> will there be some event about this new ubuntu certification thingie?
<\sh> noria, you mean LPI things? yeah, LPI Germany will have some courses ready...
<noria> LPI is distribution independent. i was reading on a blog that Ubuntu makes their own. or was that a myth?
<\sh> noria, LPI has created, together with the ubuntu crew, a cert which needs LPIC-1 and is named imho lpi 199
<\sh> noria, LPIC-1/-2/-3 is distribution independent yes, but they work together with other distros to do some distro specific certs
<noria> ah, thats interesting
<\sh> noria, you can read about it on lpi.org website...or just come around to the LPI booth, hopefully you will meet me, or a friend of mine, Matthias Alberts, who can give you more infos 
<noria> yeah, that would be cool
<noria> our beloved "Agentur fr Arbeit" does not care about such certifications yet, but i thought its worth the investment if you are looking for jobs that you can do from home
<\sh> noria, or come around the kubuntu/ubuntu booth at linuxtag, meet the other community members (including me) and we can go together to the LPI booth, so you don't have to wait for your infos :)
<\sh> noria, LPI certs are nothing for the "Agentur fuer Arbeit" they are working together with other companies, but I never saw anything linux specific
<noria> that would be fun, cause i never met community members so far :o)
<\sh> noria, send me an email (sh @ sourcecode . de) so I can put you on my schedule
<noria> \sh, yeah and that is a shame. because they sponsor the MCSE training to people who hardly know anything about computers
<\sh> real name would be cool, indeed
<\sh> noria, that's why most of those mcses are not getting a job
<noria> they better used that money on linux training so that people can support the community at least if they find no job :P
<\sh> (in companies who need real windows cracks sometimes...right now, even linux people do know more about windows server, then those mces, seeing it every day in our company)
<\sh> noria, well, we need people...linux cracks especially...jobs.combots.com 
<noria> i am not "amoung the best" yet. but i work on that :P
<\sh> noria, starting as a junior, working up to a senior...is this ok? 
<\sh> noria, and you will work with some of the best sysadmins  
<noria> that sounds too good to be real :P
<\sh> noria, and you will work with some ubuntu/debian/sles developer as well :) 
<noria> okay, and how much do i have to pay? :P
<noria> without kidding, i think i dont play in such a high league
<noria> i am human!
<\sh> noria, hehe...you will get payed...and no, we are not uber-humans...still plain normal people, with a lot of experience...and we need new blood...
<noria> \sh, sounds fantastic to be a long term coal for me
<\sh> noria, just send me your profile and your cv with your email :) really, don't be scary :)
<noria> because a linux related job has one big advantage of any other jobs - its not real work if you have strong believes in what you do
<pradalvr> Hi i am getting an error when i try and save security file into ect directory
<\sh> noria, sysadmin work is a hard job, you will have to work more then 40 hours per week, even when you are good :)
<\sh> pradalvr, what error? hopefully you mean /etc/
<pradalvr> yeah! thats it
<pradalvr> https://help.ubuntu.com/community/AutomaticSecurityUpdates
<pradalvr> I have dyslexia 
<pradalvr> use Kate. Also available via the command line are various other text editors that you can use. The file you create, name it apt-security-updates and place it in the directory /etc/cron.weekly/.
<pradalvr> thats when i get the error 
<pradalvr>  "Could not save the file"
<mdke_> pradalvr: please ask for support in the #ubuntu channel. Having said that, you'll need administrative privileges to save a file into /etc
<pradalvr> I do
<pradalvr> its my machine
<Hobbsee> hiya mdke_ 
<mdke_> hi Hobbsee 
<Hobbsee> :)
<Hobbsee> pradalvr: did you use sudo, though?
<Hobbsee> or gksu?
<pradalvr> but it never allowed me to use a password.....yes and file not found
<webwolf_27> I was planning on writing a graphical dsl-setup program. Would there be any objections to writing this with wxwidgets, or would gtk be better? 
<webwolf_27> the main interest behind it would be to make setting up german t-online and 1und1 dsl connection easier for n00bies
<Hobbsee> assuming wxwidgets is in main, it shouldnt matter, if it ever becomes default
<persia> webwolf_27: Unless you really need to port to windows and mac, and want native widgets, I'd recommend GTK+.
<webwolf_27> I would at least like to see it on the main cd as, it's pointless to have to download such a program out of the net
<webwolf_27> persia, that would also be a good incentive for me to finally learn the gtk+ livs
<webwolf_27> livs=libs
<webwolf_27> Like I said. My main interset is german convertee's as here DSL is the standard. I'm not sure whats used primarly in other countries
<pradalvr> One thing that i have learned while trying to understand computers, no one is willing to help anyone that is new...Sadly i it make me feel like i am in middle school all over again...I am sure this has turned several people off with learning..By the way, I was reading and trying to understand how to gain permission on saving files, I never figured that out. I asked the ubuntu help channel...
<pradalvr> ...and was unsuccessful..Trying to ask anyone for help leaves a bad taste in my mouth EVERY TIME..goodbye 
<Hobbsee> pradalvr: please look at the day
<noria> pradalvr, hold on
<Hobbsee> pradalvr: please note that most people arent here on a sunday
<pradalvr> well i was for hours 
<noria> pradalvr, you got the wrong impression. that has nothing to do with your person or the fact that you are new - at least not on channels that are related to Ubuntu
<Hobbsee> webwolf_27: sounds interesting.  i'm not the one who makes those decisions though
<Hobbsee> #ubuntu is busy -people often dont get an answer, because it's so huge
<Hobbsee> pradalvr: it is still a sunday.  yesterday was a saturday.  the distro team doesnt wrok weekends, unless they have a specific reason to.
<StevenK> They don't work, either.
* StevenK ducks.
<noria> heh
<noria> pradalvr, sometimes it is easier to find solutions to problems on web forums or mailing lists, because that is easier for people who are willing to help
<noria> pradalvr, if you want to, then you can private message me your problem and i try to help
<noria> the people here on this channel focus on development related topics
<pradalvr> I am a 36 year old female that thinks most people in IRC acts like young teenagers...Just not appealing for someone trying to honestly learn...People in here hide behind their computers using it as an excuse to be VERY RUDE...Thank you noria but i am very tired, it is 5.42 am here. I need sleep
<noria> pradalvr, lol. i understand your feelings very well. but it does not fit to the people in the Ubuntu community. most of them are very decent people
<pradalvr> thank you for the invitation to help 
<noria> pradalvr, you can take some rest and contact me after sleep if you want to
<Hobbsee> pradalvr: oh, you've reminded me of who you are now.
<pradalvr> maybe not in your opinion...but in my experience, its been a ridiculous nightmare
<pradalvr> I really dont care if you remember me hobbsee
<noria> pradalvr, lets talk after you got some sleep :)
<Hobbsee> you played the "no one's answering me, because i'm female, and the ops all hate me, because i'm female, and they have a horrible all male club"
<Hobbsee> card
<pradalvr> then you should know how long i have been asking
<pradalvr> how long ago hobbsee
<Hobbsee> dont remember.  there are lots of people i've helped since then, and talked to.
<pradalvr> you certainly remember who i was
<pradalvr> take a shot
<Hobbsee> it was before UDS
<Hobbsee> i couldnt take a more accurate shot than that.
<pradalvr> awhile back 
<Hobbsee> still, i'm not sure what your actual quesiton was either.
<Hobbsee> so maybe if you enlighten us on that...it might actually help.
<pradalvr> so noria, that goes to show you how long i have been trying..not being rude, just proving a point
<pradalvr> I told you
<pradalvr> i can't save a file so that i can use sudo
<noria> pradalvr, i understand your hard feelings. i offered you alternatives. now its on you to take some sleep and try again :)
<pradalvr> i don't have the permission
<Hobbsee> use chown
<Hobbsee> man chown will tell you more
<pradalvr> yes you are right...my back is killing me and i am starting to get massive cellulite like never b4
<Hobbsee> ie, sudo chown /foo/bar/directory or whatever.  use -R for recursive
<pradalvr> chown: missing operand after `/foo/bar/directory'
<pradalvr> Try `chown --help' for more information.
<Hobbsee> oh, sorry.  sudo chown youruser.yourgroup /foo/bar/directory
<Hobbsee> which chown --help, or man chown will tell you
<Hobbsee> i'm not sure you actually want your security files to be written to by a regular user anyway.
<ompaul> Hobbsee, pradalvr  user:user 
<Hobbsee> oh yes, : sorry
<StevenK> . will work, but is discourged because user names can contain a '.'
<Hobbsee> StevenK: ahhh....thanks.
<Hobbsee> pradalvr: however, this is an #ubuntu type question, which they should have answered you.  assuming it didnt get lost in the general flood of questions, which isnt personal.
<Hobbsee> unclear questions will also tend to get ignored
<Hobbsee> you may wish to see http://www.sabi.co.uk/Notes/linuxHelpAsk.html and try to use things in there to get more sucess
<Hobbsee> pradalvr: you may also wish to check out ubuntuforums.org, which has a search function, and lots of people looking to help out.
<Hobbsee> which is slower than irc
<ompaul> pradalvr, the reason your question did not get answered in #ubuntu is that it is not obvious what you are trying to do, and therefore people don't want to give wrong answers, however from watching here pradalvr, I think you are using the wrong tools for a job, or trying to do something you should not, so I would advise against it, and just get on with using the operating system and not trying to alter the default install it is rathe
<ompaul> r secure out of the box, if you need something special then I strongly suggest and advise training
<pradalvr> thank noria...I tried responding to your private message ....can forgot to sign in......but yes advice taken...thank you again Noria
<pradalvr> bye
<noria> pradalvr, oh. i am sorry about that. i ...
<noria> thats the spam protection of freenode i guess
<mc44> Hobbsee: another grateful customer :P
<Hobbsee> mc44: known troll, more like it.
* Hobbsee notes that she didnt even *respond* to the info given here, either.
<Hobbsee> what's the point in telling someone something, if they dont even listen?
<ompaul> mc44, how can you "not be able to write" to something that you should be able to write to? 
<Hobbsee> well, not quite a troll - just not a person really wanting to be helped, it seems.
<persia> Hobbsee: That's a great link on asking for help.  Do we have anything similar and specific to #ubuntu?
<Hobbsee> persia: nope
<Hobbsee> persia: it's in my quit message - people sometimes read it
<Hobbsee> persia: actually, we may do.  in the FAQ or guidelines, which of course, no one reads.
<persia> Hobbsee: :)
<persia> Hobbsee: Right.  As with everything else, I just think there should be well-known, Ubuntu-specific URLs for pasting.  Oh well.
<Hobbsee> of course
* Hobbsee waves the magic wand
<Hobbsee> {{documents appear in the wiki}}
* persia celebrates
<bhale> http://pastebin.ubuntu-nl.org/
<bhale> bookmark it.
<persia> bhale: It doesn't work from this IP :(
<Hobbsee> bhale: heh, that doesnt change it to being just for #ubuntu though
<bhale> i dont see the point in that
<persia> bhale: We have lots of channels.  Suggesting which channels people should use would be good.  Also, there may be specific guidelines that apply to Ubuntu that could be listed.  Lastly, Ubuntu branding of documentation makes Ubuntu users feel comfortable.
<Hobbsee> however the generic thing also makes users realise that this is a generic guide for tech help anywhere.
<persia> Hobbsee: True.
<Hobbsee> maybe i'm just jaded her.
<Hobbsee> *here
<bhale> im jaded for sure.
<Hobbsee> but i'm very much a person believing about the "if you give a man a fish, he'll eat for the day, but if you give a man education on how to fish, he'll eat for a lifetime"
<ompaul> persia, we do in #ubuntu say things like: !es for spanish and if someone says compiz/beryl  we say #ubuntu-effects
<Hobbsee> or whatever the quote is
<Hobbsee> i cant see how you cope in computers, etc, and life, otehrwise.
<ompaul> Hobbsee, it is 99.9% right so I would not worry about the origin of the quote
<Hobbsee> :)
<persia> I have such an extremely low opinion of users that I generally refuse to interact with them in exchange for remuneration.  On the other hand, I think creating documentation that panders to the appropriately can reduce the chance they every try to reach me.
<Hobbsee> persia: haha. this is true ;)
<StevenK> Hobbsee: "If you build a man a fire, he will be warm for a night. If you set a man on fire, he will be warm for the rest of his life."
<Hobbsee> still, if they're not reading the documentation, is there any point in adding to it?
<persia> ompaul: That's great, but it means that someone has to do that for each inappropriate use.  If the /topic included a "Guide to asking for help on #ubuntu", maybe the load would be reduced.
<persia> StevenK: :)
<bhale> persia: the topic of this very channel is oft ignored.
* Hobbsee checks if it already does
<persia> bhale: Yes.  The topic of every channel is oft ignored, but if the load is reduced by only 20%, it's better for everyone.
<ompaul> persia, na, people don't do topic :)
<Hobbsee> actually, it' snot already on there
<ompaul> persia, I think the hit rate is more like 1% :-)
<Hobbsee> ompaul: please add the howto ask questoins to https://wiki.ubuntu.com/IrcGuidelines
<ompaul> and that is a big stretch
<Hobbsee> which is listed in the topic, so you can point people to them.
<ompaul> not a bad idea
<persia> ompaul: You'd be surprised.  I've seen a lot of people using the docs I put in the wiki, even though they're just regurgitations of other publically available information.
<ompaul> persia, the wiki works, but topics welll
<Hobbsee> ompaul: then you point people to the topic, and dont otherwise answer :P
<ompaul> Hobbsee, fail
<ompaul> it is a tad trite for the verbosity of irc 
* ompaul thinks back to the first conversation he had on irc all those years ago (1994)
<Hobbsee> ompaul: btw, it's suggested that #ubuntu be a lobby, and we have #ubuntu-effects, #ubuntu-hardware, #ubuntu-beginner, multimedia, gnome, kde, programming, games, networking, etc.
<Hobbsee> ompaul: i dont think that's such a bad idea...
<ompaul> Hobbsee, that would fail
<Hobbsee> even if people cross-post, it should still be more bearable.
<Hobbsee> everything fails - including what's there now.
<ompaul> Hobbsee, it is still working, in comparison with other places
<Hobbsee> ompaul: just people arent getting answered
<Hobbsee> some even with decent questions
<ompaul> Hobbsee, we should get ljl to do some stats on that
<Hobbsee> indeed
* Hobbsee adds more bot factoids
<Hobbsee> !weekend | ompaul 
<ubotu> ompaul: 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.
<Hobbsee> !night | ompaul 
<ubotu> ompaul: It's the middle of the night in the US and the UK.  This means that a lot of people are likely asleep, and so therefore there are less potential people who can answer your question.  Please be patient, and consider asking at a time when more people will be awake.  This is particularly true in the quieter channels.
<Hobbsee> ompaul: i'm sick of typing them.
<Hobbsee> :)
* persia suggests EU instead of UK
* ompaul concurs
<ompaul> Hobbsee, ^^
<Hobbsee> ah
<Hobbsee> great
<Hobbsee> !no night is <reply> It's the middle of the night in the US and Europe.  This means that a lot of people are likely asleep, and so therefore there are less potential people who can answer your question.  Please be patient, and consider asking at a time when more people will be awake.  This is particularly true in the quieter channels.
<ubotu> I'll remember that Hobbsee
<Hobbsee> persia: thanks
<Hobbsee> !no night is <reply> It's the middle of the night in the US and Europe.  This means that a lot of people are likely asleep, therefore there are less potential people who can answer your question.  Please be patient, and consider asking at a time when more people will be awake.  This is particularly true in the quieter channels.
<ubotu> I'll remember that Hobbsee
* persia wonders about canada and all the free software advocates in South America
<persia> Hobbsee: Sorry.  I'm thinking slow today.  How about "The Americas and Europe"?
<Hobbsee> !no night is <reply> It's the middle of the night in the US and Europe, and surrounds.  This means that a lot of people are likely asleep, therefore there are less potential people who can answer your question.  Please be patient, and consider asking at a time when more people will be awake.  This is particularly true in the quieter channels.
<ubotu> I'll remember that Hobbsee
<Hobbsee> there.
<persia> That sounds great.  Thanks.
* Hobbsee isnt good with PC stuff - being in AU and all, i was picking the biggest continents, and saying "these places, among others
<ompaul> Hobbsee, https://wiki.ubuntu.com/IrcGuidelines have a look at that
<ompaul> I added three lines to the tail of the discussion
<Hobbsee> ompaul: s/nearly a/over a/
<Hobbsee> ompaul: move it to second or third point, please
<Hobbsee> we want that to be read
<ompaul> Hobbsee, sorry I have a disconnect here
<ompaul> okay so move it back up a bit, but what is the search and replace for?
<Hobbsee> first paragraph
<Hobbsee> The #ubuntu IRC channel is growing very quickly, with nearly a thousand people in the channel all the time. Keeping a pleasant atmosphere in #ubuntu has been the main
<Hobbsee> wow, we're bigger than the two #debian's combined.
<ompaul>  okay I'll commit it
<ompaul> done 
<ogra-classmate> Hobbsee: size doesnt matter :P
<Hobbsee> ogra-classmate: does sometimes
<Hobbsee> ogra-classmate: # of people asking questions at once is usually proportional to size
<ogra-classmate> indeed, i wasnt serious
<Hobbsee> what's your solutoin?
<ogra-classmate> faster supporters ? subchannels ? no idea
<ompaul> subchannels don't work because helpers will not work in 5 channels at once
<Hobbsee> but the questiosn will flow slower, so there's more chance for backscroll
<Hobbsee> and they're only helping out a small subsection of the people anyway
<Hobbsee> if anything, it just becomes like #kubuntu - sometimes good - sometimes impossible to ge ta response
<ompaul> faster supporters well, the ability of helpers not to burn out is important, nay vital to the success of a channel, so having enough helpers seems to be the issue
<Hobbsee> i'm not sure if that's better or wrose than what we have now, tbh
* persia wonders if this is on-topic for #ubuntu-devel
<ompaul> persia, actually it is not, your right ;-)
<Hobbsee> not really, but no one else is talking, and you guys may have ideas that we can use.
<Hobbsee> which is why i havent suggested movign it
<persia> I think subchannels would help.  As long as there are enough questions to feed the egos of the helpers in each channel, they will specialise, which gets better helpers, and better answers.
* Hobbsee is well aware of the -ops response
<Hobbsee> persia: the fact is, people are startging to come here more for answers, as they're nto getting them in #ubuntu
<Hobbsee> which is problematic for here
<Hobbsee> (and it's nice to have one place where there isnt user support going on!)
<persia> Hobbsee: That's what I'm seeing too, which is why I am suddenly interested in #ubuntu (remember that bit about me not liking users)
* Hobbsee --> dishes
<Hobbsee> hehe
<Hobbsee> yeah
<Hobbsee> exactly
<ompaul> we are lowering the barrier to entry so the questions and managment of same has to change over time, for instance, a couple of years ago there was a lot of "sudo education" going on, once that was removed as a topic for debate things moved along nicely
<persia> ompaul: Is there any organisation of the helpers?
<ompaul> persia, no, they like to be thought of as free spirits, until they become of #ubuntu-ops at which time they become more serious :-) 
<ompaul> woops
<ompaul> persia, until they become aware of #ubuntu-ops at which time they become more serious :-) 
<ompaul> if they are seen as good they get told about #ubuntu-offtopic as a place to step away from the hard work, most people who dive into it help until burnout which does them no good, but trying to get someone to step back from the edge and take a moment out so that you can make it work better is hard
* Fujitsu helped intensively for a couple of weeks after Dapper's release, then burnt out and joined MOTU.
<persia> Really?  I'm surprised.  I would think that they would be incented by, say, a LP group (if you can demonstrate that you helped N people well, you can apply for membership, etc.), and having a short page that provided guidelines on what to do, how to do it, and what the criteria for the pony was might help.  But then again, I'm a fan of carrots.
<ompaul> Fujitsu, you were not the first and will not become the last
<ompaul> persia, irc is a lot more about the ability to do a little when you can, it is just that #ubuntu has become huge it is hard for people with good skills to keep it up
<persia> Fujitsu: If there was a team (with a (low) barrier to entry), would you have made an effort to join the team, perhaps especially if team membership contributed towards ubuntu membership criteria?
<ompaul> persia, but if we all do 15 mins a day then the job becomes a lot lighter, however the downside is always the "T" word, trolls who will go out of their way to take your time on other people.
<persia> ompaul: I totally understand about that.  I'm just a wonk, and generally believe that a good process, with good carrots encourages people to do what I want :)
<Fujitsu> persia: I'm really not sure... I'd always been wanting to be a dev, and got fed up with trollishness, and the sheer number of questions in #ubuntu.
<ompaul> persia, ehh process rocks, carrots come after people even realise there is a process, and the carrot is knowing someone is now able to use their systm
<persia> Fujitsu: Hrm.  Perhaps it's the development bent, but that probably means I'm wrong, when combined with ompaul's previous statements.
<Hobbsee> Fujitsu: you forgot to mention the same questions, continually.
<Fujitsu> Hobbsee: I guess, but that sort of comes under trolling at times.
<ompaul> persia, we often times see people who want to do more, and start with a visit to -bugs for triage and then on to motu 
<Hobbsee> this is true
<Hobbsee> i meant from different people, though
<Fujitsu> Oh, right.
<Fujitsu> Yes.
<noria> ompaul, one thought regarding that, please?
<Hobbsee> ompaul: i'm not sure that people with the good skills are inclined to do much with #ubuntu, as it's just so big and crazy
<ompaul> noria, would you like me to be more verbose or something?
<persia> ompaul: I think that's a good path for advancement, but I suspect there are a lot of people who aren't really developers who would benefit from a support-oriented track as well.  On the other hand, there would need to be a continous path to make that work well.
<noria> writing a little application is quite hard. it requires programming skills. reading code of other people is even harder. so directing people who are fascinated about Ubuntu and the community to #ubuntu-bugs might demotivate and frustrate the majority
<Fujitsu> Having smaller channels and some standard place for common questions and answers should reduce burnout, and make it all a little more pleasant, IMO
<pygi> smaller channels would soon grow if they are useful
<pygi> that's what we always get
<Hobbsee> people are also asking for help in #ubuntu-bugs now, for #ubuntu related stuff
<persia> Channel growth is good.  Community growth is good.
<noria> persia, i dont agree
<Fujitsu> pygi: Then we split them further? :S
<Hobbsee> Fujitsu: just the ones from #ubuntu
<pygi> Fujitsu, meh, scalability issues :-/
<Hobbsee> Fujitsu: which isnt split?
<noria> community growth is good. channel growth is bad. more people means more specialized places are needed
<Hobbsee> pygi: nothing scales well, in irc support, except bot commands.
<Hobbsee> which is why we use tehm.
<pygi> I know
<Fujitsu> #ubuntu is split a bit (-effects, -xgl, etc.), but not enough.
<ompaul> the smaller channels thing leaves me cold, unless you can convince me that there are the helpers to make them work, I am in +1 and ubuntu and a few more channels, but my eyes are only focused on this one right now, I will go to a !ops call, or if there is a highlight but you tend to get your attention focused in one place
<noria> a lobby where all new people go to, from there the people can be directed to specialized places. and people who need tutoring can be directed to special #classes
<noria> so they learn sooner or later what specialized places they need
<Hobbsee> ompaul: remember that you're a staffer though, and arent sitting in a support channel
<persia> noria: I agree.  Channel growth is good only because it indicates we have more people getting support.  Channels must then be split to ensure that everyone gets the right amount of support.  Huge channels are bad.
<ompaul> Hobbsee, I am a staffer sitting in several support channels :)
<noria> persia, and exactly that is not the reality
<Hobbsee> ompaul: true that.  but you're not sittign in one, trying to answer everything.
<Hobbsee> ompaul: whereas our straight support people tend to do that
<noria> the big channels have more noise, and more people who look for help have to deal with that noise
<Hobbsee> ompaul: tbh, i dont know if there are the helpers to make it work - but i suspect it's worth a try, and recombine them if it doesnt work.
<Hobbsee> we're nowhere near a release, so it's not such a bad time to try
<noria> not to mention the helpers who are totally stressed by the masses of people 
<Hobbsee> because it's clear that what we're currently doing *isnt* working
<ompaul> Hobbsee, I do it now and again but you are right, I don't to the detailed ones like working out that someone needs to fsck and use an alt superblock anymore
<Hobbsee> yeah
<persia> ompaul: I think that the creation of a "Career path" for support specialists (like BugSquad -> UbuntuQA -> MOTU  Contributor -> ubuntu-dev -> core-dev) would make it easier to keep people happy and doing a good job.
<Fujitsu> I don't think it can break much worse.
<Hobbsee> they're the kind of people who probably need the help, too.
<Hobbsee> ompaul: seeing as that sort of thing doesnt tend to be documented, and seems to change every time
<Fujitsu> Right, I sometimes do quick ones these days.
<noria> Ubuntu (thankfully) attracts people who have no background in computer science. and these people need guidance
* Hobbsee answers a questoin in #debian
<ompaul> persia, remove the arrows and you got a deal ;-) there should be no implicit implication that you have to start at any one level
<Hobbsee> #debian doesnt make my eyeballs bleed.
<Hobbsee> much
<Hobbsee> ompaul: it helps, to do it in that order, though
<noria> and keep in mind: if you start on IRC for the first time you can hardly keep track with the scrolling on a channel with 20 people. now scale that to a channel with 1000 people
<Fujitsu> ompaul: The entry points are the first and the third.
<ompaul> Fujitsu, there are exceptions to those rules
<ompaul> noria, point
<persia> ompaul: I disagree.  For the support pathway, I suggest that you tell everyone to start in #ubuntu-beginners (or something like that), and let them move to #ubuntu-foo when they have some expertise in a subject (maybe the next day), and so on, up the chain.  They are incented to keep supporting because that way they can get to the next step.
<Fujitsu> Maybe if somebody invokes super-powers.
<Hobbsee> persia: we dont have the manpower to detain people like that, unless it's by a bot
<Hobbsee> but i'm wondering how #ubuntu-beginners would go
<Hobbsee> because even the intermediate people should be able to answer the questions
<Hobbsee> the forums seem to cope
<persia> Hobbsee: Do we detail people in bugsquad -> qa -> contributor?  It's more that those not ready for the next step are encouraged to help more with bugs.
<ompaul> persia, so it becomes like the CC interview - we have markers 
<Hobbsee> persia: you're a contributor when you do bugsquad.  or support.  i'm not sure what your questoin is
<ompaul> Hobbsee, that is code contrib I think
<persia> Hobbsee: It's about perception, but you're right in some ways.
<Hobbsee> heh.  i answered a question in debian, saying "use this command to do this" adn they immediately went for the manpage.  yay!  :)
<Hobbsee> persia: bugsquad is not code contrib, but it's definetly contributions.
<persia> ompaul: right.  Not restricted, but people are given official notice somehow when they reach the next step, and congratulated.
<Fujitsu> Hobbsee: Wow, I'd like that knowledge to be more prevalent in #ubuntu :(
<Hobbsee> Fujitsu: which?
<Fujitsu> man
<Hobbsee> ah right, yes
<Hobbsee> "if someone gives you a command, try using "man command" to get more infomration on it"
<Hobbsee> persia: i think that we need to point out why bug triage is good, and to get more people into it - not give off the view that it's a poor substitute for developing
<Hobbsee> chances are, they will go into developing after doing bugsquad for a while anyway
<Hobbsee> qa is going away, iirc.
* Fujitsu has gone back to bugsquad, of late.
<ompaul> well that is what happened to gnomefreak that right John?
<Fujitsu> Hobbsee: Where'd you hear this?
<persia> QA is going away?  I liked that, and saw a lot of triage being done to be allowed to join QA.  Too bad.
<Hobbsee> Fujitsu: UDS
<Fujitsu> Hm.
<Hobbsee> well, with the talk of changing a lot of things in the bugtracker
<Hobbsee> no idea how much of it will actually happen though
<Hobbsee> it was a productive lunch with the LP guys.
<Fujitsu> Hahahaha. Change in LP.
<Hobbsee> sure, it happens.   PPA exists now.
<ompaul> Hobbsee, they lied to you :-)
* ompaul runs
<Hobbsee> i just didnt write all the info down as to where it is.
<Hobbsee> ompaul: i've seen it :P
<Hobbsee> ompaul: works nicely
<Fujitsu> How does it look?
<Fujitsu> What's the interface like?
<Hobbsee> meh.  it's listings of files
<Hobbsee> uses dput, etc.
<Hobbsee> ftp
<Hobbsee> does the repositories thing, etc
<Hobbsee> no fancy gui around it, iirc.
<Hobbsee> i didnt play with it myself - just saw people playing around with it before the end fo the final session, uploading thigns to it, etc
* ompaul wanders off to ponder the comments, you know you might have me thinking now 
<Hobbsee> ompaul: :)
<Hobbsee> ompaul: post your thougths to the ML please
<ompaul> Hobbsee, no, no, anything but my thoughts, :-)
<ompaul> if I get to a conclusion I'll post them
<Hobbsee> heh
<Hobbsee> post a summary, your thoughts, *and* the conclusion.
<Hobbsee> :P
<bhale> yay beagle built successfully on all archs
<gnomefreak> what happened to me?
<persia> Hobbsee: Sorry.  Missed a comment.  I don't think bug triage is a poor substitute for development, I just think that having done some bug triage should be a requirement when applying to be a developer, as otherwise bug management is difficult.
<Hobbsee> depends how you're terming a "developer" and how you're measuring it
<Hobbsee> are you talking about for motu, or what?
<ogra-classmate> congrats
<persia> Hobbsee: Sorry ubuntu-dev. 
<Hobbsee> persia: right, yeah, of course
<gnomefreak> persia: problem that you might run into: person knows enough to be a developer can code maybe 20 years of experience, if needed that bad why tell him come back in 3 months when you have done enough bug triaging?
<gnomefreak> know if you are pulling from motu that would be different
<gnomefreak> s/know/now
<persia> gnomefreak: I'd suggest that person work upstream, help them find some bugs to write code for, and help them manage the bugs until the three months had passed.
<Hobbsee> i suspect it's assumed that you'll have done a whole lot with bugs
<Hobbsee> whether our people actually do or not, when going for motu, is an interesting question
<ogra-classmate> grmbl, why does my pbuilder always fail with jadetex crap
<persia> It's assumed.  I think that creating a "Career path" helps protect us from breaking down the word assume.
<Hobbsee> which is part of DeveloperResources
<Hobbsee> good idea, though
<Hobbsee> not sure how far out of scope it is
<persia> Hobbsee: *way* out of scope, but as the groups grow, scope can expand (and it becomes important, as it's harder to know people).
<Hobbsee> indeed
<gnomefreak> i agree i think at times its a great thing but i think there are times where that shouldnt matter. this ofcourse is assuming they are hired by canonical or are we talking just joining the ubuntu-devel team without being employed?
<Hobbsee> ubuntu-dev
<Hobbsee> so not necessarily canonical employees
<persia> gnomefreak: Completely separate from canonical, just Ubuntu
<Hobbsee> motu & core
* gnomefreak gets confused between -core-dev and -dev 
<persia> (Canonical may sponsor a large number of core devs and others, but they are only one of many sponsors for Ubuntu)
<Hobbsee> gnomefreak: dev == motu + core
<ogra-classmate> seb128: any hint ? i cant build g-p-m here, my pbuilder fails on jadetex do you have any workaround you use over there ?
<seb128> ogra-classmate: what error?
<gnomefreak> oh
<seb128> ogra-classmate: no workaround, I don't use pbuilder and didn't get any jadetex error on my desktop
<ogra-classmate> oh, ok
<ogra-classmate> must be my pbuilder then ... it also takes about 30min to even get to the build ... setting up tetex in all languages it seems
<ogra-classmate> s/tetex/texlive/
* noria makes sure to copy this interesting debate for later re-work
<noria> one more thought i have, if nobody stops me from expressing it :P
<noria> people dont have to wait for the freenode-registry project to be finished to deal with the changing situation
<noria> for those "core developers" who need protection and privacy in their closer environment, a channel could be setup that is set to "invite only" and approved visitors are added to chanserv's access list so they can invite themselves
<noria> for lower requirements, a channel bot chan be setup that asks the new visitor to agree with certain points, then gets a passphrase which registers his hostmask for voice. only then the user can ask his questions
<persia> noria: At this point, it's probably best to draft some proposed processes for review.  Discussion is good, but having a starting point helps a lot.  I think it's generally agreed that something should be done, but IRC is probably not the best place to document what (although it may be used for decisions).
<Hobbsee> canonical has an irc server for that....
<Hobbsee> and ubuntu uses open development
<broonie> Debian uses a password protected channel.
<Hobbsee> trust us - we know a fair bit of irc lingo
<persia> noria: Also, there needs to be an open forum for developers.  As long as there is an adequate support structure, it helps a lot.
<noria> expressing an opinion is not sign of distrust in abilities and skills of others
<noria> i just noticed some people expressing earlier that they "hate users"
<noria> and my suggestion would be a quick fix for such people
<noria> for that i dont need to spend the next hours on a wiki posting
<Hobbsee> it's not the users that are teh problem - it's the questiosn they ask, in the wrong place.
<noria> ...
<mjg59> We already have a channel devoted to development discussion, not user questions
<persia> noria: It's quick, but it's not good :)  Users needs are important, regardless of how much any specific individual might wish to interact with them.  Without users there is no point to working on Ubuntu.
<noria> "its not your hairs, but the way you move"
<mjg59> There's no problem with users being in here
<Hobbsee> uh oh, it's a tech board member
* Hobbsee hides.
<persia> Users even sometimes have good comments in here.
<mjg59> The only constraint on use of this channel is that discussion be devoted to development of the distribution
<noria> yeah, i think my ideas are fantastic :)
<mjg59> I don't think there's any requirement for anything above that
<mjg59> It's not a social channel for developers, it's a forum for discussion of developmnt
<Hobbsee> mjg59: we had yet another user wanting support in here, saying that she could never get answers in #ubuntu, etc....
<noria> yeah. and you better spend a lot of time correcting people who bring other questions to the channel instead of having arrangesments that fix that problem
<noria> "the stupid user who does not read the channel topic"
<Hobbsee> i didnt say that
<noria> thats a general quote and addressed to no person
<mjg59> This is an inappropriate place to ask for support
<mjg59> If #ubuntu is failing to provide support, then yes, that needs fixing
<Hobbsee> mjg59: users are not seeming to undersatnd this.
<noria> wrong point of view
<Hobbsee> and there are slight discussions as to how to fix that
<mjg59> Right. But the appropriate fix isn't to turn this into a support channel and try to give developers a private space
<noria> you expect that a person who is new to Ubuntu and new to IRC sticks to prefect procedure. and that shows a very limited understand of humans 
* Hobbsee still doesnt get why noria is also not actually doing anything, only complaining about the problem.
<Hobbsee> noria: it's like road rules.  yes.
<noria> Hobbsee, please dont go to a personal level
<mjg59> noria: We have no problem with directing people to the right place
<noria> mjg59, okay
<mjg59> If someone asks a question here, it's quick and easy to direct them elsewhere
<noria> i hope i dont have to read about hate that often then
<Hobbsee> ...
<Hobbsee> if you twist words, you can read whatever you like.
<noria> Hobbsee, please dont go to a personal level
<mjg59> noria: The only person to have mentioned the word hate is you
<noria> mjg59, that is not correct if you scroll back
<Hobbsee> (and persia, hours ago, about hating doing user support)
<mjg59> noria: Not within the past 8 hours
<persia> noria: I believe I'm the person who expressed that I didn't much like doing user support, but I certainly don't hate the users.
<Hobbsee> noria: i'm not sure how that's going onto a personal level, or possibly becoming a personal attack - it's a simple fact.  if you're twisting words, you'll be reading whatever you want to be.
* Hobbsee shrugs
<Hobbsee> i really cant see how this is helping, nor is it on topic
<noria> we can do nit-picking, we can agree on the fact that i better part, or we can discuss about opinions
<Hobbsee> ompaul: has had some useful input, so hopefully the irc team will be able to come up with a better solution
<Hobbsee> and until anyone actually *does* something, then i'ts all hot air.
<noria> so my opinion is hot air. and that is not a personal level that you choose?
<Seveas> Hobbsee, hot air can be useful for a hot air balloon ;)
<mjg59> noria: An opinion alone does little to change things
<Hobbsee> Seveas: this is true.  please read the backscroll on what to do with #ubuntu - there are some good thoughts there.
<noria> some body might be really good with code, but it looks to me that some people have no feeling for humans
<Seveas> Hobbsee, read parts of it, don't like noria's approach to 'expressing an opinion'
<persia> Seveas: feel free to bug me if you want assistance with process documentation.
* Hobbsee resists the urge to say "and who's doing a personal attack now"
<Hobbsee> Seveas: noria's had trouble with freenode staff before - i never found out why.
<Hobbsee> Seveas: i was meaning about splitting the channel up - that section
<Seveas> Hobbsee, that's been suggested numerous times -- was the split design any good this time?
<Hobbsee> Seveas: i believe so
<Hobbsee> Seveas: it was good enough that ompaul is thinking about it, rather than rejecting it outright.
<Seveas> that's better than previous attempts then :)
<Hobbsee> exactly
<Hobbsee> mjg59: as a member of the tech board, what kind of meeting times work for you?
<mjg59> Anything between 12:00 and 02:00 or so BST
<mjg59> Though, outside the role of #ubuntu-devel, I don't think any of this is really a tech board issue
* Lure thinks that Hobbsee just want to arrange the meeting for core-dev appliaction ;-)
<Hobbsee> mjg59: true.  it's unrelated.  (core dev app)
<Hobbsee> mjg59: can you give that to me in a real timezone please?
<Hobbsee> like, UTC?
* Hobbsee cant convert 10 billion timezones.
* Hobbsee googles for what on earth BST is
<Lure> Hobbsee: BST is UTC+1 now and I think most (all?) TB is in this timezone
<Hobbsee> oh blerg.  i could have coped with "london time" or something.
<Hobbsee> or UTS
<Hobbsee> * UTC
<Lure> Hobbsee: BritishStandardTime, afair
<mjg59> Summer Time
<mjg59> But yeh
<Lure> mjg59: right
<Hobbsee> let's hope kclock is right hten.
<mjg59> Hobbsee: Ah, ok.
* Hobbsee curses
* Hobbsee gets out time and date again
<Hobbsee> Mithrandir: said that my afternoon would be good for you guys
<Hobbsee> either i cant add, or it's actually not.
<persia> Hobbsee: 9 hours earlier than your local time
* Hobbsee brain blows up.
<Hobbsee> 9pm local, until 11am the next day.  right.
<Hobbsee> persia is right, then.
* persia is smug
<Hobbsee> persia: now do my maths assignment.
<Hobbsee> thankyou in advance.
<persia> Hobbsee: pastebin?
<Hobbsee> you need an ID and such for it, i think :(
<Hobbsee> it's tripple integrals, and general stuff that was covered while i was in spain  / not at uni
<Hobbsee> it probably wouldnt be that evil if i looked at it, and knew the material.
<persia> Hobbsee: I don't have an ID.  Sorry.
<Hobbsee> yeah i realise ;(
<highvoltage> a
* ..[topic/#ubuntu-devel:SeNHoR_DaKoMBi] : www.canalmsn.com.br
<ompaul> Seveas, we are not putting a quantity on how much better at this stage ;-) I have reservations about a split but can see some merits in same
<ompaul> Seveas, got a land line close to you, I have an idea I want to bounce and see if it is plausable
<Hobbsee> heh
<Hobbsee> oh you lucky people who can do that
<ompaul> Hobbsee, have telephone will talk
<ompaul> have viop will talk for less
<persia> Hobbsee: You don't have a telephone?
<ompaul> voip even
<Hobbsee> this is true
* Hobbsee looks for her mobile which got a message earlier
<Hobbsee> crap.  it's about an assignment that's probably due tomorrow, and that i havent even started yet.  brilliant.
<ompaul> byeee
<Hobbsee> good thing they dont care if i submit very late
<EnolaGay> hi all
<Hobbsee> hiya
<EnolaGay> Is it possible that sony_acpi is removed from the linux-source-22 but not from the kernel package?
<EnolaGay> hi Hobbsee
<Hobbsee> ask in #ubuntu-kernel
<EnolaGay> In Gutsy of course :)
<EnolaGay> ok, thx
* ..[topic/#ubuntu-devel:Riddell] : Ubuntu Development Talk
* ogra-classmate moans that there is nothing like /vmlinuz --help to see all commandline options
<mrsn0> bugs.launchpad really slow recently or is it just me ? :)
<finalbeta> Goes faster then before for me.
<finalbeta> I'm using openDNS servers now. Might just be that for me.
* ..[topic/#ubuntu-devel:siretart] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy open, go ape!
<shawarma> I really wish irssi would show the old /topic along with the new one when it was changed..
<siretart> shawarma: I'm using topics.pl (an irssi script) for that.
<shawarma> I just found topic-diff.. Now I'm just holding my breath until someone changes the topic. :)
<Keybuk> lifeless: around?
<mrsn0> finalbeta strange, opendns seemed to make it load faster O-o thx
<afflux> A package using gdk-pixbuf-csource fails to build ("Couldn't recognize the image file format for file '../pixmaps/camorama-webcam-16.png'"). Would it be okay to put a "gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders" before the call of gdk-pixbuf-csource?
<afflux> (not really sure if this is the right channel)
<finalbeta> mrsn0: np. Seems to perform better then many peoples own DNS servers.
<mrsn0> finalbeta one less reason to rely on virgin/nthell ;)
<mrsn0> if only i could switch my cable to "opencable" and such a thing existed
<keescook> wow.  udev totally broke my lvm snapshotting.
<Hobbsee> morning keescook 
<keescook> hiya Hobbsee :)
<siretart> keescook: :(
<ogra-classmate> does anyone know if squashfs supports XIP already ? i know it was planned 
<siretart> keescook: my system doesn't boot again. it breaks again in initramfs, after doing the 'lvm vgchange -ay; logout' makes it boot
<siretart> keescook: can you confirm that?
<keescook> siretart: yup, same for me.
<siretart> great!
<keescook> I think something must have been left out of the lvm2 merge, but I haven't tracked that down; I can workaround that.  the snapshotting thing... I'm unable to do any work.  :P
<siretart> not able to boot warrants severity 'critical' imho
<siretart> keescook: are you talking about bug #105936
<ubotu> Launchpad bug 105936 in lvm2 "snapshot creation failure race "in use: not deactivating"" [High,Confirmed]  https://launchpad.net/bugs/105936
<keescook> siretart: nope, I don't even get devices any more.  :(  (though perhaps once this is fixed that "in use" bug will be gone)
<benpi> hi
<benpi> I've hard kernel freezes since upgrade to Feisty ; seting up remote-console, I only got this kernel message : "[99350.074138]  invalid opcode: 0000 [#1] "
<mrsn0> benpi this channel is for devel talk, try #ubuntu i believe
<benpi> ah ok (was about : how to debug such a freeze, actually)
<benpi> sorry for disturbing
<turmo> can I ask a question?
<welshbyte> turmo: first rule of asking questions is just go ahead and ask the question, don't ask if you can ask it
<turmo> what question should I ask?
<desrt> "am i a troll?"
<turmo> ?
<turmo> what question shall I ask?
<mjg59> What question do you want to ask?
<turmo> yes
<turmo> what question shall I ask?
<ogra-classmate> (07:39:23 PM) turmo: can I ask a question?
<ogra-classmate> which one *did* you want to ask ?
<turmo> why?
* ogra-classmate gives up
<turmo> what question shall I ask?
<ogra-classmate> mjg59: since you are here, any clue if there are chances we ever see that in ubuntu ? http://lwn.net/Articles/192851/
<ogra-classmate> it would be extremely helpful for thin client boots 
<mjg59> ogra-classmate: So far it hasn't proven to be stable
<turmo> what question shall I ask?
<ogra-classmate> well, he says its relatively stable in certain conditions
<ogra-classmate> which thin clients would fulfill
<ogra-classmate> the udev initscript takes about a third of the overall bootime of a thin client boot cutting that down would improve a lot
<mjg59> ogra-classmate: That seems massively unlikely
<mjg59> Well, Greg gets an improvement of 0.4 seconds
<ogra-classmate> well, dropping udevsettle from the initscript to make init not wait for udev finishing brings me about 20secs on a standard HW client
<turmo> what question shall I ask
<mjg59> turmo: If you have a question to ask, ask it. Otherwise no, you can't ask a question.
<ogra-classmate> so i assume parallel threading would lie somewhere inbetween
<mjg59> Right now, it results in stuff breaking
<turmo> what question shall I ask
<ogra-classmate> yeah, indeed
<turmo> what question shall I ask
<Joe_CoT> #ubuntu-bugs
<Joe_CoT> (sorry)
<wereHamster> can I create a bug in launchpad where I request a new package to be added (I'm neither running ubuntu nor do I have experience creating debian packages, but building the package should be straight-forward aka. ./configure; make; sudo make install;)?
<geser> wereHamster: see https://wiki.ubuntu.com/MOTU/Packages/Candidates for how to do it
<wereHamster> geser, thanks
<keescook> cjwatson_: can you ACK the final grub debdiff for bug 106887?  It looks fine to me, but I'm not a grub expert.  :)
<ubotu> Launchpad bug 106887 in grub ""ALERT! does not exist" at boot with ICH7" [Undecided,Confirmed]  https://launchpad.net/bugs/106887
<shaya> anyone running gutsy on a t60?
<shaya> there seem to be multiple issues
<mjg59> shaya: Have you reported them?
<shaya> just discovered them :)
<shaya> playing around w/ a T60 I got off of craig's list
<shaya> though it semi sucks in gutsy right now do to fglrx not working w/ new X and having to use VESA
<keescook> yay, snapshot creation solved.
<wasabi> Hmm... I think sleep on my laptop is sort of working... except that when it gets back the monitor doesn't turn back on.
<wasabi> adding a delay of 5 seconds after chvt 12 fixed the corruption. ;)
<wasabi> Hmm... I think sleep on my laptop is sort of working... except that when it gets back the monitor doesn't turn back on.
<AlexLatchford> I was just reading through this spec... https://wiki.ubuntu.com/DebianMaintainerField.. There seems to be that derivatives of Ubuntu are not accounted for.. What about Linspire's maintainer? Where does that go..? I would add a comment to the wiki page, but I am unsure of if I am allowed as the spec has been approved..
<Burgundavia> AlexLatchford: it is expected that derivs don;t really care about other derivs maintainers
<AlexLatchford> fair enough
<Burgundavia> are you a linspire dev?
<AlexLatchford> Nope.. just thought that if this has come up now with Deb/Ubuntu it may come up between Ubuntu/DistroX in the future
<AlexLatchford> thus it would make sense to implement it now..
<Burgundavia> I imagine linspire would create an "original-ubuntu-maintainer" field
<AlexLatchford> Ah okay, so these changes do not have to go back upstream?
<AlexLatchford> (I am not the most technical of guys)
<Burgundavia> no, those changes are done at the Ubuntu level, by our buildds and infrastrucure
<AlexLatchford> Ahh, okay.. that's cool then, I was worried that the spec was collaborating with Debian and changing the structure for all their packages also.. which would be pain in the future if the change was needed again..
<_StefanS_> stuff related to gutsy, and kernel bug(s), what channel is that?
<_StefanS_> and hi ;)
<Burgundavia> _StefanS_: bugs go in launchpad
<Burgundavia> if you want to help with kernel development, try #ubuntu-kernel
<_StefanS_> Burgundavia: I know, but I was wondering whether my mptscsi issue was my fault
#ubuntu-devel 2008-05-19
<n8k99> 2
<ubergoober> anyone here a package mantainer?
<ubergoober> have a question about dependencies/versions of in my control file
<ubergoober> ubuntu 8 was released and my package is broken now.
<ubergoober> good evening by the way. sorry don't mean to be rude
<RAOF> ubergoober: In general packages need a rebuild to work on a new release; dependencies tend to change.
<RAOF> ubergoober: I don't think you've actually asked your question yet.  What is it? :)
<ubergoober> RAOF: yeah seems that way
<ubergoober> sorry was away for a min are you still there?
<ubergoober> my question is my package depends on libpq4 but in my control file thats all I've required it just says simply libpq4
<ubergoober> when ubuntu 8 came out it tells me that libpq is a virtual package and fails to install because it cant resolve the dependancy
<ubergoober> so I tried something similar to this in my control file Depends: libpq (>=4)
<ubergoober> but I still get the virtual package error
<ubergoober> If I force the package to install and then install libpq5 it works just fine. Just cant figure out how to tell it to install  as long as it can fine libpq4 and up in the repositories
<RAOF> Right.  So, this would be a library transition issue.
<RAOF> Also, there's probably an easier way to specify your dependencies :)
<ubergoober> not sure how though
<ubergoober> I've only seen examples like the one above so thats what I've been trying
<ubergoober> is that not the correct way to do it
<RAOF> I'm sure the packaging guide has some examples of dh_shlibdeps
<RAOF> A dh_shlibdeps call in debian/rules should create a shlib:Depends variable, containing all the packages that supply libraries that your binary depends on.
<ubergoober> I've read a little on shlibs but doesnt that require that I build a source package first
<ubergoober> I only want to build a binary package because our software isn't totally free
<RAOF> Oh, so you're _manually_ writing a binary package?
<ubergoober> yes
<ubergoober> sorry for not being clear
<RAOF> Man, that's much harder than it needs to be :)
<ubergoober> just trying to roll up the software into a .deb
<RAOF> So, the source package doesn't _actually_ have to contain source code.
<RAOF> (Although if it wants to go somewhere official it obviously will)
<ubergoober> ok... im real confused now lol
<RAOF> So, a source package is basically just a way of describing how to turn something (_generally_, but not necessarily, source code) into a binary package.
<ubergoober> oh
<ubergoober> just wondering though... how would using the dh_shlibs call write the control file differently
<ubergoober> I've downloaded some other packages and looked at them. they are using that syntax (>=blah)
<RAOF> It won't change how the binary control file looks.
<RAOF> It would examine your binaries, work out what they're linked to, then work out what package provides that library, then add that as a depend of the binary control.
<ubergoober> so it _would_ write the Depends line for me then
<RAOF> Yes.
<ubergoober> curious to see what it would put in there
<ubergoober> I don't need source to use that?
<RAOF> Or, rather, it would take the ${shlibs:Depends} variable and substitute all the depends it knows about.
<RAOF> You need a source package, but not necessarily the source code for what you're packaging.
<ubergoober> sorry man. not sure what you mean by that?
<RAOF> (For example, we don't have the source code to the nvidia binary drivers, but there's a nvidia-glx package in the archive)
<ubergoober> would I need to make a source package then ?
<RAOF> So, a source package _isn't_ source code.
<ScottK-uds> The of source package as source of the .deb, not source code.
<ScottK-uds> The/Think
<ubergoober> ok
<ubergoober> sounds like I need to start over then
<ubergoober> there really is alot to this debian packaging thing
<RAOF> The packaging guide may well help you; it's obviously not optimised for the 'I don't have the source' case, but most of what it says should apply.
<ubergoober> alot more than I guest before I started lol
<RAOF> ubergoober: The answer to that is somewhere between yes and no :)
<ubergoober> lol gotta love that gray area
<RAOF> How complicated it is basically comes down to how much you want to follow Debian policy. :)
<ubergoober> just wish I could figure out the correct version info to put in the control file and it would be fixed
<ubergoober> I know its got to be just that one line that I'm getting wrong
<ubergoober> yeah thats whats complicated "the debian policy" very strict. Cant say I blame them though. makes for a quality product
<RAOF> Did I mention what the actual problem was yet?
<RAOF> Heh; I didn't, I got distracted :).
<ubergoober> I guess not
<RAOF> What you've been bitten by is a library transition.  There has obviously been some updates to the 'pq' library which have changed the ABI.  Thus the soname of the library has been increased by one, and that's what the number in 'libpq5' is; the soname of the library.
<ubergoober> ok
<ubergoober> listening
<ubergoober> the package works with that version though if I force the install
<ubergoober> so the correct symlinks are there then right?
<ubergoober> whats the ABI by the way?
<RAOF> Application Binary Interface.  The set of function signatures exported by the library, essentially.
<ubergoober> ah..
<RAOF> As compared to the API, which is subtly different.
<ubergoober> gotcha
<RAOF> (You can do all sorts of ABI breaking stuff without changing the API, but not visa versa)
<ubergoober> wonder why it reports that its a virtual package though instead of saying that libpq4 or whatever is just not available
<ubergoober> I thought a virtual package was for example "mail" which could be sendmail or postfix?
<ubergoober> wouldn't think that libpq4 would fall under that catigory
<ubergoober> sorry for my spelling by the way
<daskReech> Hello
<daskReech> will there be a release of the new Vbox for hardy ?
<ubergoober> hmmm..
<RAOF> ubergoober: It's 'virtual' in this case because it's depended on by something but isn't a real package :)
<ubergoober> sorry just want to make sure I'm clear. I realy apriciate your help by the way
<daskReech> RAOF: Oh a virtual packge :)
<ubergoober> so.. if I put in the control file Depends: noexistant-package
<daskReech> I was thrown for a loop I thought that you meant my virtualbox question :)
<ubergoober> then it would show up as noexitant-package is virtual
<ubergoober> I should try it actually
<ubergoober> thanks again for you help RAOF I need to hit the sack now. Have my real job in the morning.
<RAOF> Heh.  No problem.
<daskReech> RAOF: Any help with my question?
<RAOF> daskReech: Dunno.  Although, of course, new versions of apps almost never get added to a stable release.
<RAOF> That being part of our definition of 'stability'.
<daskReech> Yes but you do allow backports right? :)
<daskReech> and I think virtualization esp one with that many new features would be very good for busniesses
<daskReech> businesses
<daskReech> RAOF: Just to be clear it's not the choice of the maintainer if it goes into backports?
<RAOF> daskReech: Basically, something goes in backports if (1) Somebody cares about it enough to ask (in a bug) and (2) Enough people care enough about it to actually test the backport.
<daskReech> ok thanks
<emgent`UDS> heya
<fabbione> looks like UDS is awake
<\sh> fabbione, sounds like too many drinks last night? ;)
<fabbione> uh?
<fabbione> i am not at UDS
<\sh> fabbione, sad ;)
<fabbione> it's ok :)
<emgent> fabbione: o/
 * \sh wonders who is planning the smokers BOFs now ;)
<fabbione> \sh: ogra or benc.. i am sure they will be valid contributors to that bof :)
<fabbione> emgent: even if i wanted to come, i can't take holidays right now to be there
<\sh> emgent, damn...you miss the mighty fabbione
<fabbione> \sh: not anymore no... used to be "all mighty" ;)
<foka> Hi!  Is there a specific channel for UDS Intrepid?  :-)
<persia> foka: #ubuntu-devel-summit
<StevenK> I daresay.
<foka> persia, Many thanks!
<ScottK-uds> Although jono's slides say different.  He's behind.
<persia> The old name works too :)
<ion_> The Ubuntu CD came by mail. My phone number is still printed as 3,5844123456e+011 on the envelope. :-)
<sladen> ion_: classic!
<siretart> are the buildd chroots fixed? are uploads expected to build successfully again?
<StevenK> siretart: Soon.
<siretart> that translates to 'not yet'. ok
<infinity> siretart: Give it another 20 mins or so.
<infinity> siretart: I'm just waiting on the publisher.
 * siretart hugs infinity 
<asac> pitti: is it possible to copy from PPA to hardy-proposed?
<Mithrandir> asac: yes
<asac> Mithrandir: hi! ... how would that show up in launchpad? changelog probably wont have hardy-proposed
<asac> or does PPA accept hardy-proposed uploads?
<pitti> asac: yes, the source can be copied; but I only do it if it has a sane version number
<Mithrandir> asac: I don't think the PPA would accept hardy-proposed uploads, no.
<asac> pitti: sure
<asac> pitti: ah ok ... just source. then i dont think its worth it.
<pitti> asac: we won't copy binaries, since we can't ensure what they were built against
<asac> pitti: ok. thats what i assumed
<ligemeget> dholbach, where should I go seeking a little support for the Five-a-day package..?
<PecisDarbs> hi people, how can I test my firefox translation from Launchpad? How can I make xpi from given po file when I choose it to download?
<dholbach> ligemeget: you can file a bug on it http://launchpad.net/five-a-day/+filebug if you're facing problems
<infinity> Okay, chroots are all fixed now, and everything that wa sin chroot-wait has been given-back.
<soren> \o/
<StevenK> infinity: How many give-backs?
<infinity> StevenK: 490.
<StevenK> Niiiice
<ligemeget> dholbach, maybe I'm not.. I'm just curious as to why I haven't appeared on the stats yet..
<ligemeget> The manual submission command (via Terminal) said my login didn't exist, but the GNOME applet submitted it without problems. Strange, though..
<dholbach> ligemeget: then there's a problem with your login, hm - did you follow all the instructions on  http://wiki.ubuntu.com/5-A-Day ?
<ligemeget> dholbach, yes I did - I was unsure of whether my login is my username 'Lhademmor' or my emailadress?
<dholbach> ligemeget: what does http://launchpad.net/people/+me get redirected to in your browser?
<ligemeget> ~lhademmor
<dholbach> so that's your LP ID
<dholbach> lhademmor
<ligemeget> Hmm.. now the 5-a-day --add command tells me that I've already reported the given bug today - so maybe it has come through somehow...
<ligemeget> (strange, since my ~/.5-a-day is my emailadress..)
<ligemeget> But wth at least it apparently   works now - otherwise I'll continue to tingle with it :)
<dholbach> ~/.5-a-day shouldn't be your mail address
<dholbach> daniel@lovegood:~$ cat .5-a-day
<dholbach> dholbach
<dholbach> daniel@lovegood:~$
<ligemeget> HP-fan? :)
<dholbach> you could say that
<slangasek> soren: are you planning to take care of merging dpkg for this cycle?
<soren> slangasek: cjwatson's doing it.
<slangasek> ok. I ask because there's a bug on dpkg that's trivial to fix in SRU, but I don't want to get stuck as touched-it-last for intrepid ;)
<soren> slangasek: I believe cjwatson said he was basically done, so he's your man.
<liw> dholbach, ref my coreutils merge bug: which Steve are you referring to? (just curious)
<dholbach> liw: I subscribed Steve Langasek - it should be on the bug page
<liw> dholbach, ah, so it is; sorry, I'm new to this stuff
<dholbach> don't worry :)
<Tm_T> evand: hi
<evand> Tm_T: hello
<Tm_T> evand: this or next week I'm kicking seriously my project on, I might be poking you at times so be prepared ;)
<evand> Tm_T: will do :)
<Mirv> evand: if you have something I or you could write on https://wiki.ubuntu.com/Gobuntu , it'd help on the communication issue. I'm the one who's currently updated the news that "not yet available" and the daily snapshot is there (which I've tested installing from)
<asac> siretart: ok wpasupp synched i guess
<asac> well ... soonish ;)
<siretart> asac: \o/
<evand> Mirv: I'll be sitting down with Kurt in one of the break out rooms later in the week, you're welcome to join us, and I'll update the wiki page after that.
<Mirv> evand: yeah let's see, I'm leaving Thursday morning
<evand> noted
<emgent> cjwatson: thanks for debianutils :)
<luisbg> http://packages.ubuntu.com/ is down?
<DaBonBon> how do ubuntu apps like gdebi "interface" apt and python? i want to learn python, and i'm thikning of writing a frontend for apt.
<persia> DaBonBon: python-apt.  Look at update manager, the distupgrade component.
<Zic> DaBonBon: try to see python-apt
<Zic> oops, persia is too fast :)
<DaBonBon> persia: thanks, i was also looking at the gdebi source.
<DaBonBon> but isn't python-apt old and obsolete?
<DaBonBon> (i read so somewhere)
<DaBonBon> the last and only release was in 2000!
<DaBonBon> wow, ubuntu default has python-apt 0.7.4, but the last version released was 0.0.2. how come?!
<lamont> DaBonBon: huh?  define "released" because 0.0.2 is ancient
<DaBonBon> lamont: released as in upstream release here - https://launchpad.net/python-apt or here http://sourceforge.net/project/showfiles.php?group_id=2602
<lamont> DaBonBon: from which we can discern that the python-apt project on sourceforge has nothing to do with the package in debian/ubuntu
<lamont> see also http://packages.debian.org/python-apt
<lamont> given the lack of a hyphen in the version, it's a native package
<lamont> (that is, debian is upstream)
<DaBonBon> hyphen in the version? wow i learnt that today :)
<DaBonBon> if it's not a native debian/ubuntu project, there has to be a hpyhen SOMEWHERE In the version?
<DaBonBon> strange, there is no project page anywhere for python-apt
<DaBonBon> i wanted to learn it
<DaBonBon> persia_: do you know of some project page of python-apt where i can find some documentation on learning it?
<persia_> DaBonBon: I'm fairly sure such a page doesn't exist.  There's some examples in the python/ directory in the python-apt source.
<DaBonBon> persia: ok, thanks
<DaBonBon> the /usr/share/doc has some examples too, i'll check them out
<DaBonBon> why is this project so under-advertised? a python-apt bridge would be really useful to many people
<DaBonBon> anyway i'm off .. thanks for all the help, bye :)
<Keybuk> tkamppeter: it's not possible to schedule your meetings with the suggested people :-/
<tkamppeter_> keybuk, still there?
<tkamppeter_> Keybuk
<tkamppeter_> keybuk, ping
<fabbione> BenC: ping?
<BenC> fabbione: yo
<fabbione> BenC: dude can pass on the other channel please? we need a couple of info on silo :)
<fabbione> very offtopic here
<N00B> hi @all
<dudus> hi, someone can explain the process to include new mimetype icons by default? Don't know why but gnome-icon-theme doesn't provide mimetypes anymore.
<emgent> http://picasaweb.google.it/emgentili/UDSIntrepid
#ubuntu-devel 2008-05-20
<pwnguin> heh, yet another gentoo fork
<pwnguin> I love this one: things we find problematic with gentoo: "portage, management, developers, qa, users, and the lack of designers"
<jdong> pwnguin: lol isn't that the whole distribution
<jdong> pwnguin: head over to Ulteo too to learn about their innovative "application balls"
<jdong> pwnguin: in my sleep deprived state I've found that extremely amusing.
<pwnguin> it gets better
<pwnguin> http://kloeri.livejournal.com/5016.html
<pwnguin> they're ready to tackle the problems of gentoo, and also write yet another initsystem
<pwnguin> " * We're writing a completely new initsystem free of all the weird, useless legacy stuff and based on user needs in the 21st century."
<RAOF> work is ongoing on this topic [multilib] and there'll probably be huge changes but we have a fairly decent idea how to handle all the multi stuff sanely.
<RAOF> Heh.
<selckin>  not hurting anyone, let em try
<selckin> can't deny gentoo is a mess
<pwnguin> apparently sysvinit, initng, runinit, launchd, upstart, eINIT, SMF and so on wasn't up to task
<pwnguin> selckin: gentoo might be a mess, but I'm not sure they're going to actually clean anything up
<emgent> heya
<Q-FUNK> mornin'!
 * Q-FUNK just arrived in Prague
<pitti> Good morning
<soren> pochu: Hey.
<soren> pochu: Just to let you know, I'm doing  the gtk-vnc update now.
<pochu> soren: the sru?
<pochu> soren: thanks :)
<pitti> cjwatson: YokoZar proposed https://blueprints.edge.launchpad.net/ubuntu/+spec/killing-ia32-libs, which is quite toolchainish (multiarch); is there time/interest to discuss it this week?
<Amaranth> that spec is pretty empty
<soren> pochu: Yeah, sorry for the delay. Feel free to ping me more often I suck like this again :)
<YokoZar> Amaranth: I'll fill it out a bit, but the main issue is discussing how to kill ia32-libs since it needs to die and there are many ways we might kill it
<persia> YokoZar: Is there anything planned other than death-by-1000-cuts, as we modify each library otherwise included in ia32-libs?
<Riddell> tkamppeter: when and where are the printing sessions today?
<YokoZar> persia: Well making a bunch of packages a la lib32asound2 is one option, but pitti seemed to have other ideas about doing it more elegantly within the toolchain.  We've been waiting on multiarch for years, however.
<ScottK-uds> And AFAIK no one is actually working on multiarch.
<tkamppeter> Riddell, biff
<Riddell> tkamppeter: are the printing sessons scheduled yet?
<Riddell> not 11 to 13 for me, otherwise fine
<tkamppeter> Riddell, on the dialog we will then schedule an extra session. There we do not get everyone together at once, I go to one after the other and talk with hm ...
<tkamppeter> The dialog session is also very early, we cannot get Alexander Wauck to call in.
<tkamppeter> Keybuk, ping
<Riddell> oh, if I press F5 they're on the schedule
<Riddell> right, I can't do that 12:00 one
<Riddell> keybuk is busy running this desktop session
<tkamppeter> Riddell, I will ask Keybuk for another session today or tomorrow in the afternoon to get at least him and Alex together with me.
<tkamppeter> Im mixing up everything, let me retry
<tkamppeter> Riddell, I will ask Keybuk for another session today or tomorrow in the afternoon to get at least you and Alex together with me.
<Riddell> right
<alkisg> Hello everyone. I'd like to add some features to ldm (LTSP Display Manager), like user-sign-up feature for new students, a remote desktop button etc, but I don't want to "just fork". What is the proper way to do something like that?
<Riddell> alkisg: talk to ogra when he's online
<\sh> alkisg, talking to ogra
<tkamppeter> Riddell, are you in a session currently?
<Riddell> tkamppeter: yes
<alkisg> Thank you, I'll try to find him!
<tkamppeter> Riddell, have you 1pm today you have time to meet me informally, in the lobby, to talk about the dialog?
<tkamppeter> Or perhaps at lunch?
<Riddell> tkamppeter: yes, lunch is fine
<tkamppeter> Riddell, so come here to the Lobby of the third floor at 1pm and then we go to lunch together.
<pwnguin> if travis is is NotAmaranth, then that must mean...
<pwnguin> It's opposite day!
<Riddell> pwnguin: no it's not
<emgent> persia: i saw mail, Thanks :)
<pochu> soren: thanks! hope it doesnt break your virt* stuff :)
<soren> pochu: Me too :)
<emgent> tseliot: where are you now?
<tseliot> emgent: volga
<tseliot> kubuntu-kde4
<emgent> argh, is not for me :)
<saispo> hello, anyone known this error when you build a package ? (parsechangelog/debian: avertissement:     debian/changelog(l5743): fin de fichier trouvÃ©e, first heading attendu)
<james_w> saispo: you're debian/changelog probably has a syntax error
<wgrant> s/probably //
<james_w> if you pastebin it then we can help you fix it up.
<ln-> james_w: "you're" -> "your"
<saispo> james_w: grab the changelog from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=debian/changelog;h=3fb3f2de98cf665bf147b4511a727eb4af6ab2a2;hb=HEAD :)
<saispo> it's this changelog :p
<james_w> I can't see anything immediately.
<wgrant> Particularly not on line 5743.
<saispo> it's the end of the file :/
<saispo> after i do a debchange -i
<wgrant> Ah, so it's not that changelog.
<saispo> it's the same with a debchange -i, just that
<wgrant> Can you please translate that error?
<saispo> yes, with my english words
<saispo> parsechangelog/debian: warning: debian/changelog(l5743): end of file found, first heading waited)
<wgrant> Huh.
<saispo> wgrant: no idea ?
<wgrant> saispo: Does it work OK if you use that changelog without `dch -i`ing?
<saispo> don't try at this time, but i can, must waiting a long time for the build process :)
<saispo> wgrant: it's working...
<saispo> debchange -i don't work ??
<wgrant> saispo: It might have become confused at the format of that latest entry.
<wgrant> Check the diff between the old and new ones.
<saispo> ok
<saispo> thanks wgrant
<saispo> wgrant: i found why, thanks
<Keybuk> Keybuk's Wishlist #1 : ~/.local/share/hal/fdi
<sdh> cjwatson: ping?
<sdh> cjwatson: I mailed Matthew Veron, he tells me you're now openssh maintainer... so, incoming :)
<hiho-man> http://xrl.us/bkj9x
<tmmoyer> is there any place which describes how versions of packages are compared to determine if one package version is greater than the other?  or at least explains the different possible combinations of version that could appear on package?  The way I understand it, there are potentially 4 different numbers the upstream version, the debian build number, the ubuntu build number and a possible NMU version number (am I missing any?)
<tmmoyer> is there any place that describes the structure/rules of version numbers in ubuntu? the way I am currently understanding things, there are potentially 4 numbers the upstream, the debian, the ubuntu, and a non-maintainer upload version number is this correct?
<geser> tmmoyer: the debian policy manual describes the format of the version string and you can compare versions with "dpkg --compare-versions"
<broonie> tmmoyer: The Debian policy document (debian-policy package) describes the comparison function;
<geser> looks like it wasn't that important that he couldn't wait some minutes for an answer
<fabbione> BenC: silo pull request? :)
<dee> Hello Ubuntu-Devs.
<dee> Could someone tell me why Ubuntu Live is cancelled in June? Does anybody has some background information? Or are you just as clueless as I am? :(
<MacSlow> dee no clue
<N00B> hi
<dee> thx MacSlow. Maybe someone else knows more
<mok0> soren: ping
<wildcode> how do I find a maintainer of a particular package
<wildcode> specifically, who maintains the wildmidi package in ubuntu
<wildcode> I'm the author of WildMIDI and would like to see any patches ubuntu made to the original source
<beuno> wildcode, http://patches.ubuntu.com/ is a good place to look
<wildcode> thankyou
<wildcode> hmm, no patch ... does that mean no changes?
<beuno> wildcode, yeap
<wildcode> k, so who do I find out wh the maintainer is, so I can see if there is anything I can do to make their life easier ... apart from stop breaking the cvs source :)
<beuno> wildcode, https://launchpad.net/ubuntu/+source/wildmidi
<beuno> Uploaded By:  Emilio Pozuelo Monfort
<beuno> Maintainer:  Emmet Hikory
<beuno> wildcode, https://launchpad.net/ubuntu/+source/wildmidi/+publishinghistory
<wildcode> I appologize if I am being annoying, its judt I was supprised to see wildmidi in a distro specially since it was made out of curiosity
<beuno> wildcode, not a problem
<beuno> open source works that way  :)
<wildcode> :)
<Adri2000> wildcode: the package comes from debian and is not modified in ubuntu, so you should talk to the debian maintainer, Emmet Hikory, who is also an ubuntu developer by the way
<wildcode> hehe, no problem
<ScottK-uds> wildcode: His IRC handle is persia.  He is most often found on #ubuntu-motu, altough he's not there now.
<ScottK-uds> Urgh.  To slow.
<ispiked> when one presses volume keys on their keyboard, Ubuntu adjusts the volume... what code handles this? I've gotten as far as figuring out that it uses the X11 "XF86Audio*" commands, but I don't know what program/daemon handles those commands
#ubuntu-devel 2008-05-21
<kees> slangasek: can you (if you're the right person) do the gnutls13 merge?  (security issues are pending in it)
<Mithrandir> sigh, remote code execution in gnutls
<Mithrandir> we should just go back to using telnet and clear-text protocols.
<pwnguin> perhaps security programs should come with proofs
<slangasek> kees: blink; when are we switching to gnutls26?
<slangasek> because gnutls13 should optimally go away
<pitti> Good morning
<pitti> slangasek: we should already have it in intrepid
<slangasek> pitti: sure; question is, is it what we're linking against, or do we have a migration to finish?
<pitti> slangasek: oh, you mean because libgnuts-dev still points to 13? yeah, that's bad; I wonder why Debian did it that way
<pitti> hm, gnutls26 also builds libgnutls-dev
<slangasek> yes, but gnutls26 appears to be ftbfs in intrepid, right
<slangasek> I guess I saw that yesterday and have already forgotten :)
<pitti> aah
<pitti> slangasek: right, that's something we should fix with priority, to avoid having too many rebuilds later
<pitti> oh, depwait
<slangasek> yep, starting on it now
<pitti> guile-1.8-dev
<slangasek> mmm
<slangasek> pitti: question of main promotion vs. neutering the build-dep.  Your preference?
<pitti> guile 1.6 is in main
<pitti> so if we can obsolete this in favor of 1.8, that would be best IMHO
<slangasek> have you seen which packages use 1.6 currently?
<pitti> checking
<pitti> argh slow ssh
<pitti> slangasek: so, I'd be fine with promoting 1.8 now and filing a milestoned bug to transition away from 1.6
<pitti> it's just autogen, gnome-games, graphviz, and swig1.3
<pitti> slangasek: gnome-games is fine with 1.8, seb changed it to 1.6 in hardy because only that was in main
<slangasek> ok - shall I promote it now, or do you want any kind of paperwork first?
<pitti> nah, just a new version
<pitti> I'm fine with promoting it now
<pitti> slangasek: I'll file that milestone bug
<slangasek> great, thanks
<slangasek> guile-1.8 promoted
<pitti> slangasek: bug 232428
<ubottu> Launchpad bug 232428 in guile-1.6 "guile 1.6 -> 1.8 transition" [Undecided,New] https://launchpad.net/bugs/232428
<infinity> Are you guys going to want a mass-give-back after gnutls builds?
<pitti> infinity: I guess so far packages just built against gnutls13, so I don't think they actually FTBFSed? or did you notice that?
<infinity> pitti: Haven't really been watching like a hawk, to be honest, but I did notice that all my buildd queues are empty, which is usually a sign that something has gone horribly wrong. :)
<infinity> Failures build a lot faster than successes.
<infinity> (With the exception of mozart...)
<slangasek> infinity: libgnutls-dev already exists in intrepid but is the wrong version; feel free to mass-giveback, but I expect most are going to require fresh uploads for the transition
<infinity> slangasek: Kay, fair enough.
<Mithrandir> speaking of gnutls, are we going to see a security update for it soon?
<slangasek> Mithrandir: that's why we're speaking of gnutls ;)
<Mithrandir> ah, ok.
<liw> Mithrandir, hi
 * Mithrandir crawls back under his pebble.
<Mithrandir> hiya, Lars
<Mithrandir> how's Prague?
<liw> Mithrandir, looks very much like the inside of a hotel
<Mithrandir> you haven't seen much more of it?
<liw> nope
<slangasek> liw: should we drag you downtown tonight? :)
<liw> slangasek, I would not mind that, and tonight is probably the last chance of that
 * Hobbsee removes the pebble
<kees> Mithrandir: if you want to help, we've still got to do a backport of the upstream fix to dapper's gnutls12.  (i'm presently testing the feisty/gutsy/hardy fixes)
<fabbione> Keybuk: ping?
<Keybuk> fabbione: hi
<fabbione> Keybuk: hi
<Keybuk> how's it going, dude?
<fabbione> Keybuk: sorry to bother but i found a bug in libvolume-id-dev that's rather annoying :)
<fabbione> Keybuk: pretty good and you?
<fabbione>     |   |-- libvolume_id.so -> /lib/libvolume_id.so
<fabbione> ^^ broken symlink
<fabbione> in my specific case turns linking from shared to static
 * ogra heard the rumours ... congrats fabbione :)
<fabbione> not sure if it affects all other packages
 * ogra hugs fabio
<fabbione> ogra: rumors? my wife is not pregnant
<ogra> haha
<ogra> fabbione, i spent a few evenings with davidz the last days
<fabbione> Keybuk: afaict the bug is also in hardy
<fabbione> ogra: thanks tho.. we will see how this ride goes
<fabbione> Keybuk: do you prefer a bug in LP.. or are you already on top of it?
<ogra> heh, yeah, sounds like an intresting change
<Keybuk> fabbione: ?
<fabbione> well it's a totally different job
<Keybuk> oh, I see
<Keybuk> bug please
<fabbione> Keybuk: for the broken symlink
<fabbione> ok
<Keybuk> err
<Keybuk> wait
<Keybuk> that's fine isn't it?
<fabbione> err no
<Keybuk> /usr/lib/libbolume_id.so -> /lib/libvolume_id.so
<fabbione> there is no /lib/libvolume_id.so
<Keybuk> ah, d'oh
<Keybuk> ok, got it
<fabbione> Keybuk: can i just copy paste this from IRC?
<fabbione> i am lazy this morning :)
<Keybuk> sure
<fabbione> thanks
<fabbione> there is already one..
<fabbione> let see if it's the same
<atul_> Hi am using Laptop where sound is not working ?I check all sound related functionality and alsamixer all are fine ?
<fabbione> Keybuk: you win #232434
<Keybuk> thank you ;)
<fabbione> welcome :)
<emgent> heya
 * mneptok shoves fabbione playfully
<fabbione> mneptok: hey dude :)
<mneptok> \o/
<mneptok> fabbione: been to Westford yet?
<cody-somerville> Heya fabbione
<cody-somerville> Keybuk, who did you say I should speak with regarding the memory leak in notification-daemon?
<fabbione> mneptok: nope.. unlikely to go for a while
 * mneptok nods
<fabbione> cody-somerville: hi
<cody-somerville> \o_
 * cody-somerville slaps mneptok around the room a bit.
 * Hobbsee attacks you all with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!â¢
<emgent> hey
<mneptok> cody-somerville: you tease ;)
<Hobbsee> mneptok: don't get excited...
<Keybuk> cody-somerville: mvo
<Keybuk> or seb128
<seb128> is there a patch for the issue or that something to debugÂ§?
<Keybuk> something to debug
<cody-somerville> I had setup valgrind and let it run for several hours
<cody-somerville> but... then I shut off my laptop.
<seb128> I think there is a bug with a valgrind log already
<seb128> the issue is in the ubuntu theme
<seb128> just too many bugs, it's on my list already, but patches are welcome if somebody wants to speed things
<cody-somerville> seb128, I'll try working through it
<seb128> cool
<seb128> bug #67129 has several valgrind logs that can be useful
<ubottu> Launchpad bug 67129 in notification-daemon "notification-daemon using 237MB of memory" [Medium,New] https://launchpad.net/bugs/67129
<cody-somerville> mneptok, I know :P
<cody-somerville> Keybuk, wasn't there something else you said I should speak to mvo about?
<cody-somerville> seb128, can you take a look at this bug and clarify for the individuals who have recently commented what you feel is the most appropriate procedure?
<cody-somerville> IMHO, I would think that commenting on that bug would be the correct action since it doesn't make sense to file a new bug on a package for a version that isn't even uploaded to Ubuntu yet.
<seb128> cody-somerville: I don't know what your issue is exactly
<seb128> but if that's similar to this bug there is no need to add new comments
<cody-somerville> Oh, I forgot to post the bug number.
<cody-somerville> seb128, it is something completely different :)
<cody-somerville> seb128, https://bugs.launchpad.net/bugs/202174
<ubottu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Medium,In progress]
<seb128> I think I'm lost in this discussion now
<seb128> weren't we speaking about memory leak in notification-daemon?
<cody-somerville> seb128, Yes. :) Sorry if I wasn't clear in my transition to a different subject.
<cody-somerville> seb128, Where are you at? I can quickly come explain in person. I don't think I've actually met you yet so that would be nice to do anyhow.
<seb128> I'm sitting with the GNOME guys at the coffee tables
<ct529>  the new update seem to be broken, they have been broken since yesterday.
<ct529> the missing packages are apport apport-qt python-apport python-problem-report
<seb128> what new update?
<ct529> the automatic update does not find them, and if you check manually they are actually *not* there
<ct529> still, "apt-get update" outputs them as in need of upgrade
<ct529> what is going on?
<cody-somerville> seb128, raise your hands in the air and wave them all about?
<cody-somerville> : P
<cody-somerville> seb128, I'll catch you later. I have to go to Live CD memory requirements.
<fabbione> who is archive_admin of the day?
<seb128> cody-somerville: yeah, I didn't see you there and had to move to the next session now
<cody-somerville> I'm in the kernel session at the moment.
<seb128> fabbione: theorically me but we are at uds
<seb128> fabbione: so I'm slightly busy, is there anything you need?
<fabbione> seb128: hey.. nothing urgent.. i uploaded redhat-cluster to intrepid that spits out a bunch of new binaries that needs NEW love. all of them except redhat-cluster-source_2.20080521-0ubuntu1_all.deb needs to go in main. source and old binaries are already there
<fabbione> seb128: let me know if you prefer it in an email or a bug..
<fabbione> seb128: and it can wait when you have time
<seb128> fabbione: if it's in the NEW queue it'll be processed, no need to open a bug or send an email, I'll have a look later when I've a free slot
<fabbione> seb128: yeps.. cool. just wanted to make sure they were landing in the right place
<seb128> is there anything depending on those?
<fabbione> some of them yes, others no
<fabbione> but they will soon
<fabbione> there will be stuff depending on them soon (sorry)
<seb128> fabbione: ok, will accept those later, there is nothing in the queue yet, I guess you just uploaded and they need to build
<fabbione> seb128: indeed.. you are absolutely right :) as i said it's not urgent.
<seb128> ok, noted, will do that later
<fabbione> thanks a lot
<seb128> you're welcome
<Keybuk> sweet, new glibc in intrepid!
<\sh> oh no...new bugfox release...I really shouldn't take painkillers
 * Keybuk wants waitfd()
<desrt> Keybuk; what would waitfd() do?
<Keybuk> int waitfd (int fd, idtype_t idtype, id_t id, int flags)
<Keybuk> or something
<Keybuk> it would return a file descriptor
<Keybuk> read() on that file descriptor would return siginfo_t structures
<Keybuk> equivalent to those that waitid() would have returned, also clearing them from the queue
<desrt> oh
<desrt> that would be really nice!
<Keybuk> wait_fd = waitfd (...)
<Keybuk> signal_fd = signalfd (...)
<desrt> basically, so you can poll it....
<Keybuk> timer_fd = timerfd_create (...)
<Keybuk> select ()
<Keybuk> yup
<Keybuk> it's the only thing you can't do with poll/select/etc. now
<desrt> wouldn't work so good for all signals....
<Keybuk> it may even exist
<Keybuk> signalfd() exists already
<desrt> having to wait until you return to the mainloop to deal with SIGBUS wouldn't work so well :)
<Keybuk> right
<desrt> there's some timerfd stuff in the kernel these days too
<Keybuk> indeed
<soc> hi
<dbmoodb> you ah hi i'm wanting to know when you guys will patch the intel driver which is causing me and others using laptops a really bad experience (aka go to vt then back once or twice and the comp freezes... close the screen ditto... on reopen ... i'm asking here because i can't give out hardy cd's until a cd with this fixed in it is put out -- when is the next revision of hardy coming out ?....
<soc> gcc-4.2-base and libtotem-plparser10 cannot be updated since a few days ... is that correct or did i miss something?
<soc> removing gcc-4.2-base is not possible because many programs still depend on it ...
<soc> and the libtotem one needs an unavailable package, 'perlapi' or something like that
<dbmoodb> why is totem being given preference over gcc ?
<jdong> dbmoodb: is a bug filed already? (the devs are mostly at the UDS conference currently...)
<dbmoodb> it is filled
<jdong> soc: I've not observed that on either of my Hardy systems
<dbmoodb> oh i see jdong
<jdong> dbmoodb: what kind of hardware does this Intel bug affect (I run GMA950 with seemingly no problems doing VT switch)
<soc> jdong: oops, sorry, wanted #ubuntu+1 ...
<soc> sorry
<jdong> soc: haha that explains it
<dbmoodb> .... 855
<soc> :-)
<dbmoodb> one second let me find it
<jdong> dbmoodb: ah
<dbmoodb> apparently https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/211285 .... says i can fix it by adding a few options
<ubottu> Launchpad bug 211285 in xserver-xorg-video-intel "i855GM: blank screen after resume from suspend to ram, on Hardy" [Undecided,Confirmed]
<dbmoodb> they updated the bot ?
<dbmoodb> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/221316 if you want the page i was reading before
<ubottu> Launchpad bug 221316 in xserver-xorg-video-intel "[hardy] blank screen on 855GM when playing video using intel driver" [High,Triaged]
<dbmoodb> triaged means what -- being dealt with ?
<liw> dbmoodb, https://wiki.ubuntu.com/Bugs/Status
<jdong> dbmoodb: triaged means cause is understood, and possible the fix has been identified
<dbmoodb> in the bug report or in within the ubuntu maintainer group ?
<jdong> dbmoodb: it can only be set by the bug team or by developers
<jdong> dbmoodb: at this point I don't see why it's triaged, I think it was at one of the false-hope stages
<dbmoodb> apparently the ForceEnablePipeA instruction works
<dbmoodb> i will try it now
<jdong> dbmoodb: the "fix" in Debian doesn't really help us out all that much....
<dbmoodb> ah in debian experimental
<jdong> dbmoodb: it's just updating from 2.2.1 to 2.2.99.901 prerelease drivers... doesn't really identify any changeset as the problem
<dbmoodb> not in debian anything so far as i can tell
<jdong> dbmoodb: this is strictly out of the question for Hardy
<dbmoodb> oh really
<dbmoodb> so why is firefox beta 3 in
<dbmoodb> where did you guys get that from ?
<jdong> dbmoodb: but if someone can bisect between those two releases and figure out exactly which change is the fix...
<jdong> dbmoodb: ff3 is in because that was a design decision made at the beginnning of the hardy development cycle.
<dbmoodb> oh
<jdong> dbmoodb: i.e. around this time 6 months ago
<jdong> dbmoodb: we do accept beta software, but not upgraded after a release is done!
<dbmoodb> that is fine the fix you say is in debian
<jdong> dbmoodb: you can imagine, a lot of bugfixing work went into the 2.2.1 driver in Ubuntu; upgrading blindly to a new version might fix your problem but break something else
<dbmoodb> dude.. i don't think it has ever worked except in debian etch for my laptop ... lenny was ok
<jdong> dbmoodb: if you have some knowledge about compiling source debian packages, I'd suggest trying the experimental driver on Hardy
<dbmoodb> and even then --- etch wouldn't bring the screen back on all the time... - blank (black ) computer was still on and if i was in kde it worked .. i.e i could and did close the screen
<jdong> report back if it works or not
<dbmoodb> well i'm testing that one option
<jdong> dbmoodb: identifying a "working" version is definitely a first step towards finding the fix :D
<dbmoodb> i'm not compiling it for ubuntu i would remove it
<dbmoodb> jdong: the working version is many ago
<dbmoodb> i tend to think this is a bug in gnome power manager
<dbmoodb> -- will get kde now for a test
<dbmoodb> wait wtf i never told hardy to remember my password why did it just store my wpa one ?
<dbmoodb> i said no
<dbmoodb> i didn't put a gnome password vault up...
<dbmoodb> fix is a go
<dbmoodb> i can switch consoles
<emgent> heya
<dbmoodb> --- with that option
<dbmoodb> oh wow even better than a go it is a total fix i just closed the lid nice
<jdong> dbmoodb: that's good to hear :) Did you add that info to the bug report?
<Hobbsee> dbmoodb: not an ubuntu issue, but why am i getting multiple copies of mails?  please fix it.
<dbmoodb> Hobbsee: it so is
<dbmoodb> i'm on ubuntu right now
<Hobbsee> good.
<dbmoodb> and Hobbsee i want fixed to go upsteam these days not stay within ubuntu / debian
<dbmoodb> i don't want another openssl problem
<Hobbsee> then send them.
<dbmoodb> Hobbsee: multiple emails ?
 * Hobbsee wonders just how many people have that particular chipset, too
<dbmoodb> a lot .... it is an intel graphics chip on a dell laptop want to look at pop-con ?
<jdong> it's one of Intel's like 20 different graphics chipsets out there today....
<dbmoodb> it seems to be an error in bullet proof x configs jdong yes i am aware of that i think it affects a large number of them (laptops ) where acpi is used a lot more than the desktop
<Hobbsee> dbmoodb: mucs stuff.  nina should have spoken to you, that multiple people are getting mass mails.
<dbmoodb> oh
<dbmoodb> that stopped you might be getting one to kubuntu and ubutu
<dbmoodb> i can fix it
<dbmoodb> i thought i removed the old one we were a bit trigger happy on the last few emails ...
<Hobbsee> cool
 * Hobbsee got 6, iirc.
<dbmoodb> 6...  for which event ?
<Hobbsee> the monday night grad thing.
<dbmoodb> shouldn't have
<dbmoodb> that is weird
<dbmoodb> wait you got a few from the comp mailing list that we passed on to them ?
<Hobbsee> i think i did, but i didn't count them.
<yosch> ArneGoetje: link to  the BachoTex presentation about new XeTeX features: http://www.river-valley.tv/conferences/bachotex2008/
<siretart> StevenK: do you use backuppc on prodcution systems? - or other way round: are you familiar with the package?
<StevenK> I used to
<StevenK> Somewhat familiar
<siretart> StevenK: would you like to take over the merge from debian?
<StevenK> I did the 3.0.0 merge
<siretart> StevenK: I started on it, but I don't really understand all te ubunut changes in detail
<siretart> StevenK: if you want, I can tar up what I currently have, so you don't need to start from scratch.
<\sh> oh ... backup.../me still needs to fix some bacula bugs
<\sh> well...it's a good task during linuxtag
<StevenK> I played with bacula, it's fun
<\sh> StevenK, it's not when you use the mysql backend + the qt4 frontend...
<StevenK> siretart: I'll deal. :-)
<siretart> StevenK: thanks. do you want my merge directory?
<StevenK> siretart: I think I can cope without it
<siretart> ok
<\sh> StevenK, and the other thing: bacula without ssl sucks a lot
<StevenK> I've moved on from the company I was looking at bacula for, so shrug
<Auzy> hey.. I'm wondering if there is a way to get xdg-open to accept program arguments
<Auzy> so I can do xdg-open sh program.sh
<guysoft42> um, hello m does anyone here know who Michel Vogt is?
<Mithrandir> guysoft42: his nick is mvo, why?
<\sh> guysoft42, mvo
<guysoft42> Martinp23, because i want to ask him about DistUpgradeViewNoninteractive.py .. i need to run it somehow
<Auzy> or if there are any alternatives to xdg-open? I need to be able to open up any file, or command in a generic way
<Martinp23> Mithrandir: ^
<Mithrandir> Auzy: look at see?
<Auzy> hmm.. that does look better mithrandir
<Auzy> I'll give it a try now (its the only thing stopping my program being released)
<guysoft42> is there anyone here that knows maybe why  DistUpgradeViewNoninteractive.py exists, but its not really accessed by anything? and is it possible to use it somehow?
<Auzy> sweeet, you are a genius Mithrandir
<\sh> guysoft42, what software?
 * Auzy hugs system()
<Auzy> ahh, no.. crap, wont work Mithrandir, its just a viewer
<guysoft42> \sh, its  a part of the update manager. i basically want to run the update manager, and make it act non-interactive (like placing DEBIAN_FRONTEND=noninteractive ) . but no option exists in the code, apart from this file. i also tried fooling it and replacing it with the DistUpgradeViewGTK.py file, but that didnt help
<\sh> guysoft42, oh update-manager...the secret software desire of "please let me understands mvos logic here and there" ... yeah...you need mvo
<guysoft42> \sh, where can i find him? does he come here? for all i care i can give him a phone call, this is kinda important to me
<\sh> guysoft42, I think mvo is somewhere attending a session during UDS prague...
 * guysoft42 googles up UDS
<\sh> guysoft42, ubuntu developer summit
<\sh> guysoft42, most ubuntu devs and community devs are planning the intrepid release..so most of them are busy talking and writing
<guysoft42> \sh, well , for a start i can go looking at #ubuntu-devel-summit
<guysoft42> \sh, do you think it would be alittle out of order going there and asking "has anyone seen mvo?"
<cody-somerville> guysoft42, no
<Pici> guysoft42: try /whois mvo and /msg nickserv info mvo   looks like he was last on irc (or at least last identified) about a day ago
<guysoft42> he was here a day ago, but come to think if, it.. if there is someone on irc neaby him here, maybe he can call him to have a look
<joaopinto> He is at the UDS judging from a blog :P
<guysoft42> joaopinto, i know i was just told.. so i was aking now on #ubuntu-devel-summit if anyone knows where he is
<stgraber> guysoft42: if he's not on IRC that's probably because he's attending a session
<guysoft42> stgraber, he was here a day or so.. i am sure he is busy
<stgraber> UDS finishes at 18, maybe you can get it then before he goes out for dinner
<Daenyth> Hi, I know this isn't really the right place, but I thought that since ubuntu uses notification-daemon a lot, I might ask here... Does anyone know of a place to find help using notify-send in scripts?
<Daenyth> or just in general, tutorials, guides, or documentation?
 * Hobbsee wonders who she can bribe to do some work for her.
<Auzy> thanks all, got a workaround
<Nonel> /server globalirc.zapto.org
<Auzy> but I should send a patch in to xdg-open
<Keybuk> wing-commander scott% xargs
<Keybuk> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed.
<Keybuk> zsh: abort (core dumped)  xargs
<Keybuk> --
<Keybuk> that's bad, right? :)
<thom> possibly less than ideal
<ion_> setopt no_crash
<Keybuk> I assume that xargs is asserting that the maximum argv length isn't too large there?
<Hobbsee> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<Keybuk> intrepid libc => hold
<wd4lko> video is jerky on old dell gx260, should i buy a new videocard? what kind?
<guysoft42> \sh, why is the update manger pulling code it already has on in its package... thats what DistUpgradeFetcherCore.py is for..
 * guysoft42 is confused
<\sh> guysoft42, I already had two tries to understand the code...I failed badly...so I'll leave it to mvo to explain the secrets ;)
<guysoft42> \sh, and he is in Pruge.. and i need to solve this one as quick as possible
<ion_> guysoft: Just a guess: the version of update-manager in Ubuntu 15.04 might not have all the required stuff to properly upgrade to Ubuntu 15.10, so better fetch the most recent dist-upgrade code.
<guysoft42> \sh, i understand the code.. but its kinda strange
<guysoft42> ion_, yes, but then why keep in on the drive in the first place - so ill try and hack it and then see its not at all used
<PsySine> could someone give me a link to information on how the localized folder names in ~ are implemented?
<liw> PsySine, I don't have a ready link, but I think it's on freedesktop.org
<PsySine> thanks, i'll take a look
<ion_> The xdg-user-dirs{,-gtk} packages handle that AFAIU.
<siretart> soren: https://bugs.edge.launchpad.net/ubuntu/+source/qemu/+bug/144368
<ubottu> Launchpad bug 144368 in qemu "qemu fails to boot a disk image in gutsy" [High,Incomplete]
<guysoft42> ok, this is strange, this didn't work : ( while true; do export DEBIAN_FRONTEND="noninteractive"; done ) & sudo do-release-upgrade
<\sh> guysoft42, yuk...you won't get DEBIAN_FRONTEND inside your sudo shell imho
<guysoft42> \sh, hmm, let me try that
<\sh> guysoft42, I even wonder if export DEBIAN_FRONTEND="noninteractive" ; sudo -E do-release-upgrade works ...( -E is preserve env)
<guysoft42> \sh, doesnt seem to work :( , let me try your command
<guysoft42> \sh, sudo illedal option -e ??
<\sh> -E
<\sh>        -E  The -E (preserve environment) option will override the env_reset
<\sh>            option in sudoers(5)).
<Auzy> guys, is there something better then sourceforge out there?
<Auzy> I think sourceforge hates me :(
<guysoft42> Auzy, i know some developers that have trouble with SF go to berlios. i still personally use SF
<Auzy> I mean, I like the features, but sourceforge seems so danged slow
<guysoft42> \sh, maybe there is an internal sudo call within do-release-upgrade then
<guysoft42> \sh, that will mess  it up for me
<Auzy> each commit for even 1 file takes forever for me
<Auzy> might check berlios though
<\sh> Auzy, launchpad.net? :)
<Auzy> can u put code on launchpad?
<\sh> sure
<Auzy> meh, i'll check that out too I guess :D
<Auzy> thanks
<\sh> in bzr mode...and not SVN...
<Auzy> ahh ok, never used bazaar before, is there an eclipse plugin?
<Auzy> I know my plugin supports SVN and CVS
<\sh> Auzy, yes...but I don't know if it works...
<Auzy> anyway, I'll look into it
<Auzy> thanks
<beuno> Auzy, yes there is, and works quite well  :)
<Auzy> cool
<beuno> Auzy, http://bazaar-vcs.org/BzrEclipse
<Auzy> I'll look at options if I even know if this program will take off
<Auzy> if it wont, no point
<mjr> is preseeding broken on hoary, I don't seem to get joy from preseed/url=http://...
<mjr> s/hoary/hardy/
<hwilde> do-release-upgrade++   :)
<highvoltage> http://blog.rominet.net/2008/05/debianopenssl-debacle.html
<hwilde> pas de francais
<nikin> hy
<nikin> i realy need some some help in undersanding  policykit and cnsole kit.. i am searching someone ith deep understanding in how theese got inside ubuntu for a longer convrsation
<emgent> heya
<kirkland> can anyone point me to a correctly localized shell script in ubuntu as an example that I can work from?
<smallfoot-> why does Ubuntu use 'usplash' instead of 'splashy' ?
<mgunes> smallfoot-, basically because splashy breaks suspend in certain cases
<smallfoot-> oh
<smallfoot-> then they should fix that bug
<smallfoot-> hey plz make so that i can press "esc" in usplash to see boot messages
#ubuntu-devel 2008-05-22
<zyx386> hi
<zyx386> why ubuntu just with gnome is LTS?
<zyx386> :)
<Nafallo> zyx386: huh?
<zyx386> Nafallo, !
<zyx386> wb ALL
<sharms> zyx386 -  Ask in #ubuntu this is the wrong channel
<zyx386> ok sorry
<ls3> hi
<ls3> one question, my laptop got wifi, but lspci shows no wifi device, whats went wrong?
<ls3> using xubuntu here
<pwnguin> is the kill switch on?
<ls3> kill ?
<ls3> how to check?
<pwnguin> its a physical switch on the laptop
<ls3> the wifi switch is on, the FN + F2
<pwnguin> but this is really not the right place for a support conversation
<ls3> oh yeah, i forgot, i should go to #ubuntu instead of #ubuntut-devel
 * cody-somerville wonders how many developer channels ls3 will visit in his attempt to get his question answered.
<pwnguin> anyone know of a more modern frontend to graphviz than dotty?
<Keybuk> !
<fabbione> morning guys
* You're now known as ubuntulog
<lifeless> cjwatson: imp.find_module supports __path__ correctly
<StevenK> lifeless: What do you think about bug 230294?
<ubottu> Launchpad bug 230294 in bzr "ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit.KnitGraphIndex object at 0x86e1e2c> corrupt: attempt to add line-delta in non-delta knit" [Undecided,Confirmed] https://launchpad.net/bugs/230294
<lifeless> I think its fixed upstream and should have a new package done for hardy
<StevenK> lifeless: Well, I'm happy to sort out the SRU process, is it possible to have a small patch to 1.3.1?
<lifeless> StevenK: I don't know
<StevenK> lifeless: I'm just not sure about pushing bzr 1.4 into hardy-proposed
<lifeless> StevenK: 1.4 is tested; 1.3.1 with a patch is not
<StevenK> slangasek: Could you also poke at bug 230294?
<ubottu> Launchpad bug 230294 in bzr "ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit.KnitGraphIndex object at 0x86e1e2c> corrupt: attempt to add line-delta in non-delta knit" [Undecided,Confirmed] https://launchpad.net/bugs/230294
<sbeattie> kees: ping
<mantiena> hi all
<elmo> evand/hobbsee: ping?
<evand> elmo: pong
<mantiena> evand: hi, I've noticed your name in oem-config changelog, I've found, that there are no possibility to translate oem-config launcher (.desktop file) in translations.ubuntu.com, against which package I should report this bug ?
<evand> mantiena: oem-config
<mantiena> evand: thanks
<StevenK> Keybuk: Are you aware of a bug in Hardy that sets group to 'disk' for USB keys rather than plugdev?
<Keybuk> StevenK: err?
<StevenK> If you say "Use Firefox 3" like you did for the schedule, I'll be cranky. :-P
<Keybuk> I'm aware of the fact that disks are in the disk subsystem like they should be
<Keybuk> and that the plugdev group is not used
<Keybuk> I wouldn't use the term "bug"
<Keybuk> I'd use the term "ding-dong, plugdev is dead"
<StevenK> Keybuk: In Gutsy, USB key devices had a group of plugdev, which means normal users could deal with the block device. Now in Hardy, only root can.
<Keybuk> StevenK: assertion error
<Keybuk> In gutsy, USB storage devices were in the plugdev group
<Keybuk> "desktop" users were also in the plugdev group
<Keybuk> which meant that desktop users could fiddle with the disk
<Keybuk> In hardy, USB storage devices are in the disk group
<Keybuk> and ACLs are added for users on the foreground console
<Keybuk> which means that users who can actually plug in USB keys can fiddle with the disk
<Keybuk> regardless of their profile
<mantiena> evand: I've noticed line "X-Ubuntu-Gettext-Domain=oem-config" in oem-config-prepare-gtk.desktop file, isn't this line enough to appear in translations.ubuntu.com ?
<mantiena> cjwatson: hi
<mantiena> cjwatson: what you think about fixing bug 233949 before Ubuntu 8.04.1 LTS ?
<ubottu> Launchpad bug 233949 in oem-config "Can't translate launcher (.desktop) file at http://translations.ubuntu.com" [Undecided,New] https://launchpad.net/bugs/233949
<mantiena> it's safe to fix bug - just add one string to translations.ubuntu.com and regenerate new language-packs :)
<slangasek> StevenK: poke at it how?
<StevenK> slangasek: So, I'd like to fix it. Do you think bzr 1.4 is suitable at all, or I should beat lifeless for a patch?
<slangasek> StevenK: if resolving requires me to make a determination of whether 1.4 is suitable, it'll miss 8.04.1; best to hang lifeless upside-down by his feet and shake out a patch
 * StevenK grins
<mjr> so is ks the recommended way of doing automated installs nowadays, ie. should I just battle with that instead of preseeding?
<mantiena> mjr: sorry for disturbing, but could you tell me what is ks ?
<mantiena> I'm also interesting in automated installs
<mjr> kickstart, apparently there is hacked-up kickstart support in hardy
<mjr> ks has been previously used with redhat installs
<pwnguin> is that the pxe thing?
<mjr> pxe is just network boot
<mjr> but kickstart/preseeding are at their most useful with a network boto
<mjr> boot
<pwnguin> i had set up a few servers with a disc and a kernel option
<pwnguin> but its not automated =(
<mantiena> mjr: maybe some info about using kickstart for automated hardy installs could be found somewhere ?
<mjr> mantiena, in the wiki
 * mjr likes preseeding better but seems to be having trouble in hardy with that
<mjr>  more precise question: how do I preseed everything the installer wants; is there documentation?
<lool> soren: Hey, which branch of ubuntu-jeos is the one I should look at to get things in tip?  There's a trunk marked as "Mature" and an intrepid branch marked as "Development"; the later has the youngest commits
<soren> lool: Intrepid's the one you want.
<lool> soren: Could you have a look at the change in lp:~lool/ubuntu-jeos/intrepid?
<lool> soren: Ideally, I'd love to upload and use this now
<ivoks> http://www.informatik.uni-koeln.de/fai/
<ivoks> ups... :)
<\sh> ivoks: lol
<sivang> hmm, colin watson seems not to be around
<sivang> cjwatson: ah, actually there you are?
<\sh> hey sivang long time no see
<sivang> hey \sh how are you doing ?
<\sh> sivang: fine :) getting older, more sarcastic, so everything is in good shape :)
<sivang> \sh: as long as health is preserved, i guess so :)
<sivang> \sh: do you know whom I need to contact to renew my ubuntu-dev membership ?
<\sh> sivang: motu thing? the MOTU Council (motu-council@lists.ubuntu.com)
<sivang> \sh: ubuntu-dev is motu right, as opposed to ubuntu-dev-core which is main developers ?
<\sh> sivang: correct :)
<cody-somerville> not really
<cody-somerville> ubuntu-dev is ubuntu-dev-core AND ubuntu motu
<\sh> oh damn..yes
<sivang> huh ?
<sivang> when did this happen ?
<\sh> ubuntu-dev is now all
<sivang> aggregations of teams? :)
<sivang> okay, so if I were approved for universe, whom do i need to contact ?
<cody-somerville> simira, contact to do what?
<simira> cody-somerville: get your tab-completion right ;)
<cody-somerville> pfft ;p
<cody-somerville> sorry
<\sh> sivang: motu-council@lists.ubuntu.com
 * \sh goes and have some rest...
<sivang> \sh: k, thanks
<Hobbsee> elmo: pong
<Hobbsee> elmo: (what have i done?
<Hobbsee> )
<slangasek> pitti: is the "general case" of bug #210379 an SRU target for glib2.0?
<ubottu> Launchpad bug 210379 in glib2.0 "should not list mounts that the user doesn't have permission to use" [Low,In progress] https://launchpad.net/bugs/210379
<guysoft42> hey all, did any of you get a bug report gksu doesnt work after hardy update?
<pitti> slangasek: I'd like it to be, at least; it's annoying and confusing
<guysoft42> because the irony is that you can't use the update manger to update the packages.. becasue gksu doesnt work!
<pitti> slangasek: you get weird error messages popped into your face whenever someone else mounts something
<slangasek> pitti: ok, leaving the hardy bug state alone then
<pitti> slangasek: that's why I left it open, yeah
<emgent> heya
<lool> nijaba: ubuntu-vm-builder is broken for me because of set -e; could you check the latest revs (well or all revs) in lp:~lool/ubuntu-jeos/intrepid?
<lool> nijaba: TIA
<nijaba> lool: sure, thanks
<lool> nijaba: Blah, it's really broken /usr/bin/ubuntu-vm-builder: line 565: DESTINATION: unbound variable
<nijaba> lool: this is why the branch is experimental
<lool> So you don't run the experimental branch, just commit to it?
<lool> Anyway, fix pushed at same location
<lool> Actually runs debootstrap now
<nijaba> lool: yes I do, but apparently not with the same params you are, or I would have fixed it ;)
<lool> nijaba: Well ubuntu-vm-builder kvm hardy didn't work :)
<nijaba> lool: :/ really?
<lool> nijaba: really!
 * nijaba hides
<lool> Hmm I can't test full UME vms, I don't have enought space in /tmp
<lool> Now I really have to fix that using /tmp thing
<liw> lool, $TMPDIR isn't obeyed?
<lool> Urgh, ubuntu-vm-builder writes to a tmpfs
<lool> liw: Actually I thought my /tmp was full, but the tmpfs in /tmp was full, it defaults to half of my memory to 1.5GB
<ogra> lool, its a script, no ? you should be able to tweak paths
<lool> Naturally
<lool> ogra: What strikes me is that it probably means you can't run the script on 512 MB machines to bootstrap ubuntu
<asac> pitti: doko: could you give back xulrunner-1.9 for all archs in intrepid?
<asac> pitti: doko: sorry ... nevermind.
<ogra> lool, well, adding a switch to use the disk instead should be possible i suppose
<ogra> not sure how that affects speed then though
<lool> Would be cool to be able to disable journal and bump the commit interval for a bind mount
<lool> Well for a subdir rather
<tmmoyer> is there any method (short of unplugging the network cable) of forcing the installer (using preseeding) to prefer the packages on the CD, and only to retrieve packages from somewhere other than the CD only when the CD doesn't provide the package needed? I want to create an installer that has some custom packages and prefers these to what it can get from the repository
<Keybuk> lifeless: you know how bzr pull, push, merge, etc. have a --remember ?
<StevenK> Keybuk: You want --forget? :-)
<lifeless> Keybuk: yes?
<Keybuk> StevenK: yup
<Keybuk> lifeless: ^
<lifeless> Keybuk: patches etc
<Keybuk> lifeless: write one ;)
<lifeless> Keybuk: know where ted/mpt are?
<Keybuk> not in here
<evand> mneptok: http://technalign.blogspot.com/2008/04/where-we-are-and-where-were-going.html
<Foxandxss> hi
<scriptdevil> I read somewhere in the ubuntu wiki about a site where users upload their own packages, can anybody point that site to me?
<\sh> http://revu.tauware.de
<\sh> or you think about LaunchPAD personal package archives...
<lifeless> pitti: ping
<CarlFK> http://dev.personnelware.com/carl/temp/May21/a/hardy_install_error1.png  I think it should be able to give something better than ï»¿"failed for unknown reasons" - what package should I bug?
<ceekay> does 7.04 have the ability to write kernel crash dumps?
<ceekay> can't seem to find any hard evidence of when/if something like LKCD was integrated into ubuntu
<lifeless> pitti: bug 234101 and bug 234105
<ubottu> Launchpad bug 234101 in gdm "Support latin locale" [Undecided,New] https://launchpad.net/bugs/234101
<ubottu> Launchpad bug 234105 in langpack-locales "Support latin locale" [Undecided,New] https://launchpad.net/bugs/234105
<lifeless> pitti: for your consideration :)
<lifeless> CarlFK: ubuiquity I think offhand
<lifeless> CarlFK: oh, sorry, alt installer -
<lifeless> CarlFK: debian-installer is the root package
<CarlFK> lifeless: thanks
<emgent> heya
<jharr> I figured I'd poke someone in here about the gdm welcome message not being displayed in the Human theme.
<jharr> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/177745 - I posted a patch
<ubottu> Launchpad bug 177745 in gdm "Login Window Preferences: custom welcome message does not take effect." [Undecided,New]
<emgent> someone can active my ubuntu.com mail alias?
<stgraber> emgent: should be done automatically after a day or so, your main e-mail on LP will be where mails for your @ubuntu.com will end up
<emgent> stgraber: yeah, i know but alias now dont work
<emgent> i will wait :)
#ubuntu-devel 2008-05-23
<Randall> I have a request
<Randall> make your damn users less arrogant
<Lightkey> try #debian
<Randall> Genesis 1
<Randall> The Beginning
<Randall>  1 In the beginning God created the heavens and the earth.
<Randall>  2 Now the earth was [a] formless and empty, darkness was over the surface of the deep, and the Spirit of God was hovering over the waters.
<Randall>  3 And God said, "Let there be light," and there was light. 4 God saw that the light was good, and He separated the light from the darkness. 5 God called the light "day," and the darkness he called "night." And there was evening, and there was morningâthe first day.
<Randall>  6 And God said, "Let there be an expanse between the waters to separate water from water." 7 So God made the expanse and separated the water under the expanse from the water above it. And it was so. 8 God called the expanse "sky." And there was evening, and there was morningâthe second day.
<Randall>  9 And God said, "Let the water under the sky be gathered to one place, and let dry ground appear." And it was so. 10 God called the dry ground "land," and the gathered waters he called "seas." And God saw that it was good.
<Randall>  11 Then God said, "Let the land produce vegetation: seed-bearing plants and trees on the land that bear fruit with seed in it, according to their various kinds." And it was so. 12 The land produced vegetation: plants bearing seed according to their kinds and trees bearing fruit with seed in it according to their kinds. And God saw that it was good. 13 And there was evening, and there was morningâthe third day.
<Randall>  14 And God said, "Let there be lights in the expanse of the sky to separate the day from the night, and let them serve as signs to mark seasons and days and years, 15 and let them be lights in the expanse of the sky to give light on the earth." And it was so. 16 God made two great lightsâthe greater light to govern the day and the lesser light to govern the night. He also made the stars. 17 God set them in the expanse of the sky to give lig
<Randall>  20 And God said, "Let the water teem with living creatures, and let birds fly above the earth across the expanse of the sky." 21 So God created the great creatures of the sea and every living and moving thing with which the water teems, according to their kinds, and every winged bird according to its kind. And God saw that it was good. 22 God blessed them and said, "Be fruitful and increase in number and fill the water in the seas, and let th
<Randall>  24 And God said, "Let the land produce living creatures according to their kinds: livestock, creatures that move along the ground, and wild animals, each according to its kind." And it was so. 25 God made the wild animals according to their kinds, the livestock according to their kinds, and all the creatures that move along the ground according to their kinds. And God saw that it was good.
<ion_> You fail at paste.
<Randall>  26 Then God said, "Let us make man in our image, in our likeness, and let them rule over the fish of the sea and the birds of the air, over the livestock, over all the earth, [b] and over all the creatures that move along the ground."
<Randall>  27 So God created man in his own image,
<Randall>        in the image of God he created him;
<Randall>        male and female he created them.
<Randall>  28 God blessed them and said to them, "Be fruitful and increase in number; fill the earth and subdue it. Rule over the fish of the sea and the birds of the air and over every living creature that moves on the ground."
<Randall>  29 Then God said, "I give you every seed-bearing plant on the face of the whole earth and every tree that has fruit with seed in it. They will be yours for food. 30 And to all the beasts of the earth and all the birds of the air and all the creatures that move on the groundâeverything that has the breath of life in itâI give every green plant for food." And it was so.
<Randall>  31 God saw all that he had made, and it was very good. And there was evening, and there was morningâthe sixth day.
<Randall> Genesis 2 (New International Version)
<Randall> New International Version (NIV)
<Randall> Copyright Â© 1973, 1978, 1984 by International Bible Society
<Randall> [NIV at IBS] [International Bible Society] [NIV at Zondervan] [Zondervan]
<Randall> Genesis 2
<Randall>  1 Thus the heavens and the earth were completed in all their vast array.
<Randall>  2 By the seventh day God had finished the work he had been doing; so on the seventh day he rested [a] from all his work. 3 And God blessed the seventh day and made it holy, because on it he rested from all the work of creating that he had done.
<Randall> Adam and Eve
<ion_> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<Randall>  4 This is the account of the heavens and the earth when they were created.
<Randall>       When the LORD God made the earth and the heavens- 5 and no shrub of the field had yet appeared on the earth [b] and no plant of the field had yet sprung up, for the LORD God had not sent rain on the earth [c] and there was no man to work the ground, 6 but streams [d] came up from the earth and watered the whole surface of the ground- the LORD God formed the man The Hebrew for man (adam) sounds like and may be related to the Hebrew for gr
<Randall>  8 Now the LORD God had planted a garden in the east, in Eden; and there he put the man he had formed. 9 And the LORD God made all kinds of trees grow out of the groundâtrees that were pleasing to the eye and good for food. In the middle of the garden were the tree of life and the tree of the knowledge of good and evil.
<Randall>  10 A river watering the garden flowed from Eden; from there it was separated into four headwaters. 11 The name of the first is the Pishon; it winds through the entire land of Havilah, where there is gold. 12 (The gold of that land is good; aromatic resin [e] and onyx are also there.) 13 The name of the second river is the Gihon; it winds through the entire land of Cush. [f] 14 The name of the third river is the Tigris; it runs along the east 
<Randall>  15 The LORD God took the man and put him in the Garden of Eden to work it and take care of it. 16 And the LORD God commanded the man, "You are free to eat from any tree in the garden; 17 but you must not eat from the tree of the knowledge of good and evil, for when you eat of it you will surely die."
<Randall>  18 The LORD God said, "It is not good for the man to be alone. I will make a helper suitable for him."
<Randall>  19 Now the LORD God had formed out of the ground all the beasts of the field and all the birds of the air. He brought them to the man to see what he would name them; and whatever the man called each living creature, that was its name. 20 So the man gave names to all the livestock, the birds of the air and all the beasts of the field.
<Randall>       But for Adam [g] no suitable helper was found. 21 So the LORD God caused the man to fall into a deep sleep; and while he was sleeping, he took one of the man's ribs [h] and closed up the place with flesh. 22 Then the LORD God made a woman from the rib [i] he had taken out of the man, and he brought her to the man.
<Randall>  23 The man said,
<Randall>        "This is now bone of my bones
<Randall>        and flesh of my flesh;
<Randall>        she shall be called 'woman, [j] '
<Randall>        for she was taken out of man."
<Randall>  24 For this reason a man will leave his father and mother and be united to his wife, and they will become one flesh.
 * Pici goes to look for people on the access list
<Randall>  25 The man and his wife were both naked, and they felt no shame.
<Randall> Genesis 3
<Randall> The Fall of Man
<Randall>  1 Now the serpent was more crafty than any of the wild animals the LORD God had made. He said to the woman, "Did God really say, 'You must not eat from any tree in the garden'?"
<Randall>  2 The woman said to the serpent, "We may eat fruit from the trees in the garden, 3 but God did say, 'You must not eat fruit from the tree that is in the middle of the garden, and you must not touch it, or you will die.' "
<Randall>  4 "You will not surely die," the serpent said to the woman. 5 "For God knows that when you eat of it your eyes will be opened, and you will be like God, knowing good and evil."
<Randall>  6 When the woman saw that the fruit of the tree was good for food and pleasing to the eye, and also desirable for gaining wisdom, she took some and ate it. She also gave some to her husband, who was with her, and he ate it. 7 Then the eyes of both of them were opened, and they realized they were naked; so they sewed fig leaves together and made coverings for themselves.
<Randall>  8 Then the man and his wife heard the sound of the LORD God as he was walking in the garden in the cool of the day, and they hid from the LORD God among the trees of the garden. 9 But the LORD God called to the man, "Where are you?"
<Randall>  10 He answered, "I heard you in the garden, and I was afraid because I was naked; so I hid."
<Randall>  11 And he said, "Who told you that you were naked? Have you eaten from the tree that I commanded you not to eat from?"
<Randall>  12 The man said, "The woman you put here with meâshe gave me some fruit from the tree, and I ate it."
<Randall>  13 Then the LORD God said to the woman, "What is this you have done?"
<Randall>       The woman said, "The serpent deceived me, and I ate."
<Randall>  14 So the LORD God said to the serpent, "Because you have done this,
<Randall>        "Cursed are you above all the livestock
<Randall>        and all the wild animals!
<Randall>        You will crawl on your belly
<Randall>        and you will eat dust
<Randall>        all the days of your life.
<Randall>  15 And I will put enmity
<Randall>        between you and the woman,
<Randall>        and between your offspring [a] and hers;
<Randall>        he will crush [b] your head,
<Randall>        and you will strike his heel."
<Randall>  16 To the woman he said,
<Randall>        "I will greatly increase your pains in childbearing;
<Randall>        with pain you will give birth to children.
<tormod> someone had too much drugs at the uds parties?
<tormod> he started so well with that arrogant user thing, I was waiting for the point
<asdfg> Genesis 42
<asdfg> Joseph's Brothers Go to Egypt
<asdfg>  1 When Jacob learned that there was grain in Egypt, he said to his sons, "Why do you just keep looking at each other?" 2 He continued, "I have heard that there is grain in Egypt. Go down there and buy some for us, so that we may live and not die."
<asdfg>  3 Then ten of Joseph's brothers went down to buy grain from Egypt. 4 But Jacob did not send Benjamin, Joseph's brother, with the others, because he was afraid that harm might come to him. 5 So Israel's sons were among those who went to buy grain, for the famine was in the land of Canaan also.
<asdfg>  6 Now Joseph was the governor of the land, the one who sold grain to all its people. So when Joseph's brothers arrived, they bowed down to him with their faces to the ground. 7 As soon as Joseph saw his brothers, he recognized them, but he pretended to be a stranger and spoke harshly to them. "Where do you come from?" he asked.
<asdfg>       "From the land of Canaan," they replied, "to buy food."
<asdfg>  8 Although Joseph recognized his brothers, they did not recognize him. 9 Then he remembered his dreams about them and said to them, "You are spies! You have come to see where our land is unprotected."
<asdfg>  10 "No, my lord," they answered. "Your servants have come to buy food. 11 We are all the sons of one man. Your servants are honest men, not spies."
<asdfg>  12 "No!" he said to them. "You have come to see where our land is unprotected."
<soren> stfu
<asdfg>  13 But they replied, "Your servants were twelve brothers, the sons of one man, who lives in the land of Canaan. The youngest is now with our father, and one is no more."
<asdfg>  14 Joseph said to them, "It is just as I told you: You are spies! 15 And this is how you will be tested: As surely as Pharaoh lives, you will not leave this place unless your youngest brother comes here. 16 Send one of your number to get your brother; the rest of you will be kept in prison, so that your words may be tested to see if you are telling the truth. If you are not, then as surely as Pharaoh lives, you are spies!" 17 And he put them
<soren> !op
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<asdfg>  18 On the third day, Joseph said to them, "Do this and you will live, for I fear God: 19 If you are honest men, let one of your brothers stay here in prison, while the rest of you go and take grain back for your starving households. 20 But you must bring your youngest brother to me, so that your words may be verified and that you may not die." This they proceeded to do.
<asdfg>  21 They said to one another, "Surely we are being punished because of our brother. We saw how distressed he was when he pleaded with us for his life, but we would not listen; that's why this distress has come upon us."
<asdfg>  22 Reuben replied, "Didn't I tell you not to sin against the boy? But you wouldn't listen! Now we must give an accounting for his blood." 23 They did not realize that Joseph could understand them, since he was using an interpreter.
<asdfg>  24 He turned away from them and began to weep, but then turned back and spoke to them again. He had Simeon taken from them and bound before their eyes.
<asdfg>  25 Joseph gave orders to fill their bags with grain, to put each man's silver back in his sack, and to give them provisions for their journey. After this was done for them, 26 they loaded their grain on their donkeys and left.
<asdfg>  27 At the place where they stopped for the night one of them opened his sack to get feed for his donkey, and he saw his silver in the mouth of his sack. 28 "My silver has been returned," he said to his brothers. "Here it is in my sack."
<asdfg>       Their hearts sank and they turned to each other trembling and said, "What is this that God has done to us?"
<asdfg>  29 When they came to their father Jacob in the land of Canaan, they told him all that had happened to them. They said, 30 "The man who is lord over the land spoke harshly to us and treated us as though we were spying on the land. 31 But we said to him, 'We are honest men; we are not spies. 32 We were twelve brothers, sons of one father. One is no more, and the youngest is now with our father in Canaan.'
<asdfg>  33 "Then the man who is lord over the land said to us, 'This is how I will know whether you are honest men: Leave one of your brothers here with me, and take food for your starving households and go. 34 But bring your youngest brother to me so I will know that you are not spies but honest men. Then I will give your brother back to you, and you can trade [a] in the land.' "
 * Yvonne_ pokes PriceChild 
<asdfg>  35 As they were emptying their sacks, there in each man's sack was his pouch of silver! When they and their father saw the money pouches, they were frightened. 36 Their father Jacob said to them, "You have deprived me of my children. Joseph is no more and Simeon is no more, and now you want to take Benjamin. Everything is against me!"
<asdfg>  37 Then Reuben said to his father, "You may put both of my sons to death if I do not bring him back to you. Entrust him to my care, and I will bring him back."
<j-dizzle> it's soothing.
<asdfg>  38 But Jacob said, "My son will not go down there with you; his brother is dead and he is the only one left. If harm comes to him on the journey you are taking, you will bring my gray head down to the grave [b] in sorrow."
<asdfg> Genesis 43
<j-dizzle> in the lobotomy way.
<asdfg> The Second Journey to Egypt 1 Now the famine was still severe in the land. 2 So when they had eaten all the grain they had brought from Egypt, their father said to them, "Go back and buy us a little more food."
<asdfg> 3 But Judah said to him, "The man warned us solemnly, 'You will not see my face again unless your brother is with you.' 4 If you will send our brother along with us, we will go down and buy food for you. 5 But if you will not send him, we will not go down, because the man said to us, 'You will not see my face again unless your brother is with you.' "
<soren> PriceChild: Thanks.
<PriceChild> Haven't read up much on how ipv6 works yet so hope that works :)
<j-dizzle> PriceChild: oh you might've banned like 2^32 IP's but good enough ;-)
<Lightkey> requested? O.o
<j-dizzle> Lightkey: minitrue approve plusgood terminology.
<PriceChild> j-dizzle: oh yeah i know that's a lot i banned, just wasn't sure how dynamic stuff behaves, which bits change, whether its the same kind of idea as ipv4.
<Nafallo> hmm
<j-dizzle> I personally think it's a FloodBot job :)
<Nafallo> banned a /64 is looks like...
<j-dizzle> Nafallo: bleh ther'es plenty of bits to go around
<Nafallo> he.net's broker supplies /48s
<j-dizzle> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<j-dizzle> that's probably another one?
<Nafallo> hmmm
<Pici> Its muted anyway.
<j-dizzle> if we just mute every channel....
 * j-dizzle files a patent
<Nafallo> so ban allows users to join then?
<Seeker`> yes
<Seeker`> well, a ban with a % in the front does
<Seeker`> but they cant talk
<Nafallo> ah. it's one of the special bans.
<Seeker`> I think PriceChild banned 2^64 IPs
<j-dizzle> lol probably banned a few ISP's
<Nafallo> no
<Nafallo> probably didn't ban enough.
<Seeker`> Nafallo: ?
<Nafallo> it's hurricane electric. they supply users with /48s on their tunnel broker.
<Nafallo> /64 is banned.
 * nalioth calls the j-dizzle in #ubuntu-devel 
<j-dizzle> nalioth: yes sir?
<ScottK-uds> Nafallo: /64 in IPv6 is the same (sort of) as banning a single IP in IPv4.
<nalioth> just paraphrasing the bot, j-dizzle
<Seeker`> Quite an interesting story asdfg was posting. I wonder how it ends
<j-dizzle> nalioth: ah :)
<Nafallo> ScottK-uds: yes. my point is the user is likely to have the /48 on the tunnel :-)
<ScottK-uds> Nafallo: Right.  I'd tend to guess that /48 is to a sub provider and he should have just he /64 as an individual user (in theory anyway - that's how it was designed)
<Nafallo> ScottK-uds: http://tunnelbroker.net/index.php
<\sh> is it still so slow?
<ScottK-uds> Dunno.  I'm not actually running it.  I just know about IPv6 cidr math because of an app I was writing that had to get cidr matches right in both IPv4 and IPv6.
<\sh> the last time I used a ipv4 <-> ipv6 tunnel...it was slow like hell...
<\sh> (for private stuff)
 * Nafallo should get IPv6 deployed now that he has a fast enough server to act as router.
<ScottK-uds> Why bother unless you don't have enough IP addresses?
<Nafallo> because I like new technology
<\sh> Nafallo: use a bloody ipv6 enabled router ;) not a server as router ;)
<ScottK-uds> OK.
<Nafallo> I'm pretty sure I have enough IPv4 :-P
<Nafallo> \sh: buy it for me and pay for the colo :-P
<\sh> Nafallo: gnarf...
<\sh> as long you don't do it for company business you can stay with RIPE private addresses ;)
<Nafallo> anyway. one of my transits are a sixxs endpoint :-)
<\sh> 192.168.x.y
<\sh> that's enough for you ;)
<Nafallo> \sh: have enough IPv4 as I said :-)
<Nafallo> both PI and PA
<Seeker`> IPv6 addresses are a pain to remember
<\sh> Seeker`: that's why the great internet god invented the DNS
<\sh> holy DNS
<Nafallo> also... dead:beef
<ScottK-uds> Nafallo and \sh: Did you know whe have a python extension that adds a special data type for CIDR and does all the CIDR math for you in the archive?
<Nafallo> ScottK-uds: nope :-)
<Seeker`> \sh: It is still useful to be able to remember IP addresses
<Nafallo> Seeker`: I remembered my linknets :-)
<\sh> Seeker`: yes..for this I always have my notepad (I mean the real one...paper) or my visio topo map
 * Nafallo shows Tomboy to \sh  ;-)
<\sh> Nafallo: nah....computer dead...tomboy dead too
<\sh> Nafallo: we have a database for this...
<ScottK-uds> https://launchpad.net/ubuntu/+source/pysubnettree
<Nafallo> for Tomboy notes?
<\sh> Nafallo: but all of us are using notepads
<\sh> Nafallo: no...ip address mappings to interfaces, machines etc.
<Nafallo> ah
<Nafallo> DNS ;-)
<ScottK-uds> It's a thin Python wrapper on some C, so it's pretty fast.
<\sh> Nafallo: asset management via ldap which could create also DNS records, if we have time to improve it...
<Nafallo> ya
<\sh> but now for something totally different
 * \sh wants to test powerdns
<\sh> so as I understand: recursor version is the resolver part for outside dns querying?
<Nafallo> \sh: what we would call a caching nameserver normally.
<Nafallo> whereas the server part is authoritive nameserver
<\sh> Nafallo: well, it should cache when I say so it should cache...;)
<\sh> damn...we are old
<Nafallo> ?
<\sh> Nafallo: the version in hardy is already old
<Nafallo> ah
 * Nafallo prefers bind anyway
<\sh> Nafallo: me too...but I want to see if the webfrontend to powerdns is actually useable
<Nafallo> not really
<Nafallo> but then again... I tend to dislike web frontends
<\sh> yeah..forget pdns..
<sladen> soren: http://www.paul.sladen.org/ubuntu/upload/ubuntu-vm-builder_0.4-0ubuntu0.1-sladen1.debdiff
<mluser-home> How do I upgrade hardy to the new development version?
<gnomefreak> mluser-home: update-manager -d  and this should be asked in #ubuntu+1 and its not advised you upgrade yet as it will most likely give you alot of issues since gcc-4.2 adn perl are broken atm if you do a dist upgrade it likely to remove everything that needs perl or gcc4.2
<mluser-home> gnomefreak: thanks, I have an extra partition that I'll be using for this.. I dont really care if it breaks.  Just want to keep an eye on the latest development efforts.  Thanks :)
<gnomefreak> mluser-home: you might want ot wait until perl is worked out upgrading them causes something like 50 packages for me to be removed one being most important is irssi for me
<mluser-home> gnomefreak: thanks for the advice, I'll probably wait a week or two then
<gnomefreak> anyone have a bug or status on perl hold backs? im sure its just something that needs a respin but im guessing since that wasnt done that there is a problem with it?
 * gnomefreak didnt relize zchat was dependant on perl
<gnomefreak> realize even
 * cody-somerville wonders how long we should keep the security notice re: SSH pinned at the top of the fridge's front page.
<geser> gnomefreak: I'm helping with the perl transition, it's primarily to figure out in which order the *-perl packages needs to get build. But I got slowed down a little bit as I'm waiting for some -perl packages to get synced which blocks a large part
<gnomefreak> geser: ah ok thanks
<pitti> Good morning
<pitti> lifeless: pong
<lifeless> pitti: yo
<pitti> lifeless: argh latin locales argh? that sounds like a WONTFIX
<lifeless> pitti: patches attached
 * pitti looks at the bugs
<lifeless> pitti: gdm and locales have esperanto, latin is no stranger
<pitti> lifeless: ah, *this* Latin :)
<pitti> lifeless: I thought it was about providing latin* encoded locales
<pitti> lifeless: that's great, thanks!
<Keybuk> cody-somerville:
<Keybuk> +       // FIXME: potential mem-leak?
<Keybuk> +       GtkStyle *style = gtk_style_copy(gtk_widget_get_style(fake));
<Keybuk> so, someone got as far as realising that they were leaking memory
<Keybuk> BUT NOT AS FAR AS FIXING IT! :)
<slangasek> MD5_Update(buf, style);
<pitti> lifeless: they need to be converted to a proper debian/patches/ patch and sent upstream, but I can deal with that (unless you beat me to it)
 * cody-somerville was just about to download the source.
<Keybuk> cody-somerville: see if you can fix it ;)
<Keybuk> cody-somerville: if you install notification-daemon-dbgsym from ddebs.ubuntu.com and run notification-daemon under massif again, you'll get the actual relevant function names rather than just "in ubuntu.so"
<cody-somerville> Keybuk, aye.
<geser> Hi pitti
<pitti> hey geser
<lifeless> pitti: if you could, that would be cool
<lifeless> pitti: I was entirely cargo culting here, my irst time fiddling with locale stuff
<pitti> lifeless: sure; I assigned the bug to me, I'll get to it soon
<lifeless> thanks!
<lifeless> pitti: bugs surely ? :)
<pitti> lifeless: right
 * soren sighs
 * cody-somerville pokes soren in the tummy.
<soren> Could an archive admin please REJECT ubuntu-vm-builder 0.4-0ubuntu0.2?
 * soren stomps on cody-somerville's foot
<StevenK> soren: To hardy-proposed?
<StevenK> Keybuk: So, I get permission denied reading from /dev/sdb
<StevenK> Keybuk: How can I check this ACL?
<Keybuk> getfacl
<soren> StevenK: Yup.
<pitti> soren: *flush*
<StevenK> Keybuk: No ACL on /dev/sdb
<slangasek> StevenK: what is /dev/sdb?
<StevenK> slangasek: A 1GB USB key
<slangasek> and you're logged in to a GNOME desktop on this system?
<StevenK> I am
<slangasek> want to bring me the USB key, so I can confirm it's not an issue with the USB detection?
<StevenK> Sure. You're next door in Oder?
<slangasek> platform, yes
<ogra> Keybuk_, http://people.ubuntu.com/~ogra/hardy-20080523-1.png
<ogra> 19secs
<ogra> (fiddling with the depmod)
<StevenK> pitti: So, the issue with USB keys is the ACL isn't getting added. PolicyKit screwing up?
<pitti> StevenK: do you have a ConsoleKit session? (ck-list-sessions)
<StevenK> Yup
<StevenK> pitti: Happy to dig, just need some pointers of where to start with the shovel
<pitti> StevenK: ck-list-sessions is a good start
<pitti> StevenK: but frankly, I'm not even sure whether we currently assign ACLs to USB block devices
<pitti> StevenK: I'm just certain for scanners and cameras (PtP, not mass-storage)
<slangasek> pitti: evidently not, I'm able to reproduce the issue here
<slangasek> pitti: I think they just get magically auto-mounted without bothering to set an ACL
<pitti> right, so it seems we just don't do it
<slangasek> (which is, after all, the common use case)
<pitti> (right)
<Hobbsee> ffs.  stupid trolls.
<lifeless> ?
<Hobbsee> lifeless: people deciding to put in a whole bunch of genesis, pasted into this channel.
<lifeless> oh, I didn't see it, muste be someone I have ignored
<Q-FUNK> is there any page on e.g. LP where we can see the queue order for the hardy-proposed buildd?
<gnomefreak> Q-FUNK: yes buildfarm i just cant remember the links to them (atleast there used to be)
<lifeless> james_w: ping; sabdfl is looking to chat
<Q-FUNK> gnomefreak: found it. seems the package was done 3 hours ago. I'm just wondeirng when it will be installed.
<gnomefreak> what package?
<gnomefreak> please dont say firefox
<Q-FUNK> xserver-xorg-video-geode
<Q-FUNK> fire...sucks
<gnomefreak> ah good :)
<Q-FUNK> :)
<Q-FUNK> bryce, ogra and I are just waiting for this to be installed to be able to debug with real hardware.
<Q-FUNK> ogra: package built successfully 3 hours ago, but still not installed.
<asac> crimsun: ping
<anujalabot> hi
<asac> crimsun: can you give me a brief update on the idea of the resurrection of libflashsupport
<anuj4ubuntu> I am new bee and I really want to clear my fundamentals for Ubuntu/Linux as I am training to become admin for ubuntu servers
<anuj4ubuntu> Pl advice if there free books /Guides on net which i can go through
<bryce_> slangasek: when you get a break, timo and I would like to chat with you about the xserver version in hardy
<andrew_sayers> anuj4ubuntu: I'm sure there must be.  You'd probably have more luck asking in #ubuntu though.
<asac> crimsun: point is i tried flash 10 like 5 days ago with libflashsupport => crash
<asac> so please clarify
<slangasek> bryce_: madness, I say
<bryce_> slangasek: but it's a thin minty stability xserver release :-)
<anuj4ubuntu> hi please suggest me free online books of ubuntu/linux as i am new in this
<anuj4ubuntu> i am really interested for leaRNING LINUX
<anuj4ubuntu> PLZ SUGGEST ME SOME GOOD BOOKS
<sads> Joshua 3
<sads> Israel Crosses the Jordan
<sads>  1 Then Joshua rose early in the morning; and they set out from Acacia Grove[a] and came to th Jordan, he and all the children of Israel, and lodged there before they crossed over. 2 So it was, after three days, that the officers went through the camp; 3 and they commanded the people, saying, .When you see the ark of the covenant of the LORD your God, and the priests, thee Levites, bearing it, then you shall set out from your place 
<sads> 5 And Joshua said to the people, .Sanctify yourselves, for tomorrow the LORD will do wonders among you.. 6 Then Joshua spoke to the priests, saying, .Take up the ark of the covenant and cross over before the people..
<sads> So they took up the ark of the covenant and went before the people.
<sads> 7 And the LORD said to Joshua, .This day I will begin to exalt you in the sight of all Israel, that they may know that, as I was with Moses, so I will be with you. 8 You shall command the priests who bear the ark of the covenant, saying, .When you have come to the edge of the water of the Jordan, you shall stand in the Jordan...
<sads> 9 So Joshua said to the children of Israel, .Come here, and hear the words of the LORD your God.. 10 And Joshua said, .By this you shall know that the living God is among you, and that He will without fail drive out from before you the Canaanites and the Hittites and the Hivites and the Perizzites and the Girgashites and the Amorites and the Jebusites: 11 Behold, the ark of the covenant of the Lord of all the earth is crossing over 
<sads> 14 So it was, when the people set out from their camp to cross over the Jordan, with the priests bearing the ark of the covenant before the people, 15 and as those who bore the ark came to the Jordan, and the feet of the priests who bore the ark dipped in the edge of the water (for the Jordan overflows all its banks during the whole time of harvest), 16 that the waters which came down from upstream stood still, and rose in a heap ve
<cpufreak> thanks
<[reed]> thanks
<infinity> Keybuk: Too slow. :P
<[reed]> team effort, woo!
<Pici> again...
<StevenK> Twitch
<StevenK> Interesting how it's IPv6
<Keybuk> well, someone has to use it
<infinity> Only Christians, apparently.
<StevenK> Haha
<Keybuk> IPv6 is the protocol of GOD
<StevenK> Who are driven to paste bible quotes into -devel
<tjaalton> anuj4ubuntu: maybe no-one knows about free online books here.. try #ubuntu
<[reed]> well, we've had the same thing happen on moznet, but the quotes eventually turn into GNAA propaganda
<infinity> The sabdfl suffereth no propaganda in Ubuntu channels, save it be that of Free Software.
<infinity> Amen.
<Keybuk> ITYM Open Source
<sabdfl> YOU CALLED?
<Darklock> hey \[reed\] :-)
<[reed]> Darklock: Hi.
<infinity> sabdfl: I think that needed a puff of smoke or something to be more impressive.
<sabdfl> infinity: a puff of smoke came out of my caps-lock key, does that count?
<infinity> sabdfl: I suppose it'll have to do.
<infinity> sabdfl: As dieties go, this seems somewhat ghetto.  I'll buy you a robe or something next conference.
<infinity> deities, too.
<sabdfl> i'd love to meet the dietie deity, and the tie-die deity too
<sabdfl> +1 on the mo' bling front, too
<sladen> more bling.  You want *mooore* bling.
<sladen> I don't know want to suggest, sprinkling the CDs with gunpowder and magnesium so that the use is user is treated to fireworks on first use
<tjaalton> just pop them in a microwave oven, that's blingy ;)
<davmor2> sladen: Only on the condition that we perfect the firework art on your machines ;)
<j-dizzle> exec kinit -R
<j-dizzle> grr not you.
<j-dizzle> crap. 3hrs too late.
<davmor2> How about a gold leaf "Powered by Ubuntu" sticker for your pc's
<thom> sabdfl: is bdale not the tie-die deity?
<sabdfl> thom: you have a point there
<sabdfl> that might make keithp the diet-y deity
 * Hobbsee waits for the lunatic to come bakc.
<Hobbsee> (when he does, please ban on sight)
<jdavies> Hobbsee: to bad I can do naught
<Hobbsee> jdavies: poke thom
<jdavies> I think you just did
<thom> Hobbsee: eh?
<yao_ziyuan> ï»¿i suggest that ubuntu set firefox's default sans, serif and mono fonts as bitstream vera ones
<ion_> No, better use the fontconfig aliases.
<Festor> #461774
<foka> Hi!  Is there a way to "Unsubscribe someone else" whom I accidentally subscribed to a bug report?  Thanks!
<sistpoty> foka: no, cf. bug #633
<ubottu> Launchpad bug 633 in malone "Malone doesn't let me unsubscribe a subscriber" [Low,Confirmed] https://launchpad.net/bugs/633
<foka> sistpoty, Many thanks!
<sistpoty> foka: you're welcome ;)
<minterior> I'm having problems with recent ubuntu-server upgrade (from 6.06 to 8.04). My system hangs on reboot after init-bottom init script. Anyone knows how to fix it?
<minterior> I've read that this is a bug, but I don't know how to fix it
<pwnguin> how big is an ubuntu mirror in disk space these days?
<pwnguin> 170GB?
<jdavies> pwnguin: more, lots more (by what elmo says)
<jdavies> pwnguin: you may wish to try asking in #ubuntu-mirrors
<pwnguin> jdavies: ah, well the mirrors page says 170
<CarlFK> jdavies: why do you ask?
<CarlFK> er, not you.... pwnguin
<jdavies> CarlFK: I think you mean pwnguin :)
<CarlFK> yeah yeah - iz confused
<pwnguin> CarlFK: well, some RTpatch idiot wrote me to say apt-rsync would be fine if i just un ar'd the deb, decompressed the tarballs and then untarred that
<pwnguin> even at "only" 170GB, that's gotta be massive
<CarlFK> im pretty sure I don't want to know any more :)
<CarlFK> is there a way to tell the alt installer to use 'basic 80x25 text' and not whatever graphics based text thing it seems to do?
<minterior> I'm having problems with recent ubuntu-server upgrade (from 6.06 to 8.04). My system hangs on reboot after init-bottom init script. Anyone knows how to fix it?
<minterior> I've read that this is a bug (https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/116727), but I don't know how to fix it
<ubottu> Launchpad bug 116727 in mdadm "mkinitramfs with raid makes an unbootable image" [Undecided,Confirmed]
<ScottK-uds> minterior_: This is a channel for development only (see /topic).  Help for Ubuntu server is in #ubuntu-server although this is not a particularly good time of day for it.
<[reed]> is there a way to search bzr branches for text?
<[reed]> like, I have a phrase I want to find where it's located in (a) branch(es)
<[reed]> is there a way?
<ScottK-uds> I think there is a #bzr channel that would be a good place for such a question.
<[reed]> well, it's not a bzr-specific question... it's more of a launchpad question
<[reed]> but I can try there...
<ScottK-uds> Then #launchpad
<[reed]> Thanks.
#ubuntu-devel 2008-05-24
<jikl> Joshua 2
<jikl> 1And Joshua the son of Nun sent out of Shittim two men to spy secretly, saying, Go view the land, even Jericho. And they went, and came into an harlot's house, named Rahab, and lodged there.
<jikl> 2And it was told the king of Jericho, saying, Behold, there came men in hither to night of the children of Israel to search out the country.
<jikl> 3And the king of Jericho sent unto Rahab, saying, Bring forth the men that are come to thee, which are entered into thine house: for they be come to search out all the country.
<jikl> 4And the woman took the two men, and hid them, and said thus, There came men unto me, but I wist not whence they were:
<jdong> dear lord....
<jikl> 5And it came to pass about the time of shutting of the gate, when it was dark, that the men went out: whither the men went I wot not: pursue after them quickly; for ye shall overtake them.
<jdong> (no pun intended)
<jikl> 6But she had brought them up to the roof of the house, and hid them with the stalks of flax, which she had laid in order upon the roof.
<jikl> 7And the men pursued after them the way to Jordan unto the fords: and as soon as they which pursued after them were gone out, they shut the gate.
<jdong> PriceChild...
<jdong> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<jikl> 8And before they were laid down, she came up unto them upon the roof;
<jikl> 9And she said unto the men, I know that the LORD hath given you the land, and that your terror is fallen upon us, and that all the inhabitants of the land faint because of you.
<jikl> 10For we have heard how the LORD dried up the water of the Red sea for you, when ye came out of Egypt; and what ye did unto the two kings of the Amorites, that were on the other side Jordan, Sihon and Og, whom ye utterly destroyed.
<jikl> 11And as soon as we had heard these things, our hearts did melt, neither did there remain any more courage in any man, because of you: for the LORD your God, he is God in heaven above, and in earth beneath.
<jikl> 12Now therefore, I pray you, swear unto me by the LORD, since I have shewed you kindness, that ye will also shew kindness unto my father's house, and give me a true token:
<jikl> 13And that ye will save alive my father, and my mother, and my brethren, and my sisters, and all that they have, and deliver our lives from death.
<jikl> 14And the men answered her, Our life for yours, if ye utter not this our business. And it shall be, when the LORD hath given us the land, that we will deal kindly and truly with thee.
<jikl> 15Then she let them down by a cord through the window: for her house was upon the town wall, and she dwelt upon the wall.
<jikl> 16And she said unto them, Get you to the mountain, lest the pursuers meet you; and hide yourselves there three days, until the pursuers be returned: and afterward may ye go your way.
<jikl> 17And the men said unto her, We will be blameless of this thine oath which thou hast made us swear.
<jikl> 18Behold, when we come into the land, thou shalt bind this line of scarlet thread in the window which thou didst let us down by: and thou shalt bring thy father, and thy mother, and thy brethren, and all thy father's household, home unto thee.
<jikl> 19And it shall be, that whosoever shall go out of the doors of thy house into the street, his blood shall be upon his head, and we will be guiltless: and whosoever shall be with thee in the house, his blood shall be on our head, if any hand be upon him.
<jikl> 20And if thou utter this our business, then we will be quit of thine oath which thou hast made us to swear.
<jikl> 21And she said, According unto your words, so be it. And she sent them away, and they departed: and she bound the scarlet line in the window.
<jikl> 22And they went, and came unto the mountain, and abode there three days, until the pursuers were returned: and the pursuers sought them throughout all the way, but found them not.
<jikl> 23So the two men returned, and descended from the mountain, and passed over, and came to Joshua the son of Nun, and told him all things that befell them:
<jikl> 24And they said unto Joshua, Truly the LORD hath delivered into our hands all the land; for even all the inhabitants of the country do faint because of us.
<jikl> Joshua 3
<jikl> 1And Joshua rose early in the morning; and they removed from Shittim, and came to Jordan, he and all the children of Israel, and lodged there before they passed over.
<jdong> elky: help....
<jikl> 2And it came to pass after three days, that the officers went through the host;
<jikl> 3And they commanded the people, saying, When ye see the ark of the covenant of the LORD your God, and the priests the Levites bearing it, then ye shall remove from your place, and go after it.
<jdong> vorian: just ban 2001:470:*:*:*:blah
<jdong> vorian: there'll be more...
<elky> ugh synch
<jdong> I wish we could just ban biblical verses from here but that might not send the right message :D
<lkjh> Joshua 8
<lkjh> 1And the LORD said unto Joshua, Fear not, neither be thou dismayed: take all the people of war with thee, and arise, go up to Ai: see, I have given into thy hand the king of Ai, and his people, and his city, and his land:
<lkjh> 2And thou shalt do to Ai and her king as thou didst unto Jericho and her king: only the spoil thereof, and the cattle thereof, shall ye take for a prey unto yourselves: lay thee an ambush for the city behind it.
<jdong> vorian: lol told ya ;-)
<jdong> vorian: how's it feel to ban like 99% of IPv6 address space? :D
<vorian> great
<jdong> :)
<elky> the only difference between them was the a11 and b11
<vorian> and the end bit
<vorian> *:all
<RAOF> Gah.  Why is rsync Sid<->Hardy an order of magnitude slower than rsync Hardy<->Hardy?
<jdong> elky: yesterday they came in much more variety...
<vorian> ah, nevermind
<elky> i was referring to the end bit but fine
<jdong> 21:38 -!- 17 - #ubuntu-devel: ban %*!*@2001:470:1f11:65:* [by PriceChild, 91400  secs ago]
<vorian> elky: right-o /me is slow
<jdong> that wasn't even enough...
 * elky notes that two bans and vigilence is better than one ban locking everyone out
<elky> and why has freaking bip changed my nick again
<ScottK2> jdong: Got a minute?
<jdong> ScottK2: kinda... all my ubuntu equipment is in a box and I'm going to bed in 15 though
<ScottK2> jdong: Easy enough.
<ScottK2> From discussions here at UDS with some of the LP folks, they are getting close to turning the bug janitor back on.
<ScottK2> I'm somewhat concerned that due to the need to find testers and such, 60 days is a short time for a backports bug to maybe be incomplete.
<jdong> ScottK2: can't the bug janitor be configured? Would that be too much to ask for?
<ScottK2> jdong: So I find out that per project, projects can opt out of bug expiration.  I think we should do it for backports
<ScottK2> The only knob is on/off.
<jdong> ScottK2: ok then we should just opt out
<ScottK2> Yes.
<ScottK2> jdong: You can do that, I can't.
<ScottK2> They said you can do it now.
<jdong> ScottK2: ok I'll keep that in the back of my head :)
<ScottK2> It's in the project setup page.
<jdong> and/or deal with it soon if I get bored of packing
<ScottK2> K.
<ScottK2> End of the school year?
<jdong> ScottK2: yup, flying home first thing tomorrow at sunrise :)
<jdong> ScottK2: really really happy to be done :)
<ScottK2> jdong: Are you graduated then or just done for now?
<jdong> ScottK2: hah. no just done for the term; get 4 months off for summer then back in hell pit again.
<ScottK2> Ah.  Well enjoy the summer then.
<ScottK2> jdong: Where's home then?
<jdong> ScottK2: Michigan
 * ScottK2 nods
<jdong> ScottK2: btw saw your picture on planet :)
<jdong> ScottK2: you sound a lot younger over IRC :)
<ScottK2> jdong: Yeah, well people say I'm older and nicer in person.
<ScottK2> I can't tell.
<nalioth> both IPs klined, btw
<jdong> nalioth: thanks :). Now how many more IP's can he come back on? :D
<nalioth> jdong: you don't want to ask that, i'm afraid
<Lightkey> you don't have to name them all
<elkbuntu> jdong, that would probably be better reworded as "how many ipv6 addresses could someone working at $biggest_isp have access to"
<ScottK2> elkbuntu: about a bazillion.
<elkbuntu> ScottK, that's about what i was aiming at, yeah
<ScottK2> In the IPv6 design, the notion is that /64 is what get's delivered to an individual user, so each individual user gets a /64 of there own.
<ScottK2> So one user ought to get 2^64.
<ScottK2> An ISP, lots more ....
<milli> ScottK2: /48 and up
<ScottK2> Yeah.
<anujtom> hi
<anujtom> hi
<anujtom> hi
 * cody-somerville twiddles his thumbs at the airport.
<RAOF> Dear ext3.  Kindly finish deleling stuff.  Love, laptop harddrive.
 * StevenK slowly packs.
 * cody-somerville doesn't want to leave Prague. It rocks.
<StevenK> cody-somerville: You don't have to leave. Your employer and family might get concerned, though.
<cody-somerville> StevenK, true.
<Festor> Is there a problem with the PPA?
<Festor> see this: https://bugs.launchpad.net/launchpad/+bug/156872
<ubottu> Launchpad bug 156872 in launchpad "PPA: packaged passing from uploaded to published without trying to build" [Undecided,Confirmed]
<Festor> Already 10 hours have passed and still no package. I can only see the sources.
<lifeless> toolchain folk: https://bugzilla.novell.com/show_bug.cgi?id=390722#c25 gdb love
<ubottu> bugzilla.novell.com bug 390722 in Development "gdb - backtrace grace ?" [Major,Reopened]
<nadnux> part
<lifeless> kees: https://bugs.edge.launchpad.net/ubuntu/+source/gdb/+bug/111869
<ubottu> Launchpad bug 111869 in gdb "gdb screws stacktraces when no debuginfo is present" [Undecided,New]
<emgent> hello
<crimsun> asac: libflashsupport purportedly works with Flash 10 beta; in my experience using intrepid's libasound2{,-plugins} with alsa-utils's `asoundconf set-pulseaudio', there are no crashes.  The libflashsupport addition is, therefore, an attempt to help identify what in libflashsupport needs to be fixed; it's early enough in the intrepid cycle to do so.
<\sh> crimsun, do we have another location where we can fix the issues with flash without depending on lilbflashsupport in general?
<crimsun> \sh: yes - via libasound2-plugins, which works correctly with intrepid's libasound2{,-plugins}.  The intent is to drop libflashsupport entirely for intrepid.
<\sh> crimsun, good :) because the situation right now is really ... you know ;)
<crimsun> right, it's stressed.  Fortunately, backports of alsa-lib, alsa-plugins, and flashplugin-nonfree are sufficient to make things happen on feisty, gutsy, and hardy.
<crimsun> s/happen/happy/
<Jadd> Hello, is this the channel for application development on ubuntu?
<lool> rather for the development of Ubuntu itself
<MrObvious> Hello. When will Firefox 3 RC1 be in the repos for Hardy stable?
<Festor> MrObvious, soon
<Festor> MrObvious, http://ubuntuforums.org/showthread.php?t=797212&highlight=firefox+release+candidate&page=7
<MrObvious> Festor: Awesome thanks.
<azzco> Hi I want to create a deb package but I don't have the source, can I just compress the files needed for the software, add dependencies and such?
<norsetto> azzco: is that for personal use?
<azzco> I think that this package will be for, at tops 10 installations.
<azzco> Might also add that I haven't made any packages yet myself so any links with info would help.
<norsetto> !packaging | azzco
<ubottu> azzco: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<azzco> Great thanks I guess I'll be busy for a while then :)
<norsetto> azzco: have fun :-)
<dimedo> hi there
<dimedo> how can i modify the hardy installer cd to setup twofish-xts-plain encrypted root file systems?
<dimedo> the kernel supports that but the installer doesn't.
<bgrupe> hi, how can I build a kernel using the kernel git for an arch different than mine?
 * pwnguin asplode
<pwnguin> http://pastebin.ubuntu.com/14397/
<pwnguin> ^ is that license crazy, or am I?
<ion_> pwnguin: Yes.
#ubuntu-devel 2008-05-25
<wgrant> pwnguin: It's not too crazy. Just adding another two limitations on top of the GPL.
<wgrant> (which GPL? we'll never know)
<wgrant> Multiverse or loony-bin material at any rate.
<azzco> Isn't it Gnu general public license and not Gnu public license?
<wgrant> azzco: Neither. It's the GNU General Public License.
<azzco> Sorry bout that wgrant, I usually spell it like that though..
<Ng> wgrant: loony-bin, it's invalid, GPL says no additional restrictions
<Ng> imho, ianal, etc
<emgent> geta wgrant Ng
<wgrant> Ng: Doesn't the GPL just say that derivatives of the licensed body cannot have additional restrictions?
<Ng> wgrant: I'm looking at section 10, paragraph 3 of the GPL
<wgrant> I've not come across such a strange case as this before, so don't remember the wording of that bit.
<wgrant> Hmm.
<wgrant> I think the licensor is permitted to do it, but it might not be redistributable.
<wgrant> That seems odd, though.
<Ng> if it's not redistributable then it's not free software aiui :)
<wgrant> Right, it would belong in multiverse if anywhere.
<wgrant> Loony-bin it is, I think.
<emgent> Ng: do you have an access to manage ubuntu.com mail alias?
<pwnguin> technically, i think you can redistribute it to other people under the gpl
<pwnguin> it'd take a lawyer to figure out whether the non commercial clause came along with it
<pwnguin> it's so batshit insane that I'm going to write him
 * cody-somerville is at last home from Prague.
<johanbr> Nice. Long flight?
<cody-somerville> 17 hours
<johanbr> Pretty long, but still in the tolerable range.
<jdong> that's what *cough* *resist.....*
<wasssups> just ah .... with ubuntu hardy did you lock down the amount of threads / forks a user can do--- my crashme testing suggest this to be the case..
<jdong> wasssups: no, that's up to the individual system administrator to set
<jdong> maswan: there's really no global values that suit everyone's workloads.... limits.conf makes it easy for an admin to make such decisions locally
<wasssups> that is my default apparently ...
<jdong> wasssups: the default does not.
<jdong> wasssups: you can definitely forkbomb the default to death.
<jdong> unless the CFS scheduler in the non-patched kernel sucked *THAT* much (grin)
<wasssups> well it seems to fork out
<jdong> ok I just DoS'ed a hardy VM to make sure.... it definitely forks enough that sshd no longer talks to me
<jdong> just a simple bash forkbomb too
<wasssups> jdong: yeah but you can still run stuff
<wasssups> crashme hits a limit way below what it should
<wasssups> i will try again
<lifeless> the gnash mozilla plugin doesn't register itself for mozilla 3
<lifeless> asac: ^
<cyberix> About the development process. A certain bug for a package in main component has been confirmed to exist on various platforms and a fix has been released to the bug thread. What should happen next? Who is responsible for releasing an update for a package?
<lifeless> asac: seems to be trivially fixed by adding firefox-addons into the list of things to add alternatives for
<persia> cyberix: If the fix is not yet in the form of a candidate update, anyone is welcome to continue the process to make it so.  If the fix is in the form of a candidate update, it falls to ubuntu-main-sponsors to review the candidate and upload (for most bugs) or ubuntu-sru to review and approve (for bugs in previously releases)
<cyberix> There are actually two fixes. A patch and an updated package from Debian.
<cyberix> Which one should be preferred?
<persia> cyberix: Depends entirely on the content of each.  There is no rule about the source.  Use of the Debian patch is often easier in terms of later maintenance, so it is preferred if it is also correct for Ubuntu.
<cyberix> persia: May I quote this discussion directly in a follow-up comment?
<persia> cyberix: If you really, really want to.  Which bug?
<cyberix> https://bugs.launchpad.net/ubuntu/+source/obex-data-server/+bug/211252
<ubottu> Launchpad bug 211252 in obex-data-server "Cannot recieve files using bluetooth" [Undecided,Confirmed]
<juliux> hey persia
<persia> juliux: Good day
<tseliot> ï»¿persia: hi ;)
<persia> cyberix: No point adding to that conversation.  slytherin seems on top of it.  It likely ran against a freeze block, and will be modified to work for intrepid soon.
<persia> cyberix: Given the mixed responses in the thread, I'm really not sure it would be best for all users to apply as an SRU, but that's something that could be tested once it is fixed in intrepid.
<tseliot> emgent: are you there?
<lifeless> anyone with an x86 care to test the better-stack-traces patch in an ubuntu build?
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/gdb/+bug/111869
<ubottu> Launchpad bug 111869 in gdb "gdb screws stacktraces when no debuginfo is present" [Undecided,New]
<lifeless> and with that, /wave
<StevenK> lifeless: Come find us!
<lifeless> StevenK: I shall; where are you lurking ?
<Samsemilia> !seen dholbach
<ubottu> Factoid seen dholbach not found
<jdavies> !seen > Samsemilia
<Samsemilia> jdavies: thanks
<yannick> Is it the right channel to discuss packaging issue? or should i try #ubuntu ?
<Festor> yannick, #ubuntu-motu
<yannick> ok thx
<emgent> heya
<tseliot> emgent: check your email
<emgent> tseliot: Yeah i saw :)
<emgent> just a moment ehehe :P
<tseliot> no problem
 * emgent sending..
<emgent> tseliot: done :)
<tseliot> ï»¿emgent: thanks :-)
<emgent> np
<emgent> tseliot: http://en.emanuele-gentili.com/wp-content/uploads/2008/05/img_2655.jpg
<tseliot> five a day!!! In all senses
<tseliot> :-P
<emgent> hahahah sure
<siretart> pitti: I'm currently working on the cryptsetup merge
<Riddell> pitti, doko: mind about the KDE 4 MIRs if you're not on holiday tomorrow, pretty important that we can get started on KDE 4 properly
#ubuntu-devel 2009-05-18
<Turl1> anyone?
<calc> grr stupid delta codeshared flights can't do online checkin :\
<calc> which means they are now going to weigh my carryon and ban it to checked baggage :\
<Sarvatt> â
<what_if> Is there currently any project to make a ubuntu install on an external HD "highly portable" between machines? ie, copying the PortableSUSE project ?
<superm1> if you dont need nvidia or fglrx, installs should already be very portable
<what_if> superm1: was thinking framebuffer...
<what_if> superm1: opinions on that?
<superm1> what_if, poor performance likely
<superm1> but really if you just have a vanilla install onto an external hard drive, not much should stop you from moving it around.  you just wouldn't have whizz bang 3d effects on machines that would need -nvidia or -fglrx
<persia> For such an environment, you might want to use usb-creator to create a persistent live environment.  That way you get HW detection, etc. cleanly.
<persia> No reason that the "USB stick" can't be a 1TB drive, after all.
<superm1> HW detection is a bit of a misnomer though too. xorg.conf generation used to be the biggest point there, but now that it's a common xorg.conf for different graphics installs, less of an issue
<persia> superm1, Isn't there still libGL diversion though?
<superm1> persia, that's why i'm saying to stay away from -nvidia and -fglrx
<persia> Ah :)
<superm1> no real way to keep a portable install that supports any of the 3 possible libGL's
<what_if> superm1: I was going to go the framebuffer route simply to keep a static xorg.conf and simplify my life
<superm1> what_if, take a look at a vanilla 9.04 xorg.conf. you don't need to
<slangasek> hmm, I think it was kirkland who said he had such a thing, but blessing something that evil would be paradoxical :)
 * what_if googles
<superm1> slangasek, kirkland had a nice way to work with all 3 libGL's at once?
<persia> slangasek, That was an internal hard drive that switched between two machines (but yes, it included some diversion-managing scripts)
<superm1> well there is registering libGL.so.1 with alternatives, which i started to look at what was involved last year
<superm1> it could potentially make for a nicer experience for bulletproof X, and letting bulletproof X's failsafe session change the alternative to try to get the X session started back up
<calc> or just get noveau working and get rid of the two binary servers :)
<what_if> so, from a feasibility standpoint, does everyone think this is viable? (minus 3D support)
<persia> what_if, Minus 3D support, it's trivial,as long as you only try to support a single architecture.
<what_if> persia: yes, would be X86 only
<persia> Then, aside from 3D support, Wacom support, and a few other corner cases, every install is portable.
<Sarvatt> â
<what_if> brb, smoke break / reboot
<Sarvatt> â
<Sarvatt> â
<Sarvatt> â
<Sarvatt> â
<ion_> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<dholbach> good morning
<highvoltage> good morning dholbach
<dholbach> hiya highvoltage
<amitk> morning
<hakkav> hi
<hakkav> anyone used  Complete Fair Queueing in kernel development
<ogra> hakkav, thast the default in ubuntu since a few releases already
<hakkav> ah
<hakkav> also do you guys use Broadcom b43 driver?
<ogra> for item in "$(find /sys -name *scheduler*)";do cat $item;done
<ogra> to find the currently used scheduler
<hakkav> sweet thanks
<hakkav> its been a few yrs
<hakkav> btw is the L7 firewall still being licenced?
<hakkav> ogra without the quotes right? " "?
<hakkav> for i in $(find /sys -name *scheduler); do cat $i; done ?
<ogra> no
<ogra> just as it is there
<soren> Um.. No?
<soren> Oh, right.
<ogra> soren, ??
<soren> That happens to work :)
<ogra> works here :)
<ogra> i dont paste stuff i didnt check
<LordKow> i think you are both wrong. should be for banana in $(find /sys -name *scheduler); do cat $banana; done
<ogra> LordKow, damned you got me :P
<LordKow> ;)
<hakkav> it may go with " "
<hakkav> no?
<soren> It happens to work, yes.
<hakkav> LordKow: thats what i did
<hakkav> for i in $(find /sys -name *scheduler); do cat $i; done ?
<ogra> both will work
<hakkav> ah
<soren> Putting ogra's quotes there render the for-loop rather useless, though.
<soren> As it'll be treated as a single argument.
<LordKow> yea then you just got yourself a string
<ogra> yeah
<ogra> indeed
<hakkav> but im thiniing
<hakkav> if one is working with files that have spaces
<ogra> both wont :)
<hakkav> like say blabla - blabla.info
<hakkav> that must be enclosed into quotes
<hakkav> no?
<ogra> cat $(find /sys -name *scheduler*) works as well ...
<\sh> hakkav: if you have those filenames, kick the guy who created them...
<hakkav> for each item found in /sys where the name is scheduler, you must cat it
<hakkav> right?
<geofft> find /sys -name "*scheduler*" -print0 | xargs -n1 -0 cat
<LordKow> hakkav: where the name includes scheduler
<LordKow> (note wildcards)
<hakkav> \sh why
<hakkav> here I have /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/queue/scheduler
<hakkav> LordKow: yeah i know
<LordKow> if anyone has any thoughts on this matter feel free to type them: which is better (1) /usr/bin/env <interpreter> or (2) /usr/bin/<interpreter>
<\sh> hakkav: because those filenames gave me problems in the past...when it all was "new" ;) and it's too MS...and typically managment like...
<hakkav> ah
<hakkav> but there';s no issues
<ogra> it makes your disk wear a tie ?
<geofft> LordKow: neither, /usr/bin/env LD_LIBRARY_PATH=/home/geofft <interpreter> :)
<LordKow> hah :P
<\sh> ogra: yes ;)
<hakkav> LordKow: 1
<LordKow> im just thinking of the person who puts python in his home directory, updates the path but wonders why a particular package keeps looking for non-existent python in /usr/bin ;)
<ogra> i doubt its easily possible to have an ubuntu without python in /usr/bin
<hakkav> dont you think 1 is better?
<hakkav> you can define a new environment for the script you are running
<LordKow> indeed ogra, but it is possible
<bigon> could someone accept gst0.10-python in karmic?
<ogra> (indeed it theoretically is possible, but surely requires a lot of fiddling)
<hakkav> cant you just define a new env?
<geofft> #!/usr/bin/env env python, so you can install your own version of env
<LordKow> heh yea
<ogra> LordKow, you dont need to update the path btw, just create ~/bin, put python in there and re-login
<hakkav> is what i said
<LordKow> ogra: oh true indeed, never crossed my mind.
<ogra> ~/bin is automatically in your path if it exists
<LordKow> but im pretending im john doe who does crazy things
<ogra> poor john
<hakkav> BUT
<hakkav> it's not as safe as we wish, but for development and multiple versions, I find it useful ;-)
<hakkav> not safe though
<LordKow> exactly. and python is one where multiple versions is a very real possibility
<ogra> as any other intrepreter ...
<LordKow> alternatives *should* be taking care of those symlinks so /usr/bin/python should still work so long as alternatives are updated accordingly
<hakkav> nothing that the user can modify is safe; if the library path points to rootkits kept by others... or so...
<ogra> well, if you package the executable, you should make sure to use /usr/bin/python ... simply to make sure you use the python version the package was built against
<ogra> else the world might break through incompatibilities
<hakkav> LordKow: yeah
<hakkav> or what i'd do is
<hakkav> change the executable name according to the env.
<hakkav> is that what ogra is saying?
<hakkav> (i did it with php) though
<hakkav> worked
<ogra> if its for your own development and you want to use a newer python, use env ... and put the new python version into 7usr/local
<ogra> or into ~
<ogra> (with LD_LIBRARY_PATH set for ~/lib though)
<LordKow> it's for packaging to the masses
<ogra> then use the full path to the binary
<hakkav> so change the exe name to the env
<ogra> that way you make sure john doesnt break it
<LordKow> yea
<LordKow> john owes me
<ogra> well, the packaging policy :)
<ogra> i think its written donw there somewhere
<hakkav> ogra
<hakkav> the library path has to be the lib you want to use with python
<hakkav> riht/
<hakkav> right?
<ogra> right
<ogra> if you use ~ you might get into other weird issues though ... python will want ~/share too etc ... i would use /usr/local if i would want to use a different py version
<hakkav> if you keep python in /usr/share/backgrounds/python/blah...
<hakkav> LD_LIBRARY_PATH must be /usr/share/backgrounds/python/blah.../lib (or whatever you indicated when ./configureD ?
<hakkav> ogra: the user's home?
<hakkav> wouldnt the weird issues depend on the rest of the config and not just ~
<hakkav> as i understand it some systems forbid to execute things in /home directories
<hakkav> and i think relative paths are icky for anything
<hakkav> ~ is a relative path
<hakkav> so folks
<persia> hakkav, ~ isn't relative to me $(echo ~)
<hakkav> im sorry?
<persia> ~ expands to an absolute path (by default)
<hakkav> it's kinda alias?
<hakkav> its like an alias?
<hakkav> that absolute path changes
<maco> i thought "relative path" always meant "relative [to the current directory] path"
<hakkav> maco: relative to the user that is currently executing the script
<hakkav> being careless
<persia> maco, Can be relative to some operating directory as well.
<maco> ~ doesn't change when you cd, only when you su
<hakkav> from one user to another
<hakkav> persia erm interesting point
<ogra> everything is relative :P
<persia> ogra, You win :)
<ogra> not me ... just quoting freaks with weird haircuts here ;)
<hakkav> easy i got a weird one
<seb128> bigon: accepted
<bigon> seb128: thx
<seb128> you're welcome
<bigon> seb128: could you also sync libchamplain and libchamplain-gtk which are in debian's incoming?
<seb128> bigon: will sync when they reach the mirrors that's easier and there is no hurry
<bigon> seb128: ok
<vital> odd question mayhaps, but why boost-library 1.35 still, when 1.39 is available since beginning of month, and 1.38 since a tad bit longer?
<slangasek> Riddell, ScottK: Debian has dropped boost1.35, and kde appears to still build-dep on it; is there a transition plan there for karmic?
<ScottK> slangasek: We need to decide what the target is (and it's more than just KDE).   It'll be 1.37 or 1.38.
 * slangasek nods
<slangasek> boost-defaults seems to be pointing at 1.38, now
<ScottK> Last I looked 1.38 was still FTBFS in Ubuntu.
<slangasek> ah
<ScottK> I'd prefer 1.38 since that's what Debian is aiming for for Squeeze, but I don't know of that's Karmic or Karmic +1.
<iskywalker> hi!
<iskywalker> i am developing a daemon, is there any guidelines? i need mysql already running is there any standard way for that, like gentoo require?
<persia> iskywalker, Depends ought to do the latter.  For the former, mostly try not to be root, and avoid non-local sockets by default.
<iskywalker> persia: i was hoping a book or so, i must create a user and run the daemon on that useraccount, like www-data
<geofft> iskywalker: have you seen the Debian policy manual? It's worth at least skimming
<iskywalker> it is huge also :)
<persia> iskywalker, Hrm.  I don't know of one (but I'm not the best person to ask for book recommendations).  I suspect you'll find more success from a more general forum, rather than something so Ubuntu focused (as I expect your daemon ought work for any linux, if not any unix)
<geofft> :) that's why you skim it and know where things are, and later read the sections that apply to you
<iskywalker> persia: sure, but i would maintain an ubuntu not an general daemon...
<Awsoonn> bryce: Bug 347569 http://ubuntu.pastebin.com/d58789f5b could I test this patch and if it works just post that to LP or would you prefer a debdiff?
<ubottu> Launchpad bug 347569 in xserver-xorg-video-ati "[RS482] glxgears low fps" [Undecided,Confirmed] https://launchpad.net/bugs/347569
<Awsoonn> That was not ver gramatical of me... The question is would you prefer a .patch file or a debdiff? The .deb on this bug report made a significant differance in fps for me and I'd love to get this fix out to the greater good.
<ion_> A debdiff ready to be uploaded is prefered.
<Awsoonn> alright
<ion_> You might want to follow the original codeâs indentation and bracket style.
<Awsoonn> I have a question though, how do you magical guys behind the curtian accully 'upload' to -updates? do you just upload teh debdiff and the build system applys it for you or do you need to apply is then submit the whole source deb to the build system?
<ion_> The uploader will apply the debdiff to the extracted source package, build a new source package and upload that one.
<Awsoonn> I see, so me doing that extra work making the debdiff really does make a differance then? :)
<lesshaste> hi all
<ScottK> If there's a buildd admin about I'd appreciate having qt4-x11 on armel and kdebase-workspace on ia64 and sparc rescored so I'll know in less than several days if I've fixed problems there.
<Awsoonn> I decided to test radeon rewrite and would love to help out a bit if possible. Who should I ping?
<henux> If I want to integrate my own app to the new notification system in Ubuntu 9.04, which library should I use?
<ScottK> henux: #ayatana is probably a better channel for that question.
<kirkland> superm1: slangasek: hmm, not sure if i know what you guys are talking about ... ?
<kirkland> superm1: i have a little hack that generates a md5sum "signature" of my hardware configuration, and the associated xorg
<kirkland> superm1: hardware configuration as shown by lshw
<kirkland> superm1: i do this nasty thing when i travel ... i physically move my hard drive from my 14" thinpad to my 11" thinkpad, for portability purposes
<kirkland> one of which has an nvidia card, and the other an intel card
<kirkland> superm1: and I have an init script that computes my current hw config, and looks for a "signed" xorg.conf that works with it
<Awsoonn> Bug #126774 would someone please check my statement and provide some guideance
<ubottu> Launchpad bug 126774 in apt "package update proceeds without adequate disk space" [Medium,Triaged] https://launchpad.net/bugs/126774
<superm1> kirkland, what do you do about libGL though?
<kirkland> superm1: that's the sore point ... install/uninstall
<superm1> kirkland, so there are two solutions that i've been pondering about with that kind of scenario
<superm1> 1) alternatives system for libGL.so.1
<superm1> 2) automatically try to use "nvidia" driver if it's available. there was a patch proposed for this a long time ago, but it didn't make it upstream
<superm1> and doesn't work as it should currently
<ebroder> Any dpkg wizards around? I'm having a hard time working out the interactions between python-xen-3.3 and xen-utils-3.3 on upgrades
<calc> hmm i started using ext4 and now i see 4 new bugs fixed in ext4 for 30-rc6
 * calc wonders if it was a good idea for him to switch to ext4 already
<directhex> calc, "no". next question?
<calc> directhex: heh
<calc> directhex: i guess to late for me at least until after UDS
<maxb> Would there perchance be any cdbs experts around? I'm looking at the current Ubuntu delta in the python-distutils cdbs class, and it looks wrong to me
<ScottK> maxb: What specifically?
<maxb> It replaces --root=$(cdbs_python_destdir) with --root=$(CURDIR)/debian/$(cdbs_curpkg) which seems a bit wrong, since the first is derived from potentially user-specified variables
<ScottK> What is the default for cdbs_python_destdir?
<james_w> maxb: bug 374892
<ubottu> Launchpad bug 374892 in cdbs "Use correct root path when converting dist- to site- in arch packages" [High,Fix released] https://launchpad.net/bugs/374892
<james_w> that's why the change was made it appears
<maxb> I see the bug, but I'm not really convinced that the fix is corretc
<maxb> I'm trying to get mercurial to build with the newer cdbs - which I have, by way of a slightly dodgy hack, but this Ubuntu change has broken it
<ScottK> So what would you recommend instead?
<maxb> Well, the "obvious" solution would be to have fixed the disparity between the upstream rules and the added ubuntu-specific fragment by making the ubuntu-specific fragment conform
<maxb> I'm just not sure if there are nonobvious problems with that
<reece> greetings
<reece> I am in the process of creating a front-end UI for espeak and other text-to-speech engines
<reece> Is there anywhere that has guidelines / requirements for what a package needs to support
<reece> in order for it to be included in Ubuntu?
<persia> reece, How do you mean?  As in which engines, or something else?  The main requirement (aside from packaging details) is that it compile and work on the current development release.
<reece> I mean things like being localised (which it isn't at the moment, but I am working on this)
<reece> Ok, so you just need to provide the details on how to build the package then?
<persia> reece, Being localised is better, of course :)  But yeah, just have a well-written INSTALL file that explains how to build and install, and make sure your licensing is all correct.
<reece> ok, cool
<reece> does the standard autotool INSTALL file count? I am using an autogen.sh script to generate the configure, et. al. files
<Elbrus> Adam Conrad here?
 * Elbrus doesn't know his nickname
<Elbrus> infinity: ping
<Elbrus> bugging about bug 2253
<ubottu> Launchpad bug 2253 in fpc "fpc needs bootstrapping on buildds" [Medium,Fix released] https://launchpad.net/bugs/2253
<Elbrus> or actually bug 67544
<ubottu> Launchpad bug 67544 in fpc "PPC build of fpc fails" [Undecided,Confirmed] https://launchpad.net/bugs/67544
<persia> reece, As long as the file correctly describes how to do it, it doesn't matter if it's lovingly hand-crafted, or boilerplate.
<reece> ok, thanks
 * maxb determines that the cdbs change is in fact a regression bug, and starts to put together a bug report
<maco> can someone explain something about uds?
<seb128> if you don't ask probably not
<mbana> hi, does anyone use xmonad?
<seb128> mbana: hi, try #ubuntu
<mbana> that won't help.   there's something with the package i believe
<seb128> so the question you want to ask is not if somebody uses it
<mbana> i've even tried the official xmonad channel, they don't seem to have a solution either.  i've been told it's packing issue or something wrong with gnome
<seb128> what about asking your question directly?
<mbana> because if no one responds, there's no point in me asking typing a long a detailed problem ;)?
<Tm_T> mbana: perhaps someone reads log and give you the answer later?
<seb128> and you expect people to reply if you don't ask the question?
<Tm_T> those things happen (;
<mbana> ok i'll ask on the ML.  which one would you guys recommend?
<seb128> you could probably have described the bug in the same time you are asking those question and explaining why
<seb128> what about opening a bug on launchpad?
<maco> mbamford, i'm using xmonad
<maco> bah
<maco> mbana, ^
<mbana> maco: hi there, would you prefer that i file a bug report?
<maco> i think whomever packages it would prefer a bug report if its actually a bug
<Tm_T> or even possible bug
<maco> what's going on that you think's a bug or that you'd like to have reproduced?
<mbana> maco: https://bugs.launchpad.net/ubuntu/+source/xmonad/+bug/378111
<ubottu> Ubuntu bug 378111 in xmonad "Xmonad refuses to start automatically on 9.04" [Undecided,New]
<maco> which desktop environment are you using?
<maco> it starts automatically in kubuntu just fine
<maco> and i believe it starts automatically for dtchen in ubuntu
<mbana> maco: gnome.  it was working perfectly in intrepid
<maco> well i had it working in 9.04 w/ gnome then reinstalled and switched to kde and it starts automatically just fine in kde too. dtchen's using it in gnome and it starts automatically for him
<maco> something changed in gnome so you have to set it up differently, but it does work
<maco> i think there are directions on xmonad.org for how to make it work with current gnome
<mbana> it's interesting to note that i used the jaunty instructions whilst on intrepid and it workedd, here's the link http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_in_Gnome#Ubuntu_Jaunty
<maco> did you blast away .gconf?
<mbana> hell no
<maco> did you read the paragraph you linked that says intrepid's .gconf isn't compatible with jaunty?
<mbana> i'm not using .gnomerc.  it seems rather odd that i have to clear out the entire .gconf
<maco> ohok
<maco> i didnt have to get rid of it...i think i just put the "killall metacity ; xmonad &" in the autostart thing
<mbana> autostart thing?
<geofft> does this apply to all window managers set in gconf, not just xmonad?
<geofft> (that upgrading from Intrepid to Jaunty causes you to lose your WM?)
<mbana> i can't confirm, i only use xmonad
<maco> mbana, system -> preferences -> session -> autostart
<mbana> maco: i'm afraid i don't have that.  do you mean startup applications?
<maco> yes
<maco> and i'm AFK now
#ubuntu-devel 2009-05-19
<pwnguin> is there a list of events used within ubuntu's upstart configuration?
<pwnguin> one of the upstart use cases described was a network mounted /usr, and that fits my own use case closely; but i haven't a clue what that event might be named
<Keybuk> ok, these X hangs are going to get old rael fast
<DJJeff> "aty128fb 0000:00:10.0 invalid ROM contents" <---- error from ubuntu 9.04 ppc LIVE (iMac G3)
<DJJeff> wont even start x
<DJJeff> let alone hang
<DJJeff> lmao
<tkamppeter> pitti, hi
<fschulte> hello, where can I find the people responsible for employment at Ubuntu, resp. the ISD-team?
<Hobbsee> fschulte: hr@canonical.com?
<fschulte> Hobbsee: Allright, on May 3rd I've sent a letter with my application to this address, but havn't received an answer jet.
<Hobbsee> fschulte: from what I've heard, they do take a while to respond sometimes.  I do not work for Canonical myself, so can't help you
<fschulte> Hobbsee: Ah
<fschulte> Hobbsee: thanks anyway
<Hobbsee> y/w
<fschulte> Hobbsee: makes me feel a lot better ;)
<Hobbsee> :)
<Gast_137_> http://www.marie-wird-entjungfert.net/?uid=617626
<sivang> hi all
<calc> wow channel is totally dead
<azeem> you ruined it
<calc> azeem: heh
<azeem> I was going to register the chan for #idlerpg
<calc> heh
<maxb> Karmic's blkid appears to have a pathological bug when confronted with my raid1 md partitions which worked fine in Jaunty - it hangs using 100% CPU. Does anyone have any better ideas for diagnosis short of strace / recompile with printfs ?
<Zorael> How do I pull from a git repository up to a specific commit? I want to bisect and I don't know where to start to mark as good
<Zorael> commit and/or date
<greg-g> Zorael: can't you just pull the whole thing, then do git-bisect?
 * greg-g isn't a git power user
<Zorael> nor am I. :3 I need to set a specific commit as "good" and then the current one as "bad", right?
<Laney> Zorael: git bisect start <bad> <good>
<Chipzz> Zorael: how is this relevant to #ubuntu-devel? pls read the topic!!
<Zorael> Chipzz: Tracking down xserver-xorg-video-intel bug regressions?
<Zorael> Which is in the repository, last I checked.
<Chipzz> you're asking about git, not xserver-xorg-video-intel
<Laney> there's a page on the Ubuntu X wiki about bisecting, iirc
<Chipzz> and by your reasoning the fact that gcc is in the repositories make it valid to ask questions about C programming too
<Zorael> Chipzz: Fair enough.
<Chipzz> and while questions about X do get asked here often, there's #ubuntu-x where it's more on-topic
<Chipzz> sorry if I sound too harsh, but just about every person here who enters to ask a question neglects to read the topic, and asks questions that are off-topic
<Chipzz> which is creating lots of noise
<Zorael> Reading it again and again, I don't see why what I'm trying to do isn't development, but I guess it might be support. Point made. I'll shut up.
<Chipzz> the best description for this channel would be that it is about the development of the distribution (or rather, the subset that is main) as a whole, the core components (like upstart), and integration between the core components
<Chipzz> for questions about packaging itself, and related affairs #ubuntu-motu is the place to be
<Laney> I think questions about how to debug xorg aren't too off topic for this channel.
<Laney> ubuntu-x would have been better, yes, but this place is fine (given how idle it has been today)
<dfeuer> Trying to find the source of a segfault in system-config-printer.  Anyone care to help?  I don't have any experience debugging multithreaded programs, or much debugging other stuff.
<madrazr> Hello all, I am building a Qt app, which I want to run on Ubuntu. I have tested it well to work with Ubuntu
<madrazr> but what I want is, when I boot Ubuntu I don't want GDM to appear, I want it to boot to my application directly
<madrazr> how do I accomplish this?
<ketvar> for peering ups anyone gives priority to linux isos?
#ubuntu-devel 2009-05-20
<geofft> regarding the discussion about xmonad last night: it looks like this affects all WMs set in .gconf
<geofft> that is, if your .gconf in Intrepid specified a window manager, you don't get one in Jaunty
<geofft> I can find discussion on the web and on e-mail, and LP bugs for specific WMs, but not one general one. am I just missing it?
 * nixternal hugs his 'startx' with xmonad :)
<owen1_> is there ubuntu reference, similar to debian's - http://www.debian.org/doc/manuals/reference/ ?
<nixternal> owen1_: there are a bunch of things that would make up something similar to be honest
<geofft> nixternal: that is my personal setup too, yes :) no GNOME on this laptop :)
<nixternal> no one stop shop for such a thing unfortunately
<nixternal> geofft: FTW! :)
<geofft> but this is biting a bunch of our users
<geofft> so I count bugs 378111, 348432, 366166, and 340140 as conceivably all the same issue.
<ubottu> Launchpad bug 378111 in xmonad "Xmonad refuses to start automatically on 9.04" [Undecided,New] https://launchpad.net/bugs/378111
<owen1_> nixternal: like what?
<ubottu> Launchpad bug 348432 in compiz "Jaunty - after upgrade from 8.10, no window decorator at login" [Undecided,New] https://launchpad.net/bugs/348432
<ubottu> Launchpad bug 366166 in ubuntu "e16-gnome not working with jaunty 9.04 " [Undecided,New] https://launchpad.net/bugs/366166
<nixternal> owen1_: various documents on help.ubuntu.com, and then various documents under wiki.ubuntu.com
<nixternal> owen1_: oh, and the Debian Reference itself can be utilized to an extent :)  yes, a bit of cheating, but it works in a lot of cases
<owen1_> i want to learn about the boot process, what apps are running on boot, why and how to control it. can i do it by reading the debian's docs?
<nixternal> there is something on the wiki concerning boot process, but I do not know exactly where...I came across it a month or so back
<geofft> owen1_: have you seen upstart's man pages and /etc/event.d?
<owen1_> geofft: no
<geofft> see man init, man initctl, etc., and the docs in that directory and in /usr/share/doc/upstart-compat-sysv/README.Debian.gz
<owen1_> geofft: thanks, i'll take a look. i am curious, how come there is no centeralize place on the web for ubuntu, as red-hat and debian?
<geofft> huh? there certainly is ubuntu.com :) wiki.ubuntu.com may be more helpful
<owen1_> geofft: ok. i'll check them out. thanks
<geofft> anyway. Anyone have ideas on what in GConf could have broken the window manager preference that worked in Intrepid?
<ebroder> geofft - what setting did we use for <=Intrepid? Googling pointed me at /desktop/gnome/session/required_components/windowmanager; another at that one and also /desktop/gnome/applications/window_manager/current
<ebroder> Huh - looks like we were setting /desktop/gnome/session/required_components/windowmanager
<owen1_> geofft: i can't find anything technical here:  https://wiki.ubuntu.com/
<geofft> owen1_: what are you looking for? there are a lot of technical docs deeper within that site
<owen1_> geofft: mainly the boot process. i was just curious if there is anything online simiar to debian. the links you sent me are not low level, at least i couldn't find any.
<owen1_> geofft: even the server guide is mainly about installing appse
<owen1_> geofft: apps.
<owen1_> geofft: i guess my best bet is the man pages you mentioned.
<owen1_> geofft: unless i missed a link on https://wiki.ubuntu.com/
<geofft> owen1_: if I search for "upstart", there's a little bit of helpful stuff
<owen1_> geofft: isn't ubuntu used for production server?  is there a place for ubuntu sys admin to look for this stuff?
<hegde> hi all
<hegde> i have a laptop with an sdcard reader in it....all the cards that i insert is mounting in /dev/sdb1 .....is there any way to get the sdcard name???? like CANON MEMORY CARD
<wgrant> hegde: This isn't a support channel; you want #ubuntu.
<maco> wgrant, i have a devel question.  if an sru has been uploaded to universe and it got an ACK from motu-sru, how does it move forward out of the unapproved queue?
<wgrant> maco: You wait for an archive admin to do it on their archive day, I guess.
<wgrant> maco: But that might take a while, given that {{Some,All}Hands,UDS} is happening.
<maco> ah ok. thanks
<mdke> do developers tend to use virtual machines when testing SRUs for previous releases, and if so, what is the software of choice? I've been using virtualbox but it's a bit of a drag to set up the different guests
<hyperair> they go into -proposed, and users test them.
<mdke> hyperair: I'm thinking that developers test the packages before uploading them, though
<hyperair> also, all virtual machine solutions require you to set up guests.
<mdke> but, doesn't vmware provide images which are pre-setup?
<hyperair> well.
<hyperair> i'm not sure
<hyperair> but it's pointless isn't it, if you're gonig to require a vanilla ubuntu ______ system anyway?
<mdke> I assumed that the vmware images were "vanilla"
<mdke> also I wondered if other virtual machines were easier to setup than virtualbox
<maco> virtualbox is pretty easy...i mean, it has a GUI!
<mdke> it's ok, but you have to go through the Ubuntu installation process, then install the extra modules on the guest so that you get proper screen resolution
<maco> you can save the image and pass it around if you like
<mdke> takes a while, and I'm setting up one for each supported version of Ubuntu
<maco> i had a alpha5 jaunty on the pirate bay
<maco> i recommend snapshotting right after install that way you can go back to vanilla after each test
<mdke> that doesn't really help me though because I'd like a separate machine for each version, snapshots don't really interest me
<hyperair> the point here is having a separate machine for each version, and snapshotting the vanilla install
<mdke> I'll use virtualbox if I have to, of course, but I was curious about what others use
<hyperair> hence after each test, you can revert to the vanilla install
<hyperair> i.e. ~0 maintenance
<mdke> well, I might do that, but the testing I'm going to do is quite minor, so reverting a test package I've installed takes 5 seconds
<mdke> I think my question still stands though
<lesshaste> hi all
<lesshaste> ulimit -m doesn't seem to do anything in hardy
<lesshaste> is this a known feature?
<lesshaste> (ulimit -v 0; exec top)
<lesshaste> <ferret> Killed
<lesshaste> that's correct
<lesshaste> but ulimit -m does nothing as far as I can tell
<lesshaste> there is a long discussion about the 2.4 kernel http://mail.nl.linux.org/kernelnewbies/2002-07/msg00131.html which says that -m doesn't do what you might think
<lesshaste> is this also true for modern kernels, and if so shouldn't the docs for ulimit be updated?
<maco> mdke, if you look around online, you can probably find vbox images for many of the releases
<mdke> maco: ok, I will have a look, thanks
<mdke> I'm still interested to find out what other developers use, though
<Hobbsee> mdke: you might ask sometime when most of them aren't at all hands, fwiw
<maco> i used kvm when i was testing unstable and knew my hardware was a bad idea with that version
<lesshaste> or should I just report a documentation bug?
<maco> All Hands *without internet*
<maco> plus, the American developers are asleep
<mdke> Hobbsee: I'll do that; but we do have some developers left, as you've demonstrated :)
<Hobbsee> mdke: sure, but I try to avoid doing SRU work, as i don't tend to run the releases after they've released for long.  So i don't count ;)
<Hobbsee> mdke: there was a bugsquad community position for someone to regularly create and update virtualbox / other images, though.  i'm not sure it ever got filled.
<mdke> interesting
<stefanlsd> mdke: i have vbox for testing gui related stuff. if its not gui, i often just use pbuilder chroot with --login option...
<mdke> stefanlsd: thanks, that's helpful
<mdke> I'll carry on with vbox too
<lesshaste> anyone on jaunty care to do "man bash" and then search for "ulimit" and tell me what it says for "-m" ?
<Nicke> lesshaste: Have you checked http://manpages.ubuntu.com/ ?
<ulel> hi
<ulel> anyone running a cluster here
<ulel> on ubuntu
<slangasek> ulel: this isn't really an appropriate channel for such questions; you might try #ubuntu-server
<ulel> ok
<quadrispro> wgrant: hi! http://qa.ubuntuwire.com/uehs is outdated, could you refresh it?
<wgrant> quadrispro: Looking, thanks.
<quadrispro> :)
<wgrant> quadrispro: It doesn't seem to be misbehaving any more, so it should be updating now.
<quadrispro> wgrant: thank you
<calc> Hobbsee: there is internet in all but the plenary room
<calc> Hobbsee: but we aren't really supposed to be using the net
<Hobbsee> calc: ahhh
<calc> Hobbsee: coming to UDS next week?
<Hobbsee> calc: nope.  Been smashed with uni work and real life
<calc> Hobbsee: ah ok
<Hobbsee> i won't make it to another one until this time next year, if I make it at all.
<calc> ok
<geofft> ebroder: so, I have both of those gconf keys set to "Metacity" (since early April) and I don't get a window manager on Jaunty
<geofft> er, "metacity". Should it be a full path or something?
<geofft> okay, setting either one of those to a full path doesn't help.
<ScottK> geofft: I think you want #ubuntu
<geofft> hm, potentially. Although I know there's a bug here.
<ScottK> Then maybe you want #ubuntu-bug
<toiyeuvietnam> alo
<toiyeuvietnam> ai chat ty ko nhy.?
<toiyeuvietnam> ko ngu dc
<Pici> !vn
<ubottu> Äá» ÄÆ°á»£c trá»£ giÃºp vá» Ubuntu báº±ng ngÃ´n ngá»¯ Viá»t, xin vui lÃ²ng /join #ubuntu-vn. Ráº¥t vui lÃ²ng ÄÆ°á»£c giÃºp Äá»¡
<hunger_t> Is there any estimation for fglrx debs working with karmic possible at this time?
<ScottK> hunger: You might ask in #ubuntu-x
<hunger> ScottK: Thanks!
<hunger> ScottK: Not that important since the jaunty kernel is working fine and has fglrx :-)
<okayzed> has anyone been following IMA in the kernel dev?
<okayzed> IMA = integrity measurement architecture
<Pici> okayzed: You may want to ask in #ubuntu-kernel
<okayzed> thanks
<maxb> ooi, what caused the mass-giveback today?
<Jihui_Choi> I'm remastering ubuntu live iso.
<Jihui_Choi> using uck. I updated all packages and it applied on live iso.
<Jihui_Choi> however after I installed ubuntu on my system using my live iso, the update manager asked me to update packages.
<Jihui_Choi> How can I updated them?
<diddly> hi all, i'm trying to debug a Qt4 based app, but gdb isn't stepping into Qt code after i installed libqt4-debug
<maxb> Hi, are there any util-linux maintainers around who could explain how best to submit a debdiff and/or request changesets be pulled from upstream's git, given the rather unique style of packaging of the source package (being a git repo based off upstream's) ?
<ScottK> maxb: You'll want to talk to lamon
<ScottK> maxb: lamont even
<maxb> lamont: ping?
<maxb> (thanks ScottK )
<YokoZar> Is there a reason lib32asound2 suggests libasound2-plugins rather than lib32asound2-plugins ?
<lamont> maxb: you want to tell me which git commit you want pulled back to which branch
<ScottK> You are lamont the great.  You're supposed to know this stuff.
<lamont> ScottK: heh
<lamont> well, there are days I'd like to pull all of the commits back, but that's not so feasible.
<lamont> anyway,  bed time for me.
<maxb> lamont: bug 377395
<ubottu> Launchpad bug 377395 in util-linux "[karmic] software RAID not assembled at boot - blkid hangs using 100% CPU" [High,Triaged] https://launchpad.net/bugs/377395
<lamont> it'll probably be monday, unless keybuk beats me to it
#ubuntu-devel 2009-05-21
<barbarian_sargon> hello all
<barbarian_sargon> I am trying to get some help installing gtk-gnutella through terminal
<barbarian_sargon> a friend of mine helped me do it last time, but he is in bed. And since I re-installed ubuntu, I have to re-install it
<barbarian_sargon> is anyone here?
<geofft> try "sudo aptitude install gtk-gnutella", and go to #ubuntu instead for any more support questions
<geofft> this channel is for ubuntu-development, not ubuntu support :)
<barbarian_sargon> oh, ok
<barbarian_sargon> sorry
<barbarian_sargon> thank you
<directhex> hm
<directhex> how important is it for ubuntu to have support for every conceivable LANG by default?
<directhex> i.e. i can save 800k if we split some of mono's codepage support into Suggests:
<directhex> sounds like we're moving the "uncomon" stuff to Suggests:
<directhex> uncommon
<directhex> i.e. keeping 8859-15 in
<vadi2> Hi. Is there any documentation on generating trusted .desktops?
<chrisccoulson> what do you mean?
<vadi2> Since 9.04, new .desktop files are marked as 'untrusted' by default
<chrisccoulson> if you mean by "trusted" that nautilus doesn't bug you about them being not trusted, then they have to have the executable bit set
<vadi2> Ah.
<vadi2> thanks a bunch
<chrisccoulson> you're welcome
<geiseri> hi, i am wondering if there is documentation on the exact order that scripts are called during an install/reconfigure and upgrade proces for a debian package.  Chapter 6 of the policy manual confuses me on how they are executed.
<ScottK> geiseri: There's a good discussion about it on (IIRC) the Debian Women wiki.  I don't have the exact URL.
<maxb> The policy manual is the canonical documentation on this matter
<geiseri> ScottK i can google it, thx
<ScottK> maxb: Yes, but not the clearest.
<geiseri> maxb: im sure it is, that is why i am asking here
<geiseri> maxb: since its kind of vauge on the exact order of things during a dpkg-reconfigure of a package.
<ScottK> The one I mentioned has been pretty thoroughly reviewed.
 * geiseri is searching now
<geiseri> ScottK: is this what you had in mind? http://women.debian.org/wiki/English/MaintainerScripts
<ScottK> geiseri: Yes.  That's the one.
<geiseri> cool, the only thing it is missing is the reconfigure process...
<geiseri> my point of confusing is that it seems postinst is called during reconfigure, but i cannot tell if prerm is called too
<geiseri> oh another question, what is the sanest way to have something execute on first boot right after a new install?  just add an rc script and remote it when im done running it?
<Im> when is the patch for 945 intel support on 9.04 going to be released??
<ScottK> Im: #ubuntu-x is probably a better place to ask.
<owen1_> how to change the keyboard layout from terminal? "InputDevice" section is commentd on xorg.conf, so maybe there is a new way to change things like this?
<ScottK> owen1_: #ubuntu for support questions
<geiseri> hrm... is there any way to make the preseed post install script run interactively?
<ScottK> geiseri: I think you want to look indo debconf
<geiseri> ScottK: i am, but it looks like it runs in the background... i see the log output in the vt4 but the main vt hangs
<geiseri> hrm.. it implies that it can run interactive, but it seems like it cannot...  i wonder if it would just be easier to run it at first startup
#ubuntu-devel 2009-05-22
<Ryan52> is there a tool like Debian's tagpending that can be used to parse debian/changelog for LP bug closing and set those bug's statuses to "Fix Committed"?
<Ryan52> and if not, any pointers to the regexp to match LP bugs and/or how to change bug statuses (from a script) so that I can write such a tool myself?
<felix_> im looking for a good c++ object oriented manual. i only know ansi c, and i would like to practice. i want to implement a hash algorithm
<geser> Ryan52: the regexp for it is in /usr/share/perl5/Dpkg/Changelog.pm and you can use the LP API to manipulate bugs
<Ryan52> hm ok, thanks.
 * hyperair grumbles about not being able to compile quilt
<Laney> when does the publisher run?
<ScottK> Laney: The run starts at 3 minutes after the hour.
<Laney> ScottK: thanks
<sebas> Anybody around who can tell me where flash does send its sound?
<sebas> I've sound working for skype and the KDE apps but flash is silent
<sebas> Removed all pulse from my system to make sound work at all
<sebas> Is it possible to use flash with sound without pulse?
<ion_> topic
<sebas> Can you be more specific?
<directhex> sebas, more specific: "#ubuntu for support and general discussion for dapper-jaunty"
<sebas> directhex: right, thanks. Sorry for the noise
<Dillizar> hey
<fta> broken libc? http://launchpadlibrarian.net/26702235/buildlog_ubuntu-karmic-i386.db4.6_4.6.21-13_FAILEDTOBUILD.txt.gz
<fta> d'oh: http://paste.ubuntu.com/178076/
<Guest63936> hello
<Guest63936> hello
<Guest63936> anyone there
<azeem> this is a development channel, not a chat room
<azeem> you won't find people randomly chatting unless there is business
<Guest63936> can someone help me compile a psptoolchain
<Guest63936> i keep getting error
<Guest63936> i keep getting errors
<Guest63936> join #ubuntu+1
<funkyHat> Which libsdl package is pulled in by default in Ubuntu? looks like it should be libsdl1.2debian-pulseaudio
<funkyHat> Can't tell from here because I already had sdl installed before upgrading (if that might make any difference)
<funkyHat> Also is there a way I can find things like that out without having to ask silly questions? :)
<maxb> pulled in by default by what?
<funkyHat> maxb: libsdl1.2debian
<funkyHat> Oh, looks like it would default to -alsa?
<kklimonda> Is it possible to update transmission to 1.53/1.54 in 9.04 instead of backporting all fixes? Developer says that almost all changes made in 1.5x are now bugfixes - there are only few "arguably minor improvements, rather than fixes, but I included them because they are so minor, and have such a limited scope w/no ripple effect" in future 1.54 release. 1.53 is security release, 1.52 contains only bugfixes. Also whole 1.5x branch is
<kklimonda> kept mostly because of Ubuntu :).
 * felix_ try
<MmikeDOMA> Is there a way to pre-download packages, and then issue do-release-upgrade? I've downloaded all the packages using apt-zip, put those in /var/cache/apt/archives, issued do-release-upgrade, and it starts downloading packages from the internet...
<Who> I am trying to do a notification gauge from notify-send - is that possible?
<xhaker> dtchen: hello, is there any CONFIG_SND_HDA_HWDEP enabled ubuntu kernel?
<xhaker> dtchen: i need to use hda-verb :/
<maxb> xhaker: /boot/config-`uname -r`
<directhex> # CONFIG_SND_HDA_HWDEP is not set
<xhaker> yes i know it is not set on mine :)
 * felix_ fears the electric storm that is being created over madrid sky
#ubuntu-devel 2009-05-23
<dtchen> xhaker: no, it's not. i'll be raising that and other config-related issues at UDS this coming week.
<Marco> Hello. Would anyone here happen to know how to download a bzr repository revision right off lp
<Marco> without having to use bzr
<maxb> Marco: #bzr would be rather more on topic for that question
<lifeless> any ubuntu-main-sponsors around? bug 379754 is ready for an upload AFAICT
<ubottu> Launchpad bug 379754 in pyrex "deprecation warning in Errors.py" [Undecided,New] https://launchpad.net/bugs/379754
<ScottK-desktop> lifeless: I've already packed my keys away in preparation for flying to Spain, so I can't sponsor, but generally it's better to provide a patch or debdiff, not who whole diff.gz
<ScottK-desktop> lifeless: Also you might send this to Debian as a wishlist bug (Python 2.6 is in Experimental)
<lifeless> ScottK-desktop: thanks; I'll definitely do that in future
<lifeless> having huge packaet loss here atm though so not right now :( minutes to upload things)
<ScottK-desktop> No problem.  I'm a trans-atlantic plane ride away from being willing to consider working on sponsoring things.
<kevix> sorry to bother folks, but I have an upgrade issue that is not something that the usual #ubuntu folks will catch. I upgraded to Intrepid. shortly after I rebooted, 'overflow' was created for /tmp. the root fs is not full but some FS error? is reporting it as 100%. I have had this specific error when I upgrade to a new stable release before.
<Chipzz> kevix: this is not an overflow channel for #ubuntu
<Chipzz> like the topic will tell you, join #ubuntu+1 if you have problems with the latest development releaes
<kevix> Chipzz: I was not suggesting it was an overflow channel. I thought I might get some hints from folks who knew more than I. The best #ubuntu said was "delete some files."  but that does not fix the issue
<kevix> Chipzz: but I will try the +1 thing and hope I dont get the same answer
<calc> anyone know if there is somewhere to get ice in the hotel
<TitanMKD> hi
<TitanMKD> I'm developer on Cuda
<TitanMKD> and I have a strange things which happen on Ubuntu 9.04 with tested driver 180
<TitanMKD> When I launch my cuda software first time all work fine
<TitanMKD> when i relaunch it, it fail and cuda kernel call are aborted
<TitanMKD> any idea why that happen with test Nvidia Driver 180.xx (recommanded at installation of Ubuntu 9.04)
<TitanMKD> ?
#ubuntu-devel 2009-05-24
<pace_t_zulu> apologies for all the reconnects... switching from xchat-gnome to xchat on all my VMs
<felix__> c-cpp-reference isnt translated to other languajes? in ubuntu repos
<hyperair> ember_: hello. i noticed you merged irssi last
<hyperair> ember_: is there anything blocking it from entering ubuntu?
<hyperair> 0.8.13 i mean
<stefanlsd> Any archive admins around that could help me with a problem?
<wgrant> stefanlsd: It's a UDS weekend, so quite possibly not. Why an archive admin in particular?
<stefanlsd> wgrant: i have bug re a package that was uploaded with an incorrect orig.tar.gz (source is extracted twice in the orig.tar.gz) - wanted to rebuild against the orig.tar.gz from debian.
<wgrant> stefanlsd: That's not possible without changing the version.
<stefanlsd> wgrant: is there anything i can do, except request it?
<wgrant> stefanlsd: What do you mean 'request it'?
<stefanlsd> wgrant: asking an archive admin to rebuild?
<wgrant> stefanlsd: An archive admin isn't likely to do that for you; any uploader can do it just as well as they can.
<wgrant> You would need to prepare an upload with a different orig.tar.gz version string.
<stefanlsd> wgrant: ok. thanks :)
<joaopinto> hi, does anyone know where to find the source for packages.ubuntu.com ?
<Hobbsee> joaopinto: you'd probably need to contact frank@lichtenheld.de
<Hobbsee> i can't see it hiding in bzr or anything
<joaopinto> Hobbsee, ok tks
<Hobbsee> joaopinto: you're welcome
<geser> it's in git on git.debian.org
 * pwnguin hates patch systems
<pwnguin> i need to apply debian/patches to a source package tree to hunt down a bug
<pwnguin> is there a common target for patching?
<infinity> pwnguin: Nope.
<pwnguin> hmm. cdbs?
<pwnguin> honestly, whats the point of using svn AND quilt?
<StevenK> patch or patch-stamp, but it changes
<pwnguin> package in question is evolution, if that helps
<mpontillo> pwnguin: in case it helps, I wrote a quick and dirty shell function to do that; see http://paste.ubuntu.com/179606/
<mpontillo> (you'd have to be careful using it on quilt packages since it doesn't read the 'series' file. but it looks like evolution uses cdbs.)
<pwnguin> mpontillo: i think i found a bugfix in upstream git
<mpt> ArneGoetje, it would ease reading of the schedule if "Roundtable discussion about what we can improve for translations" was shortened to "Roundtable: Improving translations" or similar
<TheMuso> dtchen: I have an idea about what could be causing the many 0 volume on logoff/logon/reboot for people. Are you down stairs in the lobby at all? If not, I'll meet up with you in person later to discuss it.
<stgraber> TheMuso: hey 1
<liw> TheMuso, what does "the many 0 volume" mean? (I ask, because my laptop beeps when it starts a reboot, and that annoys me, and perhaps that's related?)
<TheMuso> liw: No its not related, but its known. By 0 volume I mean the sound is turned down completely, so you have to open alsamixer et al to change it.
<TheMuso> stgraber: hey!
<liw> ah
<TheMuso> woohoo! Bug 38000 is a sound bug.
<TheMuso> woops bug 380000
<ubottu> Launchpad bug 38000 in linux-source-2.6.15 "xserver-xorg-driver-ati needs radeon kernel module v1.23, finds 1.19 only" [Medium,Invalid] https://launchpad.net/bugs/38000
<ubottu> Launchpad bug 380000 in linux "No sound in Karmic Alpha" [Undecided,Incomplete] https://launchpad.net/bugs/380000
<pitti> hey
<geser> Hi pitti
<pitti> hey geser
<bigon> could some one accept empathy in the karmic new queue?
<didrocks> that's so quiet during UDS :)
<didrocks> FYI http://summit.ubuntu.com/uds-karmic/ is down :/
<Turl> hi
<Turl> how can I request this to be synced? http://packages.debian.org/search?keywords=proxychains&searchon=names&suite=experimental&section=all
<nellery> Turl: see https://wiki.ubuntu.com/SyncRequestProcess
<Turl> thanks nellery
#ubuntu-devel 2010-05-24
<Lexxz> hi
<Lexxz> how do i change file names from console?
<Lexxz> in Linux
<blue_anna> can anyone clue me in on /usr/share/X11/locale?
<blue_anna> normally if I wanted to define a dead key I would do it in the Compose page for the locale, but spanish for example doesn't have a locale defined here, instead using teh default. If I wanted to flesh out spanish with my own custom locale so I could manipulate the dead keys, what would I need to build in that directory?
<blistov> Anyone know how to boot lucid alternate from usb?  alternate REALLY wants a cdrom.  Posted solutions for other variants doesn't work.
<ScottK> blistov: I know people have had success using usb-creator-kde from Lucid with at least the server CD (which is the same installer as the alternate CD).
<blistov> ScottK, any idea if the alternate cd is going get fixed in the future?
<ScottK> I don't think it's the alternate CD that's broken.
<blistov> It boots from USB, but refuses to read the install media from the boot media (unless the boot media happens to be a cdrom ).
<blistov> Every other distribution of Linux (including Ubuntu) is able to correctly read install media from ... any physical media.
<blistov> This is a huge problem for server installations.
<blistov> I'm not sure our company even owns a server with a cdroom.
<johanbr> blistov, try unetbootin maybe?
<blistov> johanbr, Thats what I'm using.
<blistov> Again, I can boot the image, but the installer doesn't even give you ann option to install from any media other than a cd.
<johanbr> so you didn't try usb-creator?
<blistov> no.
<blistov> trying now, but I can't imaging its going to make changes to the actual installer...
<johanbr> then I would recommend that, that's the official method for putting images on usb media
<ScottK> blistov: I helped someone with this exact problem a few days about and usb-creator-kde worked for them.
<blistov> ScottK, and johanbr, That did it.
<blistov> Thanks a tonne guys.
<ScottK> blistov: Please go complain to unetbootin about not working for this situation.
<johanbr> you're welcome
<ScottK> Yes, you're welcome.
<blistov> :)
<imbrandon> yes usb creator works for server installs , its how i do all the server installs that arent PXE here
<Chipzz> blistov: you are wrong, period
<Chipzz> I have installed alternate/server over the network, using pxe
<Chipzz> no offence, but if it doesn't work, that's because you are doing sth wrong, not because sth is broken
<SpamapS> ugh.. us.archive.ubuntu.com seems to be made up of hosts with an allergy to Los Angeles.. 512kbit? Really? :-(
 * SpamapS hopes University of Oregon is happy w/ his mirroring. ;)
<lifeless> SpamapS: us.a.u.c is london
<lifeless> SpamapS: but you should be able to get more than 512kbit out of them
<lifeless> SpamapS: also #ubuntu-mirror for mirror stuff
<lifeless> sorry, -mirrors
<SpamapS> Ugh I'm in something like 12 ubuntu- channels already.. how many must I join? ;-)
 * SpamapS takes his bleary eyed sleep-needing whining where it belongs.. to bed. ;)
<lifeless> no, you don't have to join; was just letting you know
<SpamapS> thats cool I may actually ask about it in there
<pitti> kees: well, that's the plan, but it's apparently not that easy to do, and so we disable the script in lucid for now to prevent more damage; Chase was going to change it into an example script which you can copy to /etc/
<SpamapS> pitti: whoa.. I don't know if thats wrong window or major lag.. but.. what script are you referring to?
<zyga> hello
<alkisg> When does the debian synching occur for Maverick? E.g. when will udhcp be imported from sid? https://bugs.launchpad.net/ubuntu/+source/udhcp/+bug/566845
<ubottu> Ubuntu bug 566845 in udhcp (Ubuntu) "Please update udhcp from debian" [Undecided,New]
<cjwatson> alkisg: syncing is already happening
<cjwatson> alkisg: that bug is equivalent to "cjwatson needs to get round to merging busybox
<cjwatson> "
<alkisg> Ah, got it :)
<alkisg> Heh
<alkisg> Thank you, I'll just check periodically then.
<tseliot> cjwatson: as regards LP: #580763 what version shall I use for the package in maverick?
<cjwatson> tseliot: up to you, as long as it's distinct and greater
<gnomefreak> is libc6-i686 needed or is it in the libc6 package?
<cjwatson> tseliot: if you want to use -0ubuntu1 for maverick and -0ubuntu1~10.04 or something for lucid-proposed, that's fine too
<gnomefreak> ^^ 10.10
<cjwatson> gnomefreak: no longer needed and in fact no longer existing
<gnomefreak> cjwatson: thanks
<cjwatson> we're moving to i686 across the board
<tseliot> cjwatson: ah, ok I'll use ~10.04, thanks
<tseliot> cjwatson: I think you'll have to reject my last upload before I can do that though
<cjwatson> tseliot: not actually true, but I can do it anyway
<cjwatson> (done)
<tseliot> cjwatson: thanks
<blue_anna> in Lucid, Compose sequences can only consist of two characters, and may only output one character. This makes them exactly equivalent to dead keys. but many useful example ~/.XCompose files online make use of 3 combining characters (in vitro w/ 2) or output multiple keys (digraphs)
<blue_anna> how can I get that functionality ?
<Pretto> any testdrive devel here?
 * hyperair wonders what to make of all sabdfl's mails having a bad signature
<sabdfl> que?
<hyperair> well, so says enigmail anyway =p
 * xnox loves sabdfl's french =)
<hyperair> gpg: Signature made Monday 24,May,2010 08:02:57 PM SGT using DSA key ID D54F0847
<hyperair> gpg: BAD signature from "Mark Shuttleworth <mark@ubuntu.com>"
<sabdfl> hmm
<hyperair> =p
<sabdfl> could be a MIME / T-bird thing. which mail?
<hyperair> the one you just sent on ayatana around 13 minutes ago
<hyperair> but yeah, it could be
<hyperair> i think enigmail has some issues with html mail
<blue_anna> and - why does compose-c-c give me a Ä - everywhere in gnome apps but no where in qt apps? its not defined in my system's compose files: http://pastebin.org/274106
<blue_anna> and - why does compose-c-c give me a Ä - everywhere in gnome apps but no where in qt apps? its not defined in my system's compose files: http://pastebin.org/274106
<G> kirkland: ping, do you happen to be around atm?
<kirkland> g: yes
<G> kirkland: have you had a chance to look at LP#571093 (libvirtd eating memory over time) the last couple of days?
<G> kirkland: I think I might be able to supply a rough patch to prevent it (trying to build it now)
<kirkland> g: we know that it exists, and there are a handful of upstream memory leak changes in upstream libvirt git
<kirkland> g: i haven't had a changes to zero in on it yet
<kirkland> g: if you have a patch, i'd love to see it, will help get it sponsored
<G> kirkland: AFAIK upstream havn't changed this function in 0.8, I'm trying to prevent it by making sure we free the memory if we are returning non 0
<G> (or any of the related functions for that matter)
<kirkland> g: oh?
<G> kirkland: I think this is a new bug due to udev rules in Debian/Ubuntu, I couldn't reproduce it under Fedora, but the udev rules there are totally different
<kirkland> g: oh, interesting, thanks for narrowing that down
<blue_anna> in Lucid, Compose sequences can only consist of two characters, and may only output one character. This makes them exactly equivalent to dead keys. but many useful example ~/.XCompose files online make use of 3 combining characters (in vitro w/ 2) or output multiple keys (digraphs)
<G> kirkland: I'm Nigel Jones in the bug btw
<blue_anna> how do I get that functionality
<G> hmmmm great, certainly reduces the effect of the leak
<kirkland> g: thanks
<kirkland> g: but does not prevent it?
<G> kirkland: valgrind showed two major leaks
<G> I'll take a look at the second now
<G> I wonder if it's leaving a device entry around somewhere
<G> it's only about 8k RES during a multipath -F/multipath -v4 though so it has reduced
<cjwatson> blue_anna: it would seem nobody here knows.  Perhaps you should try mailing the ubuntu-x list?
<kirkland> g: gotcha
<blue_anna> cjwatson:  thanks, I guess I'll try that too
<G> kirkland: okay, I think I got rid of the second memory leak, I'll attach the patch to the launchpad with my explanation for the second fix too
<kirkland> g: thanks
<G> kirkland: just posted my patch
 * kirkland checks
<G> kirkland: RES memory use appears to be stable now except for the odd increase/decrease but it no longer corresponds to when I run multipath
<kirkland> g: patch looks perfectly reasonable to me
<kirkland> g: could you take the to-do of sending this patch to the upstream list, while I work on getting the SRU together?
<G> kirkland: sure
<G> if I can remember my RHBZ password that is :P
<kirkland> g: post the libvir list
<G> oh okay, even better :)
<G> I guess they'll want it in git format iirc?
<kirkland> jdstrand: around?
<kirkland> jdstrand: G just posted a simple patch that purportedly fixes https://bugs.edge.launchpad.net/ubuntu/+source/multipath-tools/+bug/571093
<ubottu> Ubuntu bug 571093 in multipath-tools (Ubuntu) "multipath + libvirtd eats away more memory over time" [Medium,Triaged]
<kirkland> jdstrand: i'm just verifying that, and will upload a package to lucid-proposed
<kirkland> jdstrand: just wanted to give you a chance for feedback first ;-)
<kirkland> g: can you give me a few specific instructions on reproducing the leak?
<G> kirkland: okay, well the easiest way I found was that w/ multipath having no configuration multipath -F followed by multipath -v4 would generate the required udev add/change/remove calls
<G> kirkland: an examplehttp://paste.ubuntu.com/438911/
<pitti> SpamapS: I was replying to kees, not to you
<G> kirkland: any method of triggering the add/remove udev calls should reproduce the issue btw
<kirkland> g: cool, i'm on it
<kirkland> g: hmm, I'm running this, without seeing a leak:
<kirkland> for i in $(seq 1 10000); do sudo multipath -v4 >/dev/null; sudo multipath -F >/dev/null; free; done
<G> kirkland: do you see anything in udevadm monitor?
<kirkland> g: hmm, no
<G> kirkland: oh, I found running 'top -p (pidof libvirtd)' was the best way of keeping track of it
<kirkland> g: yeah, nothing, yet
<kirkland> g: no events in the monitor
<G> kirkland: what ouput do you get from 'multipath -F; multipath -v4'
<G> *output
<SpamapS> pitti: I understand you weren't talking directly to me. I was just curious what sort of script was doing damage.
<pitti> SpamapS: the pm-utils-powersave-policy one for spining down SATA drives
<SpamapS> pitti: interesting
<kirkland> g: http://paste.ubuntu.com/438920/
<G> kirkland: hmmm, the only thing different is 'mapp already present'
<G> kirkland: if you do multipathd -k and at the prompt run 'show config' it's empty?
<kirkland> g: correct
<G> the only thing I can think of is at first, I had an issue where udev was in a weird state
<G> (when I was first reproducing it)
<G> I could reproduce it, then udev would act up and stop producing the add/remove calls
<G> ah ha
<G> kirkland: yeah, thats the issue
<G> kirkland: got an entry in /dev/mapper by any chance?
<G> for your HD that is
<kirkland> g: http://pastebin.ubuntu.com/438923/
<G> kirkland: bingo, I think we may have struck on a race condition in multipath? :P
<kirkland> g: hrm, interesting ...
<G> because I managed to get to the same point with 'while true; do sudo multipath -F; sudo multipath -v4; done;
<G> kirkland: tbh, when I got to that point I just rebooted
<G> and reproduced with: top -p (pid of libvirtd) in one terminal, and manually running 'multipath -F; multipath -v4' in another terminal and watching RES going up
<kirkland> g: i'm running your while true, no leak
<kirkland>  1047 root      20   0  188m 7192 2960 S    0  0.2   0:00.37 libvirtd
<kirkland> g: i'm pegged there
<kirkland> g: 7192 constant
<G> kirkland: if that map already present message is still there, I'd expect it to peg there
<kirkland> g: so how do I try to re-trigger the race?  reboot and let udev redect my hard disk?
<G> kirkland: I'm just trying to work out what multipath is looking for regarding that issue
<G> kirkland: ah ha!
<G> kirkland: without a reboot: dmsetup ls, if it's there with (252, 0) do a 'dmsetup remove <string>'
<G> kirkland: that fixed my multipath
<G> so it's actually a dmsetup/multipath race
<kirkland> g: hmm, okay, so this is a bit outside my expertise
<kirkland> g: what's dmsetup remove going to do?
<G> kirkland: remove the map that multipath created but couldn't remove, if like me, the HDD is mounted traditionally (like /dev/sda1 etc) then it won't effect mounted partitions
<G> dmsetup = device mapper, and just creates fancy references, mainly used for multipath & LVM
<kirkland> g: i'm mounted by UUID
<G> kirkland: yeah, UUIDs won't be effected
<kirkland> g: and after I do this, I'll reproduce the leak?
<G> yep should do, but do it slowly with just: multipath -F; multipath -v4
<G> and wait a sec before doing it again
<G> I think the problme with the do while loops is it tries to flush before the map is created
<kirkland> g: okay, now i have activity in udev admin
<kirkland> g: and yeah, now i see a memory leak
<G> good and the RES memory usage should be going up for libvirt
<kirkland> g: correct
<G> kirkland: great :)
<kirkland> g: okay, so I've reproduced this;  can you post an update to the bug with your race condition analysis?
<G> with the patch the starting RES should be lower than without (because it's fixed for startup) and then also it shouldn't go up during normal usage
<G> kirkland: actually, the race condition is seperate, it's really a new bug
<G> which I'll create
<kirkland> g: i see your post to the libvir list, thanks ;-)
<G> kirkland: was just waiting till I was certain that you'd be able to reproduce the issue :)
<kirkland> g: heh, okay, i just need to document how to reproduce it for the SRU
<G> kirkland: no problem
<ScottK> doko_: Did you plan on uploading your last Ubuntu twisted fix to Debian so we can sync it?  I see some builds failing for lack of an update and a sync would be nicer than a merge....
<G> kirkland: btw, for the race condition: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/585027
<ubottu> Ubuntu bug 585027 in multipath-tools (Ubuntu) "Race condition with dmsetup causes 'map already present' messages" [Undecided,New]
<G> kirkland: anything else I need to do, or can I just leave it with you?
<kirkland> g: just one sec, review my update
<G> kirkland: sure, let me know when it's up
<kirkland> g: http://pastebin.ubuntu.com/438949/
<G> kirkland: for IMPACT: I'd remove the system loses a udev race on boot bit
<G> the race condition that we experienced just impacted our ability to hit the bug
<G> the impact is really any system w/ libvirtd running while udev add calls are occuring
<G> kirkland: to avoid the race condition in the while true loop, maybe add a sleep 1 or something like that to let udev/dmsetup/multipath to settle
<kirkland> g: okay
<G> kirkland: but yeah, that sounds about right
<G> (I'd put the sleep 1 bit after multipath -v4
<kirkland> g: thanks, uploaded to lucid-proposed
<G> kirkland: cool, thanks for looking at it, I think I might look at some of the libvirt bugs sometime too, that one just got me really interested though :)
<kirkland> g: cheers, thank you;  *great* job tracking it down
<kirkland> g: the libvirt bugs could certainly use a hug from someone with an interest in fixing some of them ;-)
<G> kirkland: yeah
<G> kirkland: must say, valgrind was the biggest help
<G> kirkland: well, have a good day! :)
<G> kirkland: oh I guess I should also forward this to the debian.org BTS so they can apply the patch there as well
<kirkland> g: that would be good, yeah
<G> kirkland: if you want, I can do that in the morning
<kirkland> g: nice, you got an ack on the upstream patch too, great
<G> oh, haven't seen that yet
<G> kirkland: oh thats great news
<mpagano_> Does ubuntu have a web front end to commits?
<blue_anna> I've mostly got my compose issue worked out now
<blue_anna> the main thing that's got me confused is gnome-terminal and firefox don't accept many-key compose sequences, and won't output  more than one character -- it only works for definitions that are like deadkeys
<blue_anna> everything else, xterm, opera, kde apps .. they all work with like for example compose+b+t+w = "btw"
<blue_anna> or "by the way" I was being quick :)
<blue_anna> https://help.ubuntu.com/community/ComposeKey - I was following this guide
<ion> Hit compose, release it and then hit the rest.
<blue_anna> both ways, it works or it doesnt. like compose+t, m works. so does compose, t, m
<blue_anna> but compose, b, t, w does not -- unless I'm using anything other than gtk
<blue_anna> I have explicitly set GTK_IM_MODULE like it says to in the guide
<blue_anna> ion: not sure what's up with it
<blue_anna> ion: you still here?
<blue_anna> the gtk people tell me that xim is not the preferred im because it is buggy. I am getting one of those bugs with my particular set up. what is the suggested lucid alternative to xim for custom compose keys ? https://help.ubuntu.com/community/ComposeKey -- this says xim but like I said that's known not to work
<blue_anna> do you know how to get Xcompose working with ibus? there are some unanswered posts on ubuntuforums about that but no solutions
<persia> blue_anna: I believe ibus is the recommendation
<blue_anna> persia: yeah I heard that now, thanks
<rascal999> sudo service statd start -- fails with Warning: Fake initctl called, doing nothing. Any ideas?
#ubuntu-devel 2010-05-25
<slangasek> rascal999: you can't run an upstart-managed service in a chroot
<rascal999> slangasek: i'm not
<rascal999> it's a vm, that's the only difference
<slangasek> rascal999: if you're not running in a chroot, why is /sbin/initctl a "Fake initctl"?  That's not the behavior of the upstart package shipped in Ubuntu
<progre55> hi guys. I've got a core 2 duo, and my second CPU has been showing "0% usage" for a while now.. I'm kinda concerned.. any suggestions, please?
<SpamapS> progre55: start a bunch of CPU hungry stuff... gzip -c /dev/zero > /dev/null works. ;)
<progre55> SpamapS: only 1 CPU shows 99-100% and the other one is still 0%
<SpamapS> progre55: weird
<progre55> SpamapS: oh, nvm. apparently it was the widget that went wrong.. I was using the system monitor widget to see the cpu usage, but htop shows that both cpu's are being used :)
<SpamapS> haha indeed
<Riddell> james_w: did you do syncs yesterday?  they're not flushed
<Drakeson> could you please try and see if emacs23 works in current maverick? (e.g. do an "emacs -Q" and see if it appears)?
<Drakeson> I am not sure if I broke my system or a library is changing
<Jayd3e> what are the first steps one would have to take to start learning to become a developer?
<baddog_> Drakeson, X protocol error: BadMatch (invalid parameter attributes) on protocol request 2
<baddog_> Seems like it might be broke
<Drakeson> Jayd3e: the first one should be "find a project you would want to develop in"
<Drakeson> baddog_: thanks, I get the same error. Now I don't need to build yet another chroot to make sure :D
<baddog_> :P
 * baddog_ goes to see if a bug is already there
<Drakeson> I cannot even guess which library got updated since around May 21 that broke emacs
 * Drakeson whishes he know a dpkg equivalent of "git whatchanged"
 * baddog_ files a bug (first ever!)
<blue_anna> what would cause the session menu to not show on the login screen?
<RAOF> Drakeson, baddog_: That's probably (more) fallout from the big GTK c-s-d/argb change.
<baddog_> oooh.
<RAOF> Drakeson: Also, /var/log/dpkg.log
<ScottK> RAOF: Speaking of CSD, it seems very clear the kwin developers are firmly against it.  Is this something GTK is really comitted too or are they experimenting?  Do you know?
<RAOF> ScottK: A variety of people have been wanting it for some time (including X devs).  I think *we're* pretty committed to it, and I don't think there are any in-principle objections GTK-side.
<ScottK> Interesting.
<ScottK> It seems like an odd thing for people wanting desktop consistency to want, but OK.
<Drakeson> RAOF: thanks. So, is this emacs that should be patched to be prepared for client-side-deco or the gtk libs should just work?
<RAOF> ScottK: There's no reason why kwin people need to care at all; my understanding is that it'll only be switched on if the window manager says âhey, I can handle client-side-windowsâ.
<RAOF> Sorry, client-side-decorations.
<ScottK> It seems then like a lot of trouble for something that will always need a fallback position if c-s-d isn't supported.
<Drakeson> honestly, I am [only] a bit biased against CSD since I remember some nasty windows apps (like yahoo messenger) who happened to draw their aweful window decorations, too.  Hopefully this doesn't happen here ...
<RAOF> Drakeson: That's already possible - csd in GTK would make that less likely, as there'd be a nice standardised interface.
<Drakeson> RAOF: that's good to hear.
<Drakeson> Should I try to patch emacs for now, or it is gtk libs that will have to get fixed ?
<RAOF> I'd start by looking at emacs.
<Drakeson> RAOF: I see, thanks
<kyle_> could anyone tell me what to mount my partition at? I am installing over an old distro and have another  os on here already. I want to over write sda1 (ext2) I chose use as Ext2 file system and think the mount point should be "/" but am unsure. Advice?
<kyle_> wait i think i am in the wrong node. Sorry
<ScottK> kyle_: Yes.  You are.  You want #ubuntu.
<baddog_> emacs23 is complaining about not having makeinfo, which doesn't seem to be in the repos anywhere ._.
<baddog_> on Maverick
<spiv> baddog_: I think that's part of the texinfo package, which I don't think has changed since lucid?
<baddog_> ooh. maybe
 * baddog_ is new to all this ^_^
<pitti> Good morning
<dholbach> good morning
<ara> morning dholbach!
<dholbach> hola ara!
<robert_ancell> cjwatson, can you add gucharmap to the ubuntu-deskop upload list?
<apw> can anyone point me to the wiki page which lists the support lifetimes for various bits of each series
<SwedeMike> series, as in releases?
<lifeless> http://www.ubuntu.com/products/ubuntu/release-cycle%20
<SwedeMike> it's actually on the first page of wiki.ubuntu.com, also first hit on google <ubuntu release schedule>
<cjwatson> also for >=lucid: apt-cache show PACKAGENAME | grep ^Supported:
<apw> lifeless, that is close, but it only carries the general life times.  somewhere there is a more specific page on lifetimes for each kernel variant etc
<apw> cjwatson, yeah its jaunty that i am trying to find the same information
<lifeless> apw: are the variants separated into server/desktop ?
<apw> lifeless, no this is more detailed again, for arm branches and the like
<apw> there were some 20 or so lines in the table i think
<lifeless> ok, that I haven't seen - sorry
<cjwatson> mvo: can you see why e.g. lynx still has Supported: 5y for maverick?  I moved SUPPORTED_HINTS aside to SUPPORTED_HINTS.LTS in the platform.maverick seeds in an effort to make that go away, but it doesn't seem to have taken ...
<cjwatson> Riddell: the syncs were probably me - it was OK to flush them
<cjwatson> Riddell: oh, except for the way I imagine the flush partially failed because you didn't know to remove the syncs that will only work once my LP patch is rolled out :)
<cjwatson> so you can probably rm -rf sync-queue/rejected/jriddell-20100525-010510 as lp_queue
 * cjwatson starts another autosync pass
<mvo> cjwatson: let me have a look
<cjwatson> smoser: FYI, if you follow up to an RT ticket to say "thanks", it reopens the ticket automatically ... I'm resolving RT#39454 again
<Chipzz> cjwatson: the irony :)
<ogra> cjwatson, pitti, i'd like to make bug 568736 an SRU because i plan to build the 10.07 image based on the lucid seed, i talked to slangasek already at UDS, he said he would be fine with it if another ubuntu-sru member agress (i want to ask in advance before i mark the bug SRU)
<ubottu> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/568736)
<ogra> (it requires a netbook-meta upload to take effect but its armel only
<ogra> )
<cjwatson> ogra: I'm fine with that change in an SRU
<ogra> great, thanks
 * ogra changes the bug then
<pitti> asac, didrocks, StevenK: hm, seems the go-home-applet launches netbook-launcher instead of going back to n-l-efl?
<didrocks> pitti: that's weird, some people are telling that and others are telling it's working fine. I remember of an explicit fix from jamiebennet about it
<ogra> pitti, i thik thats a known bug
<ogra> didrocks, i can confirm
<pitti> didrocks: do you see any reason why we need it at all? the standard "show desktop" applet seems to work just fine?
<ogra> it only happens though if your graphics card is actually composite capable
<pitti> right, it is
<ogra> pitti, drag n drop features
<didrocks> pitti: well, this applet is a little bit more than "show desktop"
<ogra> it adds urls to the favorites if you drop them on the applet
<didrocks> pitti: if you drag and drop an url, it's added as a favorite
 * pitti disables DRI and checks agao
<didrocks> ok, ogra is faster than I :)
<ogra> heh
<ogra> pitti, mv /usr/bin/netbook-launcher /usr/bin/netbook-launcher.bak && ln -s /usr/bin/netbook-launcher-efl /usr/bin/netbook-launcher will fix the issue
<ogra> its ugly but works :)
 * pitti disabled the DRM udev rule
<pitti> works fine now, thanks
<ogra> proper solution wuld be to be able to uninstall netbook-launcher but there is a dependency issue
<pitti> right, I'm just going to fix that to be an |
<ogra> it works then as well
<ogra> yeah :)
<pitti> but I wanted to make sure that go-home-applet is useful for efl
<ogra> it is
<pitti> cheer!
<pitti> s
<ogra> though with the new upanel i'm not sure it will still work :)
<ogra> we're supposed to get a simple gtk container that replaces the panel and only provides hooks for the indicators
<pitti> didrocks: do you know if there's a packaging bzr for it? I only see an upstream trunk, and no vcs-bzr
<ogra> not sure if an "applet" will work in that (it shouldnt since we dont want gnome deps)
<didrocks> pitti: no, I sometimes push directly to ubuntu/go-home-applet
<pitti> didrocks: that's fine, thanks
<pitti> ogra, didrocks: reading the code, it calls netbook-launcher directly; favourite d&d doesn't actually work
<ogra> aww
<pitti> ... with -efl, I mean
<didrocks> pitti: I don't know, I hadn't the time to test n-l-efl too much :(
<pitti> it'd need to check the running process
<pitti> ok, thanks so far!
<ogra> pitti, btw i have netbook running on my touchbook
<ogra> there is an issue with the battery though, it doesnt load with the kernel i rolled
<ogra> once i have that solved i'll put a dd-able image on people.c.c ;)
<Ixan> has there been a regression with preseed from rc1 to 10.04? my preseed script doesn't execute correctly anymore. I've used wget with -O -|sh to download a script and run in-target. it just echoes everything to the log in console 4 now, doesnt execute the script at all.
<Ixan> script runs fine from the console during the installation though, using the identical string given to preseed/late_command
<smoser> cjwatson, whoops. thank you (was that thanks ok ? )
<cjwatson> smoser: IRC doesn't reopen RT tickets ... so far :-)
<cjwatson> Ixan: nothing I know of, happy to investigate based on full preseed file (with any passwords removed) and log files
<cjwatson> Ixan: I recommend running the installation with DEBCONF_DEBUG=developer as a boot parameter to get the most useful log files
<Ixan> okay, i'll append that. I'll try to remove the stdout pipe now and see if it can write to a file then execute it instead. will be bothersome later , if that doesn't work either :)
<cjwatson> I'm not aware of any of wget, sh, or preseed having changed in a way which might be relevant.  of course if the script uses debconf then piping it to sh that way would never have worked reliably
<cjwatson> so that could be a source of problems
<cjwatson> (note it might use debconf indirectly e.g. by installing a package)
<rascal999> slangasek: shall i reinstall initctl then?
<ccheney> is there a tool like that which displays for totem codecs that i could have run to ask a user to install a package?
<ccheney> looks like something like packagekit could do it but its not on the cd currently so would be problematic to use it
<ccheney> so i guess my question is more is there anything on the cd that could do it, or example code to do something like what totem/gst does
<cjwatson> I believe it's gstreamer-codec-install
<ccheney> cjwatson: ok
<cjwatson> apt-get source gnome-codec-install
<ccheney> yep about to grab it now, just had to update my sources.list since i am at a hotel :)
<ccheney> cjwatson: thanks for the pointer
<cjwatson> that's ok, I don't know much more about it, mvo would know more
<mvo> ccheney: what excatly do you want to do? "apturl apt:2vcard" is one way of doing it, in maverick we will get native session PK api support
<mvo> ccheney: you can also use aptdaemon, it depends a bit on your use-case what is best (easieist is certainly apturl)
<ccheney> mvo: i know the package already to install i just to prompt the user for if they want it, the java stuff for OOo that can't fit on the CD
<ccheney> s/to/need to/
<mvo> ccheney: apturl is probably best then for now (lucid)
<ccheney> ok
<ccheney> mvo: will look into it, thanks for the help
<mvo> ccheney: np. it has a relatively good man-page nowdays and work on both gtk/kde
<ccheney> great :)
<cjwatson> I've synced in the bulk of entirely new source packages from unstable now; not contrib or non-free yet, and not yet sources which produced binaries that clashed with existing binaries in the archive
<cjwatson> I also excluded everything that already had publication records in the Ubuntu archive, indicating that they'd been removed at some point; those will all need manual investigation
<cjwatson> but that's 352 new source packages so should keep everything busy for a while
<Daviey> cjwatson: Have you created a list?
<cjwatson> nope
<ccheney> mvo: is there a way display something to explain to the user why apturl is displaying its box, would that be done with zenity or some other way?
<cjwatson> may do at some point if it's hard enough to process :)
<Daviey> cjwatson: Just fancied having a browse.. low hanging fruit and all that. :)
<mvo> ccheney: currently not, its a nice idea though. do you need it for lucid or maverick? if the later I can add a feature for it
<ccheney> mvo: maverick primarily i may try adding it to lucid if its approved after getting it working for maverick
<cjwatson> the packages that previously had publication records are:
<cjwatson> afflib arc-colors b2evolution bcov bml boost1.39 bsl dyndns fast-user-switch-applet flush gcc-3.3 gcx gdm-themes git gjay glee graphy grub-choose-default guidance-power-manager ibutils kbiff kfocus kqemu libjboss-buildmagic-java libjpeg7 libunicode-map8-perl libxr life mscore ns3 ojs php-clamav ploader pyjamas python-couchdbkit python2.5 qca qgis re2 saga snowball splashy sugar-0.84 sugar-0.86 sugar-artwork-0.84 ...
<cjwatson> ... sugar-artwork-0.86 sugar-base-0.84 sugar-base-0.86 sugar-browse-activity-0.86 sugar-chat-activity-0.84 sugar-hulahop sugar-presence-service-0.84 sugar-presence-service-0.86 sugar-read-activity-0.84 sugar-toolkit-0.84 sugar-toolkit-0.86 t2html task texfam ubuntulooks urg ust wacom-tools wine xfmedia xtel xulrunner
<ccheney> mvo: i can always do it in a different way for lucid if its acceptable
<mvo> ccheney: ok, for lucid its probably best to just add zenity around it (or a small python script)
<ccheney> ok
<Daviey> cjwatson: suprised to see git :/
<cjwatson> I imagine that's the project name clash thing being resolved
<cjwatson> probably wants to be synced
<Daviey> ahh
<ccheney> hmm there is a small problem with using zenity in that it wouldn't easily be translatable I think?
<cjwatson> it would be the caller's responsibility to handle translation
<sebner> cjwatson: funnily, autosync synced gdm3 (which is 2.30.2-3), out gdm in maverick is 2.30.2-0ubuntu1
<cjwatson> sebner: heh, I missed that, bound to be the odd mistake
<cjwatson> should I remove that again?
<cjwatson> seb128: ?
<seb128> cjwatson, yes please
 * sebner guesses a blacklist add is needed too
<cjwatson> yes, I'll take care of that
<cjwatson> (done)
<sebner> :)
<lool> Hmm where's doko
<lool> ~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~/win 1
<lool> Ups
<lool> Interesting
<ogra> heh
<ogra> pitti, i'm trying to make sense of http://bazaar.launchpad.net/~work-items-tracker-hackers/launchpad-work-items-tracker/trunk/annotate/head:/config/maverick.cfg for the mobile team specs (nothing shows up on the tracker yet) could it be that "mobile-|preinstalled-sd-card" needs to be in brackets ?
<blue_anna> can I get help getting i2c-core module for my build? it's not in my kernel and I don't see an alternative in the repositories
<ogra> blue_anna, try #ubuntu-kernel for kernel related questions
<blue_anna> thanks
<slangasek> rascal999: if you don't know why you have a fake initctl in place, reinstalling upstart may not fix the problem
<maco> bdrung: Re: https://lists.ubuntu.com/archives/ubuntu-devel/2010-May/030754.html  <-- i bzr branch'd ubuntu-dev-tools and pbuilder'd it for Lucid, and "syncpackage" is very Not Happy  http://paste.ubuntu.com/439419/
<bdrung> maco: you need the launchpad credentials, see manage-credentials how to get them
<bdrung> maco: or we need to improve syncpackage to use the anonymous launchpad login. i have to leave now. see you later.
<bdrung> (or drop me a mail)
<maco> hrm. need to figure out what a "consumer" is
<maco> um yeah that didnt work
<maco> it spit the html source of a 403 at me
<pitti> ogra: it shouldn't be necessary to add parentheses
<ogra> pitti, hmm, then i wonder why nothing shows up at all
<ogra> pitti, i mean i wont complain, http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html promises an easy dev cycle :)
<pitti> ogra: hm, nothing mobile-ish on http://people.canonical.com/~pitti/workitems/maverick/all.html, too
<ogra> pitti, there is one special case (not sure why, we could just rename it) https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
<pitti> ogra: https://blueprints.edge.launchpad.net/ubuntu/maverick/+specs?searchtext=mobile only has one spec, though, and that one has no WIs
<ogra> that should at least show up
<ogra> pitti, ugh
<pitti> ogra: I removed the empty line after work items:, should turn up next cycle
<ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-m-lightweight-panel-for-efl and https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-m-image-builds-without-root should definately be there too
<pitti> i. e. in an hour
<pitti> ogra: no, they aren't targetted at maverick
<pitti> "Series goal: None"
<ogra> gah
 * ogra fixes
<seb128> cjwatson, pitti: could bug #571329 be accepted to updates now?
<ubottu> Launchpad bug 571329 in xsane (Ubuntu Lucid) "No translation for xsane in lucid" [Wishlist,Fix committed] https://launchpad.net/bugs/571329
<pitti> seb128: right, tagged v-done
<seb128> pitti, thanks
<pitti> and moved to -updates
<seb128> thanks ;-)
<robbiew> boy...firefox could cause people seizures in Maverick...flickerific
<robbiew> lol
<cjwatson> right, I've been dealing with things that are marked green and over the aging period on the pending SRU page, but I haven't been able to go through v-needed bugs and check whether they should be v-done
<seb128> cjwatson, btw could you pocket copy things you accept to maverick too? pitti has been doing that usually, that avoid having to do another version upload to maverick, ie less work
<seb128> cjwatson, well as long as lucid and maverick versions are identic
<cjwatson> seb128: yes, I've been doing that
<cjwatson> may be a couple behind, I haven't done it since last week
<seb128> ok, thanks
<apw> cjwatson, are we expecting a debootstrap backport for lucid ?
<ogra> apw, iant maverick support already in ?
<ogra> *isnt
 * ogra tests
<ogra> yes, seems to work
<cjwatson> apw: yes, debootstrap already had maverick support when lucid released
<cjwatson> so no need for a backport
<apw> cjwatson, hrm, i'll go hit things till it stops lieing to me :)
<ogra> apw, upgrade to the final release ! :P
<cjwatson> apw: https://launchpad.net/ubuntu/+source/debootstrap/1.0.20ubuntu1
<apw> it says its up to date ... must be some other tool whining
<apw> cjwatson, thanks must be smb's fault
 * smb slaps apw 
<apw> such cheek
 * mneptok pops some corn and begins taking wagers
<smb> apw, Maybe just the mkschroot not having a maverick section. Feel free to fix it
<apw> smb, could be... will check
<persia> mk-schroot shouldn't care: it ought rely on debootstrap.  That said, if mkschroot differs from mk-schroot, I'd like to know how and fix it :)
<tlb> what's the best way to get a new package(a small pam module) into Ubuntu?
<Laney> get it into Debian
<tlb> Laney, so what's the best way to get a new package(a small pam module) into Debian? :)
<Laney> haha
<Laney> find a sponsor and get said sponsor to upload it
<Laney> try #debian-mentors on oftc
<mathiaz> tlb: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<tlb> ok thanks :)
<Laney> maybe the maintainers of pam itself would be interested: try mailing pam@qa.packages.debian.org :)
 * Laney runs before one of them sees
 * mneptok does the "Going To DebConf 10" dance
<Sarvatt> looks like pkg-config in maverick is screwed up
<Sarvatt> pkg-config --cflags xorg-server
<Sarvatt> -fvisibility\=hidden -I/usr/include/xorg -I/usr/include/pixman-1
<Sarvatt> that -fvisibility\=hidden is making everything using xorg-server.pc fail
<geser> does the .pc file contain the \= or only a =?
<geser> know bug
<Sarvatt> Cflags: -I${sdkdir} -fvisibility=hidden
<geser> Debian bug #583009
<ubottu> Debian bug 583009 in pkg-config "Attempts to escape = char in Cflags" [Serious,Open] http://bugs.debian.org/583009
<Sarvatt> yeah
<Sarvatt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583005 too, tons more i'm sure
<ubottu> Debian bug 583005 in pkg-config "xserver-xorg-video-radeonhd: FTBFS: ../../src/rhd_driver.c:517: error: invalid storage class for function 'RHDPreInit'" [Serious,Open]
#ubuntu-devel 2010-05-26
<greenfish> i apologize if this is off topic... is there a debug kernel image available for lucid that i can use for profiling purposes?
<ccheney> shtylman: ping
<ccheney> shtylman: i saw your comment on 389623 but wasn't sure if you meant documents aren't supposed to be saved into $HOME/Documents on KDE or if you meant it just doesn't work for any locale when you closed it invalid, isn't $HOME/Documents a XDG dir that is supposed to be used for cases like this?
<pitti> Good morning
<ddecator> morning pitti
<ajmitch> morning pitti
<dholbach> good morning
<didrocks> good morning Mr Holbach :)
<dholbach> Salut didrocks
<tkamppeter> pitti, hi
<Laney>  	  #5
<Laney> Rebooting my system and attempting to reinstall did not correct the issue for me. My system consistently hangs when attempting to install assemblies into mono.
<Laney>  	  #5
<Laney> Rebooting my system and attempting to reinstall did not correct the issue for me. My system consistently hangs when attempting to install assemblies into mono.
<Laney>  	  #5
<Laney> Rebooting my system and attempting to reinstall did not correct the issue for me. My system consistently hangs when attempting to install assemblies into mono.
<Laney> oops
<Laney> sorry
<ajmitch> Laney: you obviously need to remove mono ;)
<Laney> REVEALED: Laney looks at mono bugs!
<ajmitch> *gasp*
<cjwatson> seb128: can the main task on bug 438434 be closed?  I see that maverick has 2.26.3
<ubottu> Launchpad bug 438434 in Drizzle "Valgrind errors - tree_or" [Critical,Invalid] https://launchpad.net/bugs/438434
<seb128> cjwatson, wrong bug?
<cjwatson> bug 438484
<ubottu> Launchpad bug 438484 in librsvg (Ubuntu) "Crash when thumbnailing an SVG file" [Medium,Fix committed] https://launchpad.net/bugs/438484
<seb128> cjwatson, yes
<seb128> doing that now
<seb128> cjwatson, thanks
<cjwatson> ta
<cjwatson> seb128: ditto bug 582178
<ubottu> Launchpad bug 582178 in pygtksourceview (Ubuntu Lucid) "2.10.1 stable update" [Wishlist,Fix committed] https://launchpad.net/bugs/582178
<seb128> same, closing it
<hyperlinx> my monitor is only of the Half of the existing surface
<seb128> cjwatson, do we need verification on all bugs?
<seb128> cjwatson, seems that 5 bug fix verified and no regression should be good to go
<seb128> we usually don't aim at fixing all issue but to have something better than the current version
<cjwatson> well, I thought it worth asking
<cjwatson> if the reporter says he can't, then we can look at the whole lot
<cjwatson> I was just doing a drive-by and hadn't read the other bugs in detail
<seb128> ok
<hyperlinx> my monitor is only of the Half of the existing surface
<mdz> is anyone else seeing sd_espeak and sd_dummy running with a blank argv[]?
<mdz> 13203 ?        Sl     0:00
<mdz> 13207 ?        Sl     0:00
<pitti> mr_pouit, davidbarth: is xfce4-panel capable of displaying indicators?
<seb128> pitti, it should since it can run applets too
<seb128> I guess you can add the indicator-applet to it
<seb128> pitti, switching to xfce?
<pitti> seb128: in a small VM
<ogra_cmpc> seb128, i bet pitti tries to solve the same prob i'm attacking with efl launcher for arm in maverick :)
<seb128> ogra_cmpc, disk space?
<ogra_cmpc> and ram
<pitti> I'm trying to run netbook-laucher-efl in an xfce session
<ogra_cmpc> what we discussed yesyerday, in maverick the 2D session will use as less gnome stuff as possible and get a gtk container as panel for the indicators
<ogra_cmpc> i'll have the spec ready this evening so you should be able to read up about the implementation
<ogra_cmpc> effectively the DX team will write us a minimal gtk panel
<davidbarth> pitti: it is, with the g-applet compatibility module
<davidbarth> pitti: ie, running indicator-applet, withing xfce g-applet applet; a bit convoluted, but that works
<ogra_cmpc> but likely doesnt save you much
<ogra_cmpc> (ram/diskspace)
<pitti> davidbarth: ah, it's in a separate package, I suppose?
<seb128> pitti, it is
<pitti> ah, xfce4-xfapplet-plugin
<seb128> yes
<pitti> thanks guys!
<ogra_cmpc> pitti, do you make a ram/diskspace comparison between xfce panel and a normal 2D session ?
<pitti> ogra_cmpc: I will
<ogra_cmpc> i would be intrested in data if you plan to collect any
<ogra_cmpc> cool !
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> There is still the problem with CUPS not being started by upstart, bug 554172. Have you any idea how to solve it, also some minimum-invasive way for Lucid?
<ubottu> Launchpad bug 554172 in cups (Ubuntu) "cups not starting at boot" [Medium,Confirmed] https://launchpad.net/bugs/554172
<tkamppeter> pitti, for me the whole backward compatibility mode of upstart seems to be broken, as users also complain about other sservices not starting.
<pitti> tkamppeter: unfortunately no, since I still don't know why it's not started in the first place :-(
<cjwatson> rc-sysinit.conf has 'start on filesystem and net-device-up IFACE=lo', so if lo never comes up for some reason, or if filesystems never get mounted, then the system will never enter runlevel 2
<pitti> davidbarth, ogra_cmpc: yep, works like a charm, cheers
<ogra_cmpc> cool
<cjwatson> some people have to put 'nobootwait' on some entries in /etc/fstab
 * ogra_cmpc is intrested in the resource usage we probably dont need upanel at all if its low enough
<cjwatson> this is not an upstart problem, it's (if anything) a mountall problem - although mountall will eventually be integrated into upstart
<pitti> ogra_cmpc: http://people.canonical.com/~pitti/screenshots/xfce-panel-indicators-nl-efl.png :)
<pitti> (yes, not themed yet, etc.)
<ogra_cmpc> pitti, looks great !
<tkamppeter> pitti, the bug is assigned to the CUPS package and when I assign it to upstart they simply assign it back to CUPS. Seems that whoever works on upstart is not convinced that the problem is in upstart.
<cjwatson> you can't just say "I don't understand this, must be in upstart", you need analysed evidence of what's going on
<cjwatson> full --verbose logs at the very least
<ogra_cmpc> but but ... upstart is so easy to blame :)
<mr_pouit> pitti: as you noticed, not natively (there is a xfce4-indicator-plugin, but it's not in the archive, and it doesn't work because the api changed too much)
<simonp> is this the right place to ask about a problem i have with debconf (im building .debs)
<simonp> or should i be in some other channel?
<cjwatson> simonp: maybe - what's the problem?
<simonp> im getting an error when testing. ive got my config and config.templates but when i run the config file (in debug) i get a 10 'cant find' error
<simonp> ive double checked, its not a typo
<simonp> ive tried using config.templates and also a standalone templates file
<cjwatson> config.templates is a bogus name, don't know where you got that from
<cjwatson> can you post the whole package somewhere?
<simonp> i got it here http://www.fifi.org/doc/debconf-doc/tutorial.html
<cjwatson> no you didn't, it doesn't say "config.templates" anywhere
<simonp> 'First, if there is a file with a name that is ".templates" appended to the name of the config script that is being run, debconf assumes that is the templates file.'
<simonp> ?
<simonp> my script is called 'config'
<simonp> therefore, config.tempaltes
<cjwatson> oh, that's a special case, don't do that
<simonp> ok
<cjwatson> that is for people doing weird stuff
<cjwatson> can you post the whole package somewhere?
<simonp> its not fully built, im still testing the debconf stuff. so i cant test it from command line, i have to build it and install to test?
<cjwatson> no, I mean the source package
<cjwatson> your debian/ directory anyway
<simonp> ok sec
<cjwatson> I don't care whether it's built or not
<simonp> http://pastebin.com/GTf4F3tW
<simonp> thats it in its most basic form
<simonp> :)
<cjwatson> uh, you really can't test debconf stuff like that
<cjwatson> not unless you know debconf very very well and know all the tricks
<simonp> ok so probly easier to use my own postinst then and skip debconf
<cjwatson> it's really much, much easier to get the package built and test it that way
<cjwatson> anyway, I notice two mistakes there
<simonp> ooh :)
<cjwatson> firstly, you shouldn't Pre-Depends: debconf because you don't need to - a Depends is quite sufficient (if you use Depends: ${misc:Depends}, dh_installdebconf will fill in the right thing for you)
<cjwatson> secondly, you have no postinst - see the second note under "Modifying Existing Maintainer Scripts" in that tutorial
<cjwatson> i.e. if you're using debconf in the config script, the postinst script needs to at least do  . /usr/share/debconf/confmodule
<simonp> yep havent done the postinst yet, was just tyring to get to grips with actually asking questions nad putthing shite in the db
<cjwatson> technically, the thing you were missing was calling debconf-loadtemplate, but it's easy to get that sort of thing wrong
<simonp> ahh! ok so i mis understood that, the way i read it was that it would find the temaplte based on a filename
<simonp> ill read up about that bat, cheers for the pointer
<simonp> bat?
<simonp> s/bat/bit/g
<simonp> cheers :)
<cjwatson> well, it does do that, just not the way you were trying to run debconf ...
<cjwatson> using the 'debconf' command itself is a very special-purpose thing and doesn't do that magic
<cjwatson> it's for debugging
<cjwatson> if you'd just executed the script directly it might have managed it
<simonp> awesome thats just fixed it :)
<simonp> you ledgend
 * simonp facepalms
<shtylman> ccheney: Is there an environment variable for this folder? cause right now, the save dialog defaults to $HOME unless openoffice itself hints at something different.
<maeon31> I have a long datafile with lines in it, boss wants Line-level encryption so some lines are encrypted and some are not, so that some lines cannot be read, but others can be.  What would be the best way to go about that?
 * wgrant is a little unsure about the whole new websites thing.
<wgrant> eg. the white on light grey on http://www.ubuntu.com/server, plus a whole lot of other little things.
<G> wgrant: it's going to get some people I agree, but the homepage etc is clearer now
<wgrant> They both seem really... rough.
<G> wgrant: the Desktop/Netbook/Server links at the top are perfect positioning for the first glance at the page (I don't know how, but it took me several clicks to find the server ISOs on the old site, I think because Download was the most prominent feature
<G> hmmm I do have a graphics glitch on the homepage, but I think I'm going to put it down to my ISP
<wgrant> I wouldn't.
<G> wgrant: I live in a rural area, rain gets into the overhead lines and makes my connection unreliable
<G> wgrant: for me, the bottom right hand part of the ? for 'Get support' is missing
<Pici> Thats how the image is
<wgrant> The bottom left is deliberately missing.
<wgrant> It took me a few minutes to work it out.
<wgrant> But it's actually the profile of a head.
<G> oh, the ? is the ears?
<Pici> Just like the top of the fishbowl on the community thing is missing.
<wgrant> I guess it could be.
<Pici> http://www.ubuntu.com/sites/default/files/active/03_global/02_pictograms/pictogram_support_medium.pnghttp://www.ubuntu.com/sites/default/files/active/03_global/02_pictograms/pictogram_support_medium.png
<G> oh and of course, the other isa fishbowl
<Pici> oops, double paste.
<sgallagh> Question: what's the process for getting Ubuntu to pull in a newer point release of a package?
<G> Pici: thanks for explaining it
<G> not sure if I'd go along with the community = fishbowl analogy or not, but okay :)
<zul> how do I handle source package renames do I have to do a MIR and all that fun stuff?
<pitti> zul: no, of course not; just tell today's archive admin
<zul> pitti: thanks
<cjwatson> sgallagh: for stable release updates, in the vast majority of cases, we ask that people instead backport only critical bug-fixes
<cjwatson> sgallagh: for the development release, it's quickest to get Debian to adopt it and then we'll pull it in semi-automatically; otherwise, file a bug
<sgallagh> cjwatson: The update in question is a critical bugfix-only release
<cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates
<sgallagh> cjwatson: The package in question (SSSD) actually appeared first in Ubuntu
<sgallagh> It was only recently built in Debian
<cjwatson> if it really is *absolutely nothing else*, we can consider it via the process above
<sgallagh> cjwatson: https://fedorahosted.org/sssd/wiki/Releases/Notes-1.0.6
<cjwatson> I don't want to get involved with putting the upload together, I'm just pointing you in the right direction
<sgallagh> (Apologies for all the questions, I'm a Fedora guy)
<cjwatson> that looks short enough that we could accept it in its entirety, I think
<cjwatson> an Ubuntu developer will have to prepare an upload for it
<cjwatson> it really ought to get into maverick first though
<sgallagh> cjwatson: Ok, so I should file a bug in Launchpad?
<cjwatson> for a stable update, there must be a bug filed in Ubuntu, yes
<cjwatson> that's how we deal with QA tracking
<sgallagh> cjwatson: Well, hopefully Maverick will be pulling in SSSD 1.2.0 (which is being built in Debian next week)
<sgallagh> This is just a fix for a very serious bug in our old stable tree
<sgallagh> It was already fixed in 1.1.x and 1.2.x
<sgallagh> But it only came to my attention today that Ubuntu was still on 1.0.x
<cjwatson> I'm just quoting a statement from the policy page above ...
<cjwatson> "It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch."
<cjwatson> so if 1.[12].x includes that fix, that's fine too
<sgallagh> Yes, it was a straight trivial merge from the 1.1.x branch
<sgallagh> Ok, I'll open a bug and see what we can do.
<sgallagh> Thanks for your help
<cjwatson> I guess you had a sponsor to get sssd into Ubuntu in the first place?  Best to get them interested
<cjwatson> mathiaz or tjaalton, by the looks of it
<sgallagh> Yes, both of them, I think.
<sgallagh> tjaalton: Toss me a ping when you're around, if possible. I'd like to talk to you about a bugfix update for SSSD 1.0.x
<ccheney> shtylman: ping
<shtylman> ccheney: pong
<ccheney> shtylman: i think it probably uses the XDG_CONFIG_DIRS env var, but not completely sure, about to grep sources to see
<shtylman> ccheney: k, if you do find where it sets that up for the file dialog, do let me know... I can fix that in the kde one as well... also, I have a patch that allows mailto links (and other links) to work now
<shtylman> per one of the other bugs
<jcastro> sgallagh: since you're here I work on pages for upstreams to help document things like our SRU process: https://wiki.ubuntu.com/Upstream
<jcastro> feedback always welcome!
<ccheney> shtylman: maybe only by ooo-build and/or just the gnome dialog, will let you know what i find
<shtylman> k
<ccheney> shtylman: great :)
<sgallagh> jcastro: Thanks, I'll take a look
<ccheney> shtylman: hmm i don't see how its working, at least its not doing anything obvious under fpicker
<shtylman> hm
<shtylman> ccheney: maybe the gnome dialog defaults to that directory by itself? it would seem strange that it does that... but it may be possible
<shtylman> ccheney: that bug seems pretty minor tho... the user can just select the right folder :)
<ccheney> shtylman: perhaps, i'm asking on go-oo, i don't think it would default to Documents without at least somehow prodding it to the right type of dir
<ccheney> shtylman: but there may some flag i don't know to search for that would do it
<shtylman> ccheney: k
<ccheney> shtylman: whatever is changed even the internal file dialog defaults there, and on official upstream so not something done by go-oo patches
<hrw> hi
 * ccheney will ask in upstream channel, maybe someone there knows
<shtylman> k
<shtylman> very strange
<apw> pitti, are you doing a general reset of trend lines or should i be doing that for kernel ??
<pitti> apw: some teams asked me to flush their work items last week
<pitti> apw: once you guys have your specs ready, I can do that for kernel as well
<ccheney> shtylman: it might be somewhere in framework code since it seems not to be in fpicker, my grep will take a while, will update you later
<shtylman> ccheney: kk.. no problem.. will be on the lookout for any update :)
<pitti> apw: or, if you want to keep the history, just change it in maverick.cfg
<jdub> howdy, foundations-m-toolchain is listed as accepted, but has no wiki page; while https://wiki.ubuntu.com/Specs/M/ARMToolChainSelection suggests gcc 4.5 except for g++
<jdub> seeing that both 4.4 and 4.5 have been uploaded, anyone know the outcome?
<hrw> doko: ping
<jdub> (long time no see, btw, old chums!)
<ccheney> actually looks like slangasek is in charge of that spec
<ccheney> slangasek: ^
<apw> pitti, yeah i don't see any value in dropping the history or anything, its just the trend line, so i can sort that
<doko> hrw: ?
<doko> jdub: 4.4 default, 4.5 optional (in main)
<hrw> doko: I wanted to discuss about https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/585439 (debhelper7 for gcc-4.4)
<ubottu> Ubuntu bug 585439 in gcc-4.4 (Ubuntu) "migrate to debhelper7" [Undecided,Incomplete]
<jdub> doko: so no elements of 4.5 in the default toolchain at all (libstdc++ etc)?
<hrw> doko: if you have few minutes
<doko> jdub: except for the runtime libs
<jdub> ah okay
<jdub> thanks :-)
<doko> hrw: what do you need to know?
<apw> pitti, like this ??
<apw> trend_start = {
<apw>         'canonical-kernel-team': 168,
<apw> }
<pitti> apw: for that, and presumably also for ('canonical-kernel-team', 'maverick-alpha-2')?
<hrw> doko: does migration to dh7 (done in better way) will be accepted?
<apw> pitti, ahh ok ta
<hrw> doko: I need to check yet how to better use dh_install (no --autodest) and then how to show not packaged files.
<doko> hrw: what is the advantage compared to v5?
<doko> hrw: the best fix would be to de-deprecate dh_movefiles, or add an option --move to dh_install
<apw> pitti, i assume the cron runs at '0' so i guess i just missed it
<pitti> apw: at :5
<doko> dapper still has v5,
<pitti> so you're lucky :)
<ccheney> shtylman: ok its set by an option in OOo which probably pulls it from xdg somehow but that isn't needed to be search for anymore, just have to determine how to query the internal var now
<apw> heh i am indeed
<tjaalton> sgallagh: ok, I can prepare it. thanks for the heads-up
<hrw> doko: we (arm team) want to do some changes and thought that moving to dh7 would be good addition (thats my idea, others can not agree)
 * apw hopes he hasn't blown the whole thing up and pitti won't have to come round and beat him
<pitti> apw: you know, I don't actually have to look at the WI charts this cycle ;)
<shtylman> ccheney: yea.. I see the comment in go-oo, I guess someplace in shell
<apw> pitti, lucky man
<doko> hrw: "do some changes" should be specified ... and no, I don't think v7 is a good idea on its own
<hrw> doko: you are using debian/tmp/ now to check which files did not got packaged? what about comparing list of installed files (from debian/tmp) with list of packaged ones?
<doko> hrw: how did you test your patch?
<sgallagh> tjaalton: Great! Thank you very much.
<hrw> doko: sure, agree. so far they exists as list of work items in https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers
<hrw> doko: built normally for host (amd64) and for cross (amd64 -> arm), then applied my patch and built again same targets. then debdiffed resulting packages
<tjaalton> sgallagh: looks like maverick still has 1.0.5, so I'll upload it there first, not merging the debian changes to keep the diff minimal, then that version can be uploaded to lucid-proposed
<jdub> doko: warty was built for i486, right?
<jdub> doko: or just particular optimisations?
<sgallagh> tjaalton: Ok, cool. Let me know if there's anything you need from me.
<hrw> doko: if I can test it in better way then I am all ears
<doko> jdub: gcc-4.1 (4.1ds7-0exp7) experimental; urgency=low
<doko>   * Set default 32bit ix86 architecture to i486.
<doko>  -- Matthias Klose <doko@debian.org>  Fri, 27 Jan 2006 22:23:22 +0100
<jdub> doko: oh, so dapper! gosh.
<doko> jdub: not sure, didn't check which gcc version was in use for warty and hoary
<cjwatson> dh_movefiles was deprecated because the operation of moving rather than copying can't meet policy's idempotency requirements
<doko> hrw: please do without --autodest, I think /lib and /usr/lib might get wrong
<hrw> doko: I am now building gcc-4.4 to get base for work this out
<cjwatson> so dh_install --move would just reintroduce that problem
<doko> cjwatson: deprecated for that reason? I remember that globbing issues were the reason
<cjwatson> multiple reasons - see debhelper 4.0.0 changelog
<doko> #315518 is still open =)
<cjwatson> anyway, dh_movefiles is still there, you can still use it with debhelper 7
<axonnn> oh hi guys
<axonnn> I want to develop something similar to Wubi. What are the main topics should I study?
<axonnn> are u sleepin?
<azeem> no, but your question is probably too vague
<axonnn> azeem: actually I'm looking for some keywords
<axonnn> such as loopmount, lupin etc.
<hrw> axonnn: "windows grubdos linux wubi" are not enough?
<axonnn> hrw: oh I will develop a new wubi for a distro. so I should learn main concepts in this stuff
<hrw> axonnn: I would first check how wubi and debian win32 installers work and how they are done
<hrw> but I did not had to use wubi
<axonnn> hrw: yeah I'm wondering exactly that. should I checkout the code? not sure..
<azeem> checking out the code is rarely wrong
<axonnn> azeem: hmm okay so I would do that.
<axonnn> wubi is such a good software. however some people say that it is significantly slow. is that true?
<azeem> shouldn't you evaluate things like that yourself if you want to develop something like it?
<tjaalton> sgallagh: looks like the package didn't include sssd.api.conf. how big of an issue is that?
<tjaalton> sgallagh: wondering if I should fix that as well..
<axonnn> azeem: actually not evaluating just asking that ntfs is really slow or not.
<sgallagh> Ah, shoot
<sgallagh> tjaalton: Trying to remember. You just didn't package it, or I added it in this patch?
<tjaalton> sgallagh: the tarball has it, but the package didn't because of a typo in the packaging scripts ;)
<axonnn> kewl.
<sgallagh> oh ok
<sgallagh> tjaalton: Well, without it, the SSSDConfig API won't work, but I don't think you have any consumers of that API in Ubuntu yet (in Fedora we have authconfig)
<tjaalton> sgallagh: alright, then I'll keep it out, we'll get that from debian when we merge/sync 1.2.0
<ogra> kirkland, hrm, seen bug 532733 recently ? i wonder against which upstream we're supposed to file it if not qemu
<ubottu> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) "apt/dpkg in qemu-system-arm hangs if a big task is installed" [High,Incomplete] https://launchpad.net/bugs/532733
<hrw> cjwatson: with dh_movefiles checking which files did not got packaged is easy - "find debian/tmp" basically. which way you would do such check with dh_install being used?
<sgallagh> tjaalton: At some point, you probably want to add an install-script based on the SSSDConfig API to set up network configuration.
<tjaalton> sgallagh: yes, sounds nifty
<arand> Keybuk: Are you planning to do the merge of the new e2fsprogs, or do you mind if I tried poking it a bit? (I was told you were in charge of that package?)
<Keybuk> arand: there shouldn't be a need to merge
<Keybuk> our e2fsprogs package is from the same git tree as Ted's
<Keybuk> it should be up to date
<Keybuk> there's just a new version to pull
<Keybuk> I'll do that at some point - it's just "git pull ted" "dpkg-buildpackage"
<ogra> that would build a ted package, no ?
<ogra> :)
<arand> Keybuk: Ah, ok, I got on the track since I was thinking that https://bugs.edge.launchpad.net/ubuntu/+source/e2fsprogs/+bug/582035 might need an SRU with a fix that is in the new release.
<ubottu> Ubuntu bug 582035 in e2fsprogs (Ubuntu) "User cancel of fsck gives: "fsck.ext4: Inode bitmap not loaded while setting block group checksum"" [Undecided,Confirmed]
<Keybuk> arand: SRU doesn't really need to be done within git, so you can backport that one patch to lucid and upload
<jjardon> Hello, I'd like to update the info from: https://launchpad.net/gtk
<Keybuk> I've tried to keep the Ubuntu package in git for easier collaboration with Ted
<tjaalton> sgallagh: uploaded to maverick, next up lucid-proposed. the process will handle it from there :)
<jjardon> How can I do that?
<sgallagh> tjaalton: Thanks again for your help.
<arand> Keybuk: Yea, ok, I wasn't sure on the procedures really, but I'll make the -proposed debdiff ready for lucid and just wait until the new version gets into maverick then?
<seb128> jjardon, you can try asking on #launchpad
<seb128> jjardon, what do you want to change?
<jjardon> set the branch of developemt, the stble branch, obsolete ...
<jjardon> Also, Is anyone working in GTK+3 packages
<jjardon> ?
<jjardon> seb128, see https://launchpad.net/glade-3 as an example
<seb128> jjardon, not that I know
<Keybuk> arand: why do you need to wait for the new version?
<tjaalton> sgallagh: np, thanks for the notice
<ogra> Keybuk, SRU policy
<ogra> needs to be in $dev_release before the SRU is accepted
<pitti> Keybuk, ogra: haven't followed scrollback, but NB that if lucid version == maverick version, we can just copy lucid-proposed to maverick, so no extra upload necessary
<pitti> that's standard practice right after a new release
<jdub> http://ubuntuedge.wordpress.com/2010/05/27/previously-on-maverick/ <- thoughts? (blog about devel branch activity)
<tjaalton> sgallagh: who reported the issue? filed a bug here, so they should confirm it's fixed once the package is available https://bugs.launchpad.net/ubuntu/lucid/+source/sssd/+bug/585885
<ubottu> Ubuntu bug 585885 in sssd (Ubuntu Lucid) "a serious bug in enumerate=false mode" [High,New]
<sgallagh> tjaalton: It was filed a long while ago upstream, and was fixed in 1.1.0
<sgallagh> tjaalton: But I only today realized that Ubuntu had never upgraded to 1.1.x
<sgallagh> So I backported it to a version you'd be able to continue with
<tjaalton> sgallagh: ah ok
<tjaalton> wonder who's going to confirm the bug, but since it came from upstream I think it's good :)
<sgallagh> tjaalton: Well, I'll have the guy who came to me about it verify it for you
<mdeslaur> pitti: I have an occasional problem with evolution where all of a sudden it's calendar timezone gets screwed up. I have traced the problem to /usr/share/zoneinfo/UTC getting replaced with my current timezone file when I do a dist-upgrade. Any idea what package would be messing with the UTC file?
<tjaalton> sgallagh: ok, thanks
<mdeslaur> pitti: I have a list of packages in LP: #254980 if you want to take a look
<pitti> mdeslaur: tzdata for sure
<mdeslaur> pitti: yes, but that's not the one that is _breaking_ the UTC file. There's another package that is breaking it.
<pitti> mdeslaur: hm, check dpkg -S /usr/share/zoneinfo/UTC and grep zoneinfo /var/lib/dpkg/info/* ? (the latter will look for broken postinst scripts)
<pitti> mdeslaur: but maybe it just picks up the file in an intermediate bad state during unpack?
<mdeslaur> pitti: I tried those two already...tzdata still owns it, and nothing looks broken in the postinst scripts
<mdeslaur> pitti: it's a weird problem...and I've had it sporadically for the last couple of years...jdstrand also
<mdeslaur> hmm...I wonder if it has something to do with schroot
<mdeslaur> nah
<cjwatson> hrw: dh_install has two options just for that - --list-missing and --fail-missing
<hrw> cjwatson: but does it work if I do lot of dh_install calls?
<cjwatson> why would you do that?
<cjwatson> you shouldn't need to if you're using debian/<package>.install properly
<hrw> cjwatson: gcc-4.4 rules has 103 calls to dh_movefiles (which I so far changed to dh_install)
<cjwatson> hrw: it shouldn't be expected to be a one-to-one translation
<zeroluck> anyone have experience installing kernel modules/patches for rocketraid card drivers?
<hrw> I know and I am working on it
<cjwatson> anyway, I don't see why arm should need to do this :)
<hrw> ;)
<dholbach> Laney, stefanlsd: mind if I subscribe you to community-m-packaging-docs?
<dholbach> you have action items on there
<ricotz> seb128, hello, are there already some packaging attempt for gtk+3.0 yet?
<seb128> ricotz, hi, no
<dholbach> Laney, stefanlsd: done, jbicha too
<seb128> ricotz, we have lot of others things to work on, but contributions are welcome
<ricotz> seb128, i was hoping you already have a ppa, i wanted to look into it since gnome-shell will propably depend on it soon
<seb128> urg, good luck with that
<jcastro> hi ricotz, I sent you a mail about -shell dailies a day or so ago
<ricotz> jcastro, hi, you did? let me check
<ricotz> jcastro, i got no mail
<ricotz> seb128, thanks :(
<seb128> ricotz, don't package gtk3 in a ppa in any case
<seb128> if you work on it please work with us to get it done in Ubuntu
<ricotz> seb128, isnt it best way to use a ppa, and let someone of you check it?
<seb128> ricotz, no offense to your work but you don't want to ship non official gtk builds to user
<seb128> ricotz, it could create quite some issues
<seb128> those need to be done properly and reviewed
<ricotz> seb128, i havent planed to publish it widely
<seb128> if it's in a ppa with gnome-shell users will get it
<seb128> and it might break upgrades to the official version
<seb128> work with us to get it properly done in debian and ubuntu
<ricotz> i wouldnt put it in there!
<seb128> ok, good
<ricotz> gtk3 should also be able to install besides gtk2
<ricotz> seb128, i have done some testing with gtk-sharp3 some time ago which should be a similar transition like gtk+
<seb128> ricotz, right, it just need to have rebuild of all theme engines, etc for it
<seb128> + bindings
<seb128> + input methods
<seb128> + etc
<ricotz> yes, thats why i asked cause this package is a bigger deal
<mvo> Riddell: we are about to move language-selector to dbus/policykit. I suppose this will be fine with kubuntu? it has a policykit1 auth dialog I assume?
<mvo> (just double checking to not accidently break stuff)
<Riddell> mvo: yes we have polkit-1 support in kde
<Riddell> but might be worth testing it
<Riddell> JontheEchidna: incase you're interested ^^
<mvo> Riddell: cool, thakns
<apw> pitti, is there any reason that having the default start for the trend line as the highest bar in the range would ever be unreasonable
<pitti> apw: rickspencer3 didn't like that, since it would hide the fact if new WIs are added to your workload after the original plans, and thus are responsible for slipping deadlines or not delivering other projects
<apw> pitti, i was more thinking as a default ... and as long as you don't delete the history the jump in bar height at day N tells you someone added work doesn't it?
<apw> that has nothing todo with the meaning of the trend line for my mind
<pitti> apw: TTYL, just finished a phone call and off for dinner; back in 30
<apw> sure
<seb128> jdong, hey, do you think you could do some sru reviewing work? there is quite some updates waiting, cjwatson has been reviewing a good bunch of those bugs would be nice to have somebody else helping him I guess
<seb128> or slangasek or other sru team members
<jdong> seb128: ah I'm so sorry about that. For the past two weeks I've been swamped with house repair work. When I get back tonight I'll spend an hour going through the queue
<jdong> thanks cjwatson for filling in
<seb128> jdong, nothing to be sorry about, thanks for having a look to those ;-)
<pitti> I'll spend some 20 mins on it now
<seb128> pitti, thanks!
<jdub> seb128: are you guys aiming for GTK+ 3 in maverick?
<seb128> jdub, no
<seb128> jdub, well depends what you call aim, I aim at having it available
<seb128> I'm leaning toward trying to keep it out of the default installation
<seb128> it's going to be a non trivial transition
<jdub> seb128: ah, so mostly focusing on having stuff built against 2.22?
<seb128> and having 2 gtk versions on the CD would be challenging
<seb128> right, mostly stabilizing what we have now
<seb128> getting platform uptodate
<seb128> then trying to get GNOME3 things as they seem reasonable ready
<seb128> but we are not going to run into gsettings on gtk3 port for the desktop components
<jdub> ok, cool -- thanks :-)
<pitti> seb128: I'm done with some -updates migration, but there's some half-finished langpack upload in the -proposed queue (asked ArneGoetje for details) which breaks the review script
<pitti> but it's time for Taekwondo anyway
<pitti> bye everyone!
<seb128> pitti, ok thanks, have fun, see you tomorrow!
<debfx> Daviey, superm1: hi, mythtv and mythplugins need to build-depend on libqt4-webkit-dev as QtWebKit is no longer part of libqt4-dev
<brassman> i need some help
<brassman> i installed ubuntu with Wubi
<brassman> 3 days latter my hard drives doesnt boot
<brassman> any suggestions
<azeem> brassman: please ask in #ubuntu
<superm1> debfx, can you please file a bug with tasks for both?
<superm1> (and i'm assuming that change was made for maverick - earlier versions can still b-d on just libqt4-dev)
<ScottK> superm1: Yes.  It's just maverick.
<debfx> superm1: done
<superm1> thanks
<zul> is there an archive admin around? mysql-dfsg-5.1 got renamed to mysql-5.1 in debian I just uploaded the newest version from debian and need to replace mysql-dfsg-5.1 with mysql-5.1
<blue_anna> hey, is this a bug in ruby or could it be in my base libraries? http://pastebin.ws/1tuwkd
<blue_anna> ruby's documentation says taht it uses the native architectureâs double-precision floating point representation.
<kitallis> ok
<kitallis> why doesn't Set up Broadcast Account open up on my lucid install
<blue_anna> kitallis: did you mean to go to #ubuntu ?
<kitallis> ubuntu has too much noise.
<kitallis> but, okay.
<blue_anna> kitallis: whichever you want it's a free world (well sorta) -  I think generally if you have questions here it is supposed to be about libraries, not end-user stuff
<kitallis> well, this is a sort of an unfixed _bug_
<kitallis> https://bugs.edge.launchpad.net/gwibber/+bug/523964
<ubottu> Ubuntu bug 523964 in gwibber (Ubuntu) "gwibber crashed with AttributeError in __init__() (dup-of: 522538)" [Medium,Confirmed]
<ubottu> Ubuntu bug 522538 in desktopcouch "gwibber-service crashed with error in connect()" [High,In progress]
<blue_anna> ooh, yeah that's maybe perfect question for here
<Chipzz> blue_anna: no, this channel is about the development of ubuntu (and some derivates) as a whole, and the development of some core technologies
<blue_anna> so it's strictly about development of the next packages, no debugging of current ones?
<blue_anna> I mean -- I'm asking .. I volunteered because it was pretty quiet for a minute, is all :)
<blue_anna> kitallis: it launches for me, although I do see dbus errors in STDOUT when it does
<Chipzz> blue_anna: debugging of the current ones too, of course
<Chipzz> if by current you mean the packages in the current development release
<Chipzz> blue_anna: just mentioning what I have noticed appears to be the general trend here
<Chipzz> my word is by no means final :)
<blue_anna> Chipzz: thank you :)
<Chipzz> but saying that #ubuntu-devel is purely about libraries would be wildly inaccurate :)
<kitallis> well
<Chipzz> there are some other things that tend to get discussed here
<kitallis> i'm getting those errors + couchdb returning a 500 error
<blue_anna> python error messages always are illegible to me :S
<kitallis> i've been updating as soon as things come, looks like it hasn't been fixed yet
<blue_anna> -- /usr/lib/python2.6/httplib.py line 330 -- you failed to get a socket for some reason, not sure why
<Chipzz> blue_anna: although it may have changed recently, another rough guideline is that packages in main/restricted get discussed here, packages in universe/mulitverse get discussed in #ubuntu-motu
<Chipzz> but this may not be entirely accurate due to the reorganization of the pockets, iirc
<kitallis> bah
<blue_anna> kitallis: can you do python -d /usr/bin/gwibber and pastie the results?
<kitallis> blue_anna: http://pastie.org/private/bzlwxgrvth1mx6r2mzdkqg
<blue_anna> that looks different
<blue_anna> attach taht to your bug --
<blue_anna> "Connection refused" is what's causing your problem, and the code doesn't escape out of the connection attempt gracefully
<blue_anna> well, I dunno know but, looks like it is your problem
<blue_anna> kitallis: how did you file a bug?
<blue_anna> I'm pretty sure I have one
<kitallis> i did not
<blue_anna> that's not your bug report you linked earlier?
<kitallis> nope,
<blue_anna> oo
<kitallis> -,
<blue_anna> kitallis: watch the thread it is marked as duplicate of instead of the one you linked me
<blue_anna> hey, is this a bug in ruby or could it be in my base libraries? http://pastebin.ws/1tuwkd
<debfx> seb128: the directfb so bump cause some packages to be uninstallable
<debfx> especially libsdl which many packages build-depend on
<debfx> I think that should be rebuilt: bug #585992
<ubottu> Launchpad bug 585992 in libsdl1.2 (Ubuntu) "Rebuild for directfb transition" [Undecided,New] https://launchpad.net/bugs/585992
<seb128> debfx, yes, that's true often true on soname changes
<seb128> -true
<seb128> debfx, somebody will fix it soon enough I guess
<seb128> debfx, uninstallability happen especially early in unstable cycles
<debfx> seb128: sure, it's just annoying when trying to build a package that has uninstallable build-deps
<seb128> debfx, ...
<seb128> debfx, not sure what you are looking for, I can't transition the whole archive by myself you are welcome to contribute if you have issues
 * ajmitch TIL on libsdl, should probably upload a rebuild sometime
<debfx> all I'm saying is that it would be nice to fix some of the packages that have many reverse build-deps
<seb128> debfx, right, not discussing this, patches are welcome
<blue_anna> I think the problem with firefox might be related to the floating point base libraries not being up to date on xorg
<blue_anna> ** problem with firefox on xorg
<micahg> YokoZar: my sound issue isn't with wine, it's with the audio subsystem :(
<blue_anna> how do I upgrade my system to the development version?
<blue_anna> there's no /testing page now
#ubuntu-devel 2010-05-27
<jdub> cjohnston: 'oom never' no longer needed in maverick's /etc/init/ssh.conf ?
<jdub> cjwatson: 'oom never' no longer needed in maverick's /etc/init/ssh.conf ?
<jdub> sorry cjohnston :-)
<lifeless> jdub: zomg, you still know how to irc:)
<Lrrr> anyone here got LXC to work with libvirt properly?
<Redache> '8
<jono> hey all
<jono> I am thinking of upgrading to Maverick, how stable is it right now?
<ion> I still have to run the Lucid kernel for fglrx and vuze stopped working since a Gtk change (apparently related to RGBA), but i havenât had problems other than that. :-Pppppp
<jono> cool
<ion> :-P even. (The keyboard battery is dying.)
<jono> thanks!
<ion> Basically, iâm imposing problems on myself by running proprietary crap and Java crap. ;-)
 * ajmitch hasn't had anything die horribly in a VM since upgrading this morning, fwiw
<RAOF> jono: Maverick's tracking pretty nicely here.
<jono> awesome, thanks RAOF
<jono> kicking off the upgrade now :)
<psusi> I can't wait for the new lvm2 to get packaged and hit maverick... support for snapshot merging, so you can make a snapshot, update, and if things break, revert by merging the snapshot back into the origin
<ion> psusi: I take it user data that must not be reverted along has to reside on a separate partition?
<ion> I guess it would be the filesystemâs job to provide partial snapshots and reverting.
<ion> btrfs? :-)
<psusi> ion, yes, obviously a revert is for everything on the fs, but should not be a problem if you are just testing an upgrade to make sure it still boots and a few cursory checks of applications that still work before you decide to delete the snapshot or revert to it
<freeaks> hi there,
<freeaks> i'm trying to follow this tutorial:
<freeaks> http://www.wedevblog.com/gnome-panel-applet-part-1.html
<freeaks> to learn making a gnome panel applet
<freeaks> i have install build-essential package as well was libpanel-applet2-dev
<freeaks> but when i try to compile i get this error:
<freeaks> error: panel-applet.h: No such file or directory
<freeaks> error: gtk/gtklabel.h: No such file or directory
<freeaks> ..
<freeaks> ?
<freeaks> it seems as if my gnome source, headers aren't found ?
<freeaks>  i can see /usr/include/panel-2.0/panel-applet.h
<freeaks> the file is here
<freeaks> but somehow i can't seem to be able to compile
<freeaks> what could i do ?
<freeaks> i'm using this: g++ $(pkg-config âcflags âlibs libpanelapplet-2.0) -o helloworld example-applet.c
<ScottK> freeaks: This is development of Ubuntu here, not on Ubuntu.  IIRC there is #ubuntu-app-devel or something similar.
<freeaks> ScottK, ok, thanks
<pitti> Good morning
<dholbach> good morning
<tseliot> cjwatson: can you approve nvidia in lucid-proposed now that it was been tested in maverick, please? (LP: #580763)
<tseliot> s/was/has/
<cjwatson> tseliot: done
<seb128> cjwatson, hi, I know you are busy but do you think you could review the gnome-keyring rhythmbox brasero srus today?
<seb128> they should be pretty easy to review
<seb128> the brasero update fixes audio cd recording not working
<cjwatson> seb128: didn't I already review rhythmbox?  it isn't in the queue
<cjwatson> seb128: I'll look at the others now
<seb128> cjwatson, you didn't comment on bug #569380 if you accepted rhythmbox
<ubottu> Launchpad bug 569380 in rhythmbox (Ubuntu Lucid) "Rhythmbox crashes, when connecting a mtp device " [Low,Fix committed] https://launchpad.net/bugs/569380
<seb128> cjwatson, thanks
<tseliot> cjwatson: thanks a lot
<cjwatson> seb128: odd.  running sru-accept on it now
<seb128> cjwatson, thanks
<cjwatson> seb128: the CLEANFILES target in gnome-keyring/daemon/Makefile.in looks wrong
<cjwatson> seb128: shouldn't it be org.freedesktop.secrets.service rather than org.freedesktop.service?
<cjwatson> seb128: (not critical for SRU, it'll just mean the package doesn't clean correctly)
<cjwatson> looks like it was a bug in the patch submitted upstream
<seb128> cjwatson, oh, right, I will follow up upstream about it
<cjwatson> thanks
<seb128> cjwatson, thank you for spotting it
<cjwatson> I find GNOME package versions very hard to tell apart visually, somehow :-)
<cjwatson> it usually takes me a couple of goes to spot the difference between 2.30.0-0ubuntu1 and 2.30.1-0ubuntu1
<mpt> ev, http://pastebin.ubuntu.com/440300/
<mpt> Oh bother, that's not quite right
<mpt> Delete "With a USB key or SD card," -- that's left over from when I was thinking you could write to CDs
<mpt> And when that bit is deleted, the repetition of "also" grates a little more, but you get the idea
<cjwatson> seb128: ok, done now
<seb128> cjwatson, thanks!
 * hyperair wonders why he keeps getting ssl errors for *.debian.org addresses
<hrw> cjwatson: is it possible to use variables in *.install files?
<pitti> hrw: see man dh_install; it's not
<pitti> hrw: if you want to do something dynamic, you need to install files in debian/rules
<hrw> thx
<cjwatson> hrw: remember that it's perfectly possible to generate the .install file before running dh_install
<cjwatson> hrw: see the groff source package for an example
<hrw> cjwatson: I see
<ogra> Keybuk, http://paste.ubuntu.com/440283/ amitk tries to boot nfsroot without initramfs, do you have any idea why all tmpfs mounts seem to fail here ?
<ogra> parse_filesystems seems to find tmpfs properly
<ogra> (and according to amit devtmpfs support is compiled in but it desnt seem to be found by parse_filesystems)
<amitk> ogra: Keybuk: bug 586275 filed against mountall until I know more
<ubottu> Launchpad bug 586275 in mountall (Ubuntu) "mountall: can't mount /dev and some other filesystems using nfsroot" [Undecided,New] https://launchpad.net/bugs/586275
<amitk> it has kernel config and the boot logs
<ogra> amitk, err
<ogra> # CONFIG_TMPFS is not set
<ogra> why the heck does it show up in /proc/filesystems though
<amitk> hmm
 * ogra doesnt get that, do you have /proc from the server mounted in the root ? 
<ogra> though that would probably also find devtmpfs
<amitk> ogra: \o/ you rock
<ogra> heh
<hrw> ;d
<dmart> asac, ogra: hi, do you know a good person to ask about X input device issues?
<ogra> dmart, tseliot
<ogra> he's our Xinput god :)
<tseliot> what's up?
<tseliot> heh
<dmart> hi there
<tseliot> hi
<dmart> I have a weird ARM platform configuration with a rather old kernel
<dmart> most stuff works, but there are some udev problems, and X does not detect input devices properly
<dmart> Could you take a look at a log?
<tseliot> sure but can you also tell me what kind of input devices you're talking about? Mice?
<dmart> keyboard and mouse in this case, over USB
<tseliot> ok, don't they work at all?
<dmart> They don't appear to.  I do have /dev/input/{mice,input*}, and catting them produces data when I type / wiggle
<tseliot> ok, I'll need a dmesg and a /var/log/Xorg.0.log
<tseliot> ah
<hrw> dmart: use evtest for testing input devices rather then cat
<dmart> hrw: cool, I will try that
<dmart> (cat is a bit primitive ;)
<hrw> ;)
<hrw> evtest is kind of xev for terminal
<dmart> hrw: ah, right
<dmart> tseliot: http://pastebin.ubuntu.com/440337/
<dmart> This the contents of /dev and the Xorg log
<dmart> Unfortunately I don't have the platform running right now, but I can get dmesg output later if you need.
<tseliot> ok
<dmart> What's weird is that X detects stuff, be then doesn't use the evdev driver:
<dmart> config/udev: Adding input device USB keyboard (/dev/event1)
<dmart> (II) No input driver/identifier specified (ignoring)
<dmart> But the driver is definitely in the fs ...
 * ogra wonders if your kernel has CONFIG_INPUT_EVDEV set
<dmart> ogra: I thought of that, but it's definitely supported
<tseliot> can you also try to get a backtrace, please?
<dmart> You don't get /dev/input/event* otherwise
<ogra> also it seems strage that xorg picks /dev/event1 instead of /dev/input/event1
<tseliot> good point
<dmart> tseliot: I can try--- note that server reset or shutdown always segfaults on ARM right now.  I don't think we're seeing any other crash here--- X runs until it is shut down
<tseliot> dmart: ah, ok
<dmart> ogra: good spot... I move the input devices into /dev/input because udev is confused by the old kernel and puts them straight in /dev, maybe I shouldn't
<ogra> not sure
<tseliot> what kernel is that?
<dmart> I still get similar X input problems even if the device nodes aren't moved... but I could try and get a log
<dmart> 2.6.29 unfortunately... and hard to upgrade in this case
<ogra> how about usbfs and friends ?
<ogra> iirc we stopped supporting the old style usbfs a while ago
<dmart> dunno... do you mean something that ought to be mounted is not?
<ogra> no, a missing kernel option rather
<dmart> Note that I have lucid Xorg working even on 2.6.26
<ogra> iirc i had probs when some deprecated USB options were set in a test kernel i built recently
 * ogra cant remmeber which though and the kernel is fixed now
<dmart> hmmm... might be worth a check
<dmart> tseliot, ogra: well, I think I have some next things to try now... I'll come back when I know more
<ogra> and iirc udev has issues with CONFIG_SYSFS_DEPRECATED_V2
<ogra> not sure that affects the input layer though
<dmart> ogra: oh yes :)  But Xorg still works!  (I'm as surprised by this as anyone...)
<tseliot> dmart: if udev catches the device and applies the settings for the mouse you should get something like:
<tseliot> (II) config/udev: Adding input device Razer Razer Salmosa (/dev/input/event4)
<tseliot> (**) Razer Razer Salmosa: Applying InputClass "evdev pointer catchall"
<dmart> tseliot: yup, I see this on other, more normal platforms
<tseliot> maybe dmesg will show something interesting
<dmart> I'll take a look
<dmart> thanks
<tseliot> np
<apachelogger> jdong: hey, it would be very nice if you could take a quick look at bug 583735 regarding sru :)
<ubottu> Launchpad bug 583735 in kdepimlibs (Ubuntu Maverick) "Akonadi self-test comes up if startup takes too long" [Undecided,In progress] https://launchpad.net/bugs/583735
<zul> StevenK: ping
<StevenK> zul: contentless pong
<zul> StevenK: sorry...debian renamed the source package for mysql-dfsg-5.1 with mysql-5.1 can we replace the mysql-dfsg-5.1 that is in main right now with mysql-5.1 which I uploaded yesterday?
<StevenK> pitti: ^
<StevenK> pitti: I just want an ok, I'm happy to fiddle it
<hrw> cjwatson: is there a script which will generate *.install from packages contents maybe? :D
<pitti> StevenK: sure, seems obvious
<zul> StevenK: thank
<lool> hrw: Hmm you dont actually want to do that
<lool> hrw: You want to use the current logic in rules, not the contents of the packages
<StevenK> zul: I should demote, or remove mysql-dfsg-5.1?
<zul> remove mysql-dfsg-5.1
<lool> hrw: BTW I had a call with doko to go over his input on the spec, I'll update the spec to clarify
<hrw> thx
<skeledrew>  hello. is there any detailed specifications on how Wubi and Lupin works/what EXACTLY they do? also, how can i go about getting the code in http://bazaar.launchpad.net/~ubuntu-installer/wubi/trunk/files and http://bazaar.launchpad.net/~ubuntu-installer/lupin/hardy/files ? my web spider isn't exactly cooperating.
<free> mvo: hi! I noticed that lucid is not yet listed in http://changelogs.ubuntu.com/meta-release-lts, I guess that's on purpose right?
<smoser> anyone seen something like this before: http://ubuntu-server-new-bugs.notlong.com
<smoser> i'm triaging server bugs, there are 8 or so (awstats and munin) SIGSEGV bugs in perl on karmic
<mvo> free: yeah, that is on purpose, the plan is to enable it by default for 10.04.1
<free> mvo: cool then
<mvo> thanks
<cjwatson> skeledrew: detailed spec> probably not to the exactitude you're looking for if you're trying to implement an equivalent for another OS (this is a guess but you're about the fourth person to ask that kind of thing, so ...).  Use bzr to check out the source.
<skeledrew> cjwatson: yes. i'd like to make it more generic to install other downline Ubuntu distros, such as peppermintos that don't have it.
<ogra> tedg, heya, i added a workitem for you on https://blueprints.launchpad.net/ubuntu/+spec/mobile-m-lightweight-panel-for-efl
<tedg> ogra, Cool, thanks!
<Drakeson> I am a bit confused with the version number of a package: libdbus-1-3 has version 1.2.16-2ubuntu4.  Does it mean it is dbus 1.3 or not?
<Keybuk> no
<Keybuk> it means it contains libdbus-1.0.so.3
<Drakeson> *sigh*, thanks
<Keybuk> library versioning is not orthogonal to package versioning
<Keybuk> libdbus-1.0.so.3 is the *current* library version of dbus, as shipped in, e.g. 1.2.16
<Drakeson> I see. thanks :)
<Drakeson> btw, is dbus 1.3 on the roadmap for maverick?
<Ian_Corne> am I right to say -number indicates the version in the distribution, not of the actuall thing, and .number is for the real version?
<Ian_Corne>   Candidate: 1.2.16-2ubuntu4
<cjwatson> upstreamversion-packagingrevision
<cjwatson> so that means "upstream version 1.2.16, Debian revision 2, Ubuntu revision 4"
<ogra> pitti, did the cronjob for the WI tracker stop working ?
<pitti> ogra: no, it crashed since someone broke maverick.cfg
<pitti> (and didn't commit it either)
<ogra> ouch
<pitti> I just fixed the syntax
<ogra> pitti, while you're at it, can you replace asac with me for mobile ?
<pitti> ogra: that's already done in maverick.cfg
<ogra> oh, then i seem to look at the wrong branch
 * ogra is looking at trunk
<pitti> ogra: right, as I said, someone edited it on lillypilly without committing
<ogra> ah
<pitti> JFo, asac: someone added https://wiki.ubuntu.com/UbuntuARMTeam/ReleaseStatus/MaverickTasks?action=raw to maverick.cfg; should't that rather get into ubuntu-arm.cfg?
<pitti> it looks weird to distribute the ubuntu-arm WIs like that, but your call of course
<JFo> good question pitti
<JFo> pitti, I am asking amitk about it now
<ogra> pitti, i think someone == JamieBennett
<ogra> amitk just summons him :)
<pitti> oh, did I pick the wrong Jamie? sorry
<amitk> pitti meet JamieBennett
<JamieBennett> amitk: pitti: heh
<JamieBennett> whats up
<blue_anna> in man 2 mkdir it says that it is made to conform to Posix.1-2001 -- but there is no Posix.1-2001 .. the last POSIX.1 standard was 1995
<blue_anna> what standard are they actually following?
<amitk> JamieBennett: 17:57 < pitti> JFo, asac: someone added https://wiki.ubuntu.com/UbuntuARMTeam/ReleaseStatus/MaverickTasks?action=raw to maverick.cfg; should't that rather get into ubuntu-arm.cfg?
<JamieBennett> amitk: I contemplated that but as all spec's moved into the ubuntu project I added to the maverick.cfg file
<JamieBennett> oh and pitti it seems it hasn't been run since 13:12 or so
<blue_anna> because mkdir is returning before the directory is actually made
<ogra> JamieBennett, yes, it crashed
<JamieBennett> there maybe a call to keep it as ubuntu-arm, I would like to see it that way but as the blueprints are now under ubuntu its a grey area
<pitti> JamieBennett: right, there was a syntax damage in maverick.cfg, just fixed
<pitti> JamieBennett: well, whichever way works better for you, it was just a question
<dholbach> mdeslaur will give a Packaging Training session about "Preparing Security Updates" in #ubuntu-classroom at 18:00 UTC
<JamieBennett> pitti: ideally under ubuntu-arm I think. As that wasn't being generated at the time I thought I would tag it into the maverick.cfg to see if it was getting generated there, both weren't for the reason you said. I'll remove it from the maverick.cfg file then and if you could take a look at ubuntu-arm.cfg to make sure I got it right that would be great.
<pitti> JamieBennett: sure, ping me once you moved it
<JamieBennett> pitti: done
<pitti> JamieBennett: looks fine
<JamieBennett> pitti: great, thanks
<pitti> let's wait how the next cycle will look like
<mdz> dholbach, what's the shortcut you use to do this: [[LaunchpadHome:dholbach]] <<DateTime(2010-05-27T16:27:29+0100)>>
<dholbach> mdz: @SIG@
<mdz> dholbach, thanks
<dholbach> anytime
<hrw> dpkg-deb: warning: 'debian/gcc-4.4-source/DEBIAN/control' contains user-defined field 'Original-Maintainer'
<hrw> I wonder why Ubuntu did not patched that out
<cjwatson> hrw: I've been trying desperately to reduce the number of patches we're carrying against dpkg, so I don't want to add patches for things that are essentially cosmetic
<hrw> just was curious
<hrw> doko, cjwatson: can you look at http://hrw.pastebin.com/4qb2McVD and tell is it good way?
<hrw> I have cpp-4.4.install and cpp-4.4.links files
<cjwatson> I'll leave that to doko
<cjwatson> er, well, I wouldn't use sed -i if I were you - have .install.in and .links.in files instead
<cjwatson> since otherwise it isn't going to work the second time
<hrw> cjwatson: ok, like in groff
<cjwatson> (and keeping backup files and restoring them is annoying and fragile)
<hrw> right
<JamieBennett> pitti: still no generation of the work items, how often does it get done?
<pitti> JamieBennett: 5 past the hour for ubuntu, 25 past the hour for arm
<pitti> ah, it crashed again
<pitti> KeyError: 'arm-ubuntu'
<doko> hrw: what do you want to achieve? in general, I think .install files are a bad idea for gcc. what do you want to fix/improve?
<pitti> JamieBennett: there is no https://launchpad.net/~arm-ubuntu, as stated in ubuntu-arm.cfg
<pitti> JamieBennett: the other three seem fine, so I just comment out arm-ubuntu for now
 * pitti re-runs
<hrw> doko: first wanted to get rid of dh_movefiles, now it is gaining debhelper packaging skills. I think that I will postpone it until there will be a time/realneed for it.
<doko> hrw: honestly, there are more pressing things than "gcc gaining debhelper packaging skills"
<hrw> sure
<hrw> doko: and I learnt more about debian way to build toolchain
<doko> ok
<jono> seb128, are you aware of an issue in Evo in Maverick with the cursor not visible when composing a mail?
<seb128> jono, no
<jono> ok, will look into filing a bug
<seb128> jono, but I'm not using maverick yet ;-) I didn't read bugs about it though
<jono> seb128, slacker
<jono> :P
<jono> I have never been able to say that about seb128 before
<Drakeson> while you're discussing evolution, is the icon for junk-email (or was it not-junk-email) added to the default icon-theme, yet? the toolbars tend to get huge otherwise.
<jono> seemed like a good opportunity
<jono> :)
<seb128> jono, lol, not you slacker, I need to get work done, you might have the leasure to spend your week fixing your computer, I don't ;-)
<jono> Drakeson, that is fixed upstream I believe
 * seb128 runs
<pitti> JamieBennett: went through, see http://people.canonical.com/~pitti/workitems/ubuntu-arm/ ; now with per-team reports \o/
<jono> seb128, haha
<jono> seb128, ok, I will file a bug :)
<seb128> thanks
<seb128> I will try in my mini
<ccheney> shtylman: i synced master and 3-2-1
<seb128> I run maverick there for now
<ccheney> shtylman: haven't done a build yet so it might have bugs
<seb128> I'm still trying to get some lucid sru dones before switching my laptop
<shtylman> ccheney: cool
<ccheney> shtylman: i got it ready before the rc3 ooo-build release tomorrow :)
<shtylman> rc3 of 3-2-1 ?
<ccheney> shtylman: yea
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<ccheney> grr is there a way to make gtg to make something not a subtask, i accidently converted something to one
<ogra> pitti, any idea why i still have two specs from the arm team on http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html ?
<tkamppeter> pitti, I have done a small change on the CUPS startup script for bug 369850. I let it also load the parport_pc module in addition to lp and ppdev. This is a nice minimum-invasive solution for a Lucid SRU.
<ubottu> Launchpad bug 369850 in linux (Ubuntu Maverick) "Cannot set up parallel port printer on Ubuntu 9.04 or 9.10" [High,Confirmed] https://launchpad.net/bugs/369850
<pitti> tkamppeter: that sounds wrong, though; parport-pc has proper modaliases
<tkamppeter> pitti, the SRU should also contain the fixes for bug 468701 (newline in device ID breaks CUPS) and bug #578181 (white rectangles yellow in printout).
<ubottu> Launchpad bug 468701 in cups (Ubuntu Maverick) "Cups on Ubuntu Karmic does not recognize USB printer " [Undecided,Fix committed] https://launchpad.net/bugs/468701
<pitti> it should be autoloaded
<ubottu> Launchpad bug 578181 in cups (Ubuntu Maverick) "Printing white rectangles from OpenOffice produces yellow rectangles on paper" [Undecided,Fix committed] https://launchpad.net/bugs/578181
<pitti> tkamppeter: aren't the other two already in -proposed?
<pitti> yes, they are
<tkamppeter> pitti, OK, then next SRU should contain the parport_pc load and also
<tkamppeter> pitti, something that assures that CUPS gets loaded on boot
<pitti> tkamppeter: we'd load that module on every platform, which would just be a waste for 99% of people out there, though
<tkamppeter> pitti, and in the CUPS init script we should add something which restarts Samba if Samba is already running as in Lucid we have the perfect race condition, Samba started by native Upstart and CUPS by System V scripts.
<tkamppeter> pitti, for Maverick we should move to an Upstart job for CUPS.
<pitti> agreed for maverick
<pitti> but it seems for lucid we should rather fix samba's upstart job instead of restarting it
<tkamppeter> pitti, what is your fix suggestion? Should the upstart job simply get a loop added which waits until the CUPS daemon is up and running (check with "lpstat -r")? Or should the Samba Upstart job start CUPS if it is not yet running and only after that start Samba?
<pitti> nonono
<pitti> samba should just wait on cups
<pitti> I suggest to discuss that with Keybuk, he asked to get consulted for upstart job fixes
<pitti> tkamppeter: cups' init script could emit a "cups-started" event which samba can wait for; it just needs to handle the case when cups is not started or installed at all
<tkamppeter> pitti, here the Samba upstart script would need to check somehow whether CUPS is installed and configured for being started on boot.
<pitti> right, that's the bit which should be discussed with Keybuk; I do not have enough experience with upstart scripts for a tricky thing like that, I'm afraid
<tkamppeter> pitti, but the biggest problem to be SRUed is that CUPS need to start reliably on boot for every user, bug 554172.
<ubottu> Launchpad bug 554172 in cups (Ubuntu) "cups not starting at boot" [Medium,Confirmed] https://launchpad.net/bugs/554172
<pitti> tkamppeter: do these people get anythign else started in /etc/rc2.d/? such as kerneloops, rsync, binfmt-support, postgresql, etc.?
<pitti> I don't quite believe that this is a cups specific problem
<pitti> ogra: because pwlars is in ~canonical-mobile, I presume?
<ogra> pitti, he isnt anymore since 11UTC
<ogra> i cleaned that up after he showed up
<ogra> s/he/his specs/
<ogra> so i would expect them to vanish again
<pitti> ogra: ah, the membership is updated daily only, midnight
<pitti> so should be good tomorrow
<ogra> pitti, ah, thanks ... sorry to waste your time then
<pitti> np :)
 * pitti -> dinner
<SpamapS> Question: I'm working on merging the 'moin' package, which has a delta because the debian verison is dependent on some stuff in universe but moin itself is in main... should we just keep maintaining this delta or try to MIR the packages? They were removed because the dependency was added really close to LTS release.
<tkamppeter> pitti, for me it also looks like an upstart problem, I have already tried to move the bug to upstart, but it got promptly moved back to cups, by slangasek.
<zul> SpamapS: MIR
<tkamppeter> pitti, in bug 524186, comment #2, a simple approach of native upstart support for CUPS is tested, but only run-level based, so only half-native upstart. This approach still leaves many users without CUPS as under upstart their runlevel stays "unknown".
<ubottu> Launchpad bug 524186 in cups (Ubuntu) "CUPS service stopped (dup-of: 554172)" [Undecided,New] https://launchpad.net/bugs/524186
<ubottu> Launchpad bug 554172 in cups (Ubuntu) "cups not starting at boot" [Medium,Confirmed] https://launchpad.net/bugs/554172
<tkamppeter> pitti, this would mean that for that users all legacy System V scripts would not start.
<pitti> right, what I suspected; there might be a problem with a broken lo device, or whatnot
<SpamapS> zul: I believe, sir, that I will owe you an entire case of Gambrinus 12Â° by the time we get to Prague
<zul> SpamapS: sooner preferably ;)
<tkamppeter> pitti, legacy System V support is started on the "filesystem" event (successfully concluded "mountall") AND on "lo" being up and running.
<tkamppeter> pitti, so it can also be a mountall problem.
<slangasek> tkamppeter: I reassigned it back to cups because there was zero evidence in that bug report that upstart was failing to run the init scripts, and the original submitter said the problem was fixed for him by reinstalling the cups packages - which has nothing to do with upstart
<tkamppeter> slangasek, pitti, later on other posters told that reinstall of CUPS only helped once and later boots failed and also other legacy System V scripts and not only CUPS did not start.
<tkamppeter> slangasek, the real fix would be to move all services to native upstart, but this is too invasive for a Lucid SRU. And in addition, legacy System V support needs to work reliably in upstart, to support third-party packages containing services. AFAIK the LSB requires System V init script support.
<tkamppeter> pitti ^^
<slangasek> tkamppeter: then that poster may have a different bug, probably a broken configuration; I don't think that's sufficient to treat the whole bug as an "upstart problem".
<slangasek> this needs debugged as a cups bug first instead of jumping to the conclusion that upstart is broken
<slangasek> because upstart *does* run the sysvinit scripts reliably, unless something else is broken on the system
<tkamppeter> slangasek, pitti, we have again an example of the big problem of all bug tracking systems: Users post into the same bug if they have the same symptoms but different bugs (happens very often on the printing side). One should have the possibility to move single comments and attachments from one bug to another (like one can do in web forum systems).
<slangasek> tkamppeter: "especially as users have the same problem with other services than CUPS" -- what users where?  I don't see any mention of problems with other init scripts
<slangasek> oh, https://bugs.launchpad.net/ubuntu/+source/cups/+bug/554172/comments/41 mentions vboxdrv, ok
<ubottu> Ubuntu bug 554172 in cups (Ubuntu) "cups not starting at boot" [Medium,Confirmed]
<slangasek> but again, no evidence that his bug is the same as the others
<tkamppeter> slangasek, pitti: You mentioned it already, comment #41.
<tkamppeter> slangasek, pitti, is there any debug logging facility in upstart, so that users can get a log showing what upstart is actually doing?
<slangasek> tkamppeter: boot with --verbose, post /var/log/boot.log: https://help.ubuntu.com/community/UpstartHowto
<tkamppeter> slangasek, pitti, comment #47 has a list attached with all services which do not get started on a boot where CUPS did not get started.
<slangasek> tkamppeter: attached as an OpenOffice document.  Perhaps you would like to convert that into a usable format?
<nemo> is there a libtalloc2-dbg somewhere?
<tkamppeter> slangasek, for me it opens on a double-click, OOo is part of the standard desktop installation ...
<slangasek> tkamppeter: I'm not going to visually inspect some ridiculous OpenOffice spreadsheet to extract the equivalent of a text diff
<slangasek> tkamppeter: if you want to convert that into text files for me, I'll be happy to review it
<slangasek> but it's probably better to get the poster to just send us the text output in the first place
<slangasek> instead of working from something that's been manually munged twice
<tkamppeter> slangasek, so I will ask him to post the information inline into the bug report, so that the reader does not need anything but his browser.
<nemo> getting help elsewhere finding 'em. thanks anyway
<slangasek> tkamppeter: no, not inline, text attachments.  I need something I can sensibly *diff*
<tkamppeter> slangasek, sorry, will do a second approach of instructions ...
<tkamppeter> slangasek, I asked him now to reboot repeatedly, to see how much relationships between CUPS not starting and other services not starting depend on each other.
<james_w> SpamapS: I think there is already an MIR in progress for that package. If I could remember the name then I would grab the bug number for you.
<tkamppeter> slangasek, to which command line do I have to add --verbose? to the kernel command line or to the initrd command line?
<james_w> SpamapS: found it, bug 566537
<ubottu> Launchpad bug 566537 in mod-wsgi (Ubuntu) "[MIR] mod-wsgi: libapache2-mod-wsgi" [Undecided,New] https://launchpad.net/bugs/566537
<tkamppeter> slangasek, I have found it, kernel command line.
<tkamppeter> slangasek, thanks for the instructions on how to get Upstart into verbose logging mode. I have added the instructions to the bug report.
<jono_> pitti, any chance you could re-gen http://people.canonical.com/~pitti/workitems/maverick/canonical-community.html so that the trend now starts at the top?
<slangasek> tkamppeter: sure thing - I'm sorry that we haven't done a better job up to now of publicizing the upstart troubleshooting information
<jdong> apachelogger: looking now
<apachelogger> jdong: super, thanks :)
<jdong> apachelogger: hehe interesting "fix" :)
<tkamppeter> slangasek, pitti, someone should create a page like https://wiki.ubuntu.com/DebuggingPrintingProblems for Upstart.
<jdong> apachelogger: ACKed, now just hope nobody tries starting KDE over NFS on dial-up ;-)
<apachelogger> lol
<SpamapS> james_w: right, sorry just saw your help finding that MIR.. yes..libapache2-mod-wsge was one of the 4 that need to happen for moin to drop most of its delta.
<SpamapS> james_w: which brings me to my next question..
<james_w> SpamapS: ah, sorry, I didn't realise there was more than one
<SpamapS> at some point python-xml was even dropped from universe for some reason.. but it is still in debian..
<SpamapS> anyway, python-xml is suggested by the debian package.. but removed from the ubuntu package .. which at this point will be the final bit of delta we have to maintain.. if we found it worthwhile to drop python-xml .. could we also push for debian to drop it? Really I'm trying to find the rationale for dropping/blocking python-xml
<james_w> SpamapS: it has been dead and deprecated for years, with people advised to use what is in the standard library now, or one of the other libraries if that doesn't cut it. For a "Suggests" there is no reason to diverge from Debian, as it has no real effect.
<SpamapS> ahh.. google has provided .. wow.. contentious
<SpamapS> https://bugs.launchpad.net/ubuntu/+source/python-xml/+bug/343242
<ubottu> Error: Could not parse data returned by Ubuntu: list.index(x): x not in list (https://launchpad.net/bugs/343242)
<james_w> yeah
<SpamapS> james_w: so a package in main is allowed to suggest a non-existant package?
<james_w> SpamapS: yes
<james_w> SpamapS: because it doesn't break anything. It's obviously not very elegant, but is used from time to time to suggest non-free packages and the like.
<james_w> plus there are cases like this where because there is no effect it's not worth diverging from Debian over it
<SpamapS> Well sweet
<SpamapS> I believe that means that once the 4 MIR's are approved and completed, we can just request that moin be synced. +1 for reduce (Al Gore would be proud)
<SpamapS> "â¦it looks like you were trying to look for `python-xml' binary package. The Package Tracking System is source based, therefore you should have looked for `python-xml'"
<SpamapS> brilliant
<lifeless> nice
<SpamapS> damn one more MIR, fckeditor
<SpamapS> great package name
<soren> SpamapS: What for? Moin?
<SpamapS> soren: yeah... its recommended in the debian package
<SpamapS> and actually
<SpamapS> wow it has a horrendous security record doesn't it?
<soren> SpamapS: Hm. We could just drop back to a Suggests.
<soren> Unless of course something changed in moin that makes that troublesome somehow.
<SpamapS> soren: indeed, I think its probably worth maintaining that as a change.
<SpamapS> soren: no fckeditor is disabled by default
<SpamapS> its fine
<SpamapS> yeah I think we'll maintain that delta.. fckeditor looks like just the sort of thing we want to keep out of main
<soren> SpamapS: I don't even see the changelog entry where it's bumped to Recommends.
<SpamapS> soren: we've bumped it from recommends to suggests in ubuntu.. but its still recommended in debian.
<leini> hi you
<soren> SpamapS: Oh, we've done that all along?
<leini> done what where?
<soren> SpamapS: I thought Debian had bumped it from Suggests to Recommends recently since you were looking at doing an MIR.
<SpamapS> soren: no I was looking at doing a MIR because its the only change left to avoid just syncing w/ debian
<soren> SpamapS: Oh, I see.
<SpamapS> soren: but really, I think its worth it.. and it should merge easily with just that one change in rules
<soren> SpamapS: Certainly.
<teurastaja> i have a permanent graphics address remapping table bug with possible asic involvement
<teurastaja> neither #ubuntu nor #ubuntu-bugs can help
<teurastaja>  the kernel tries to force the gart to 32M just after chainloading
<teurastaja> it freezes for a very long time and if i reboot no sidebar interaction with running programs is possible
<teurastaja> it says "[17.983732] [drm:rs400_gart_adjust_size] *ERROR* Forcing to 32M GART size (because of ASIC bug?)"
<teurastaja> can i fix this?
<teurastaja> if i try to minimize windows i lose them
<teurastaja> i have KDE
<andersk> Can I get someone to upload my bash-completion debdiff for bug 546794?  The current bash-completion spews bash syntax errors every time you start a shell (apparently nobody tested that patch at all?).
<ubottu> Launchpad bug 546794 in bash-completion (Ubuntu) "[revert, causes errors] Smarter lib* aware autocompletion?" [Undecided,New] https://launchpad.net/bugs/546794
#ubuntu-devel 2010-05-28
<psusi> cjwatson, you played much with lazy_itable_init yet?  I wrote a patch today to e2fsck that I think will address ted's concerns about enabling it by default
<SpamapS> is there a good wiki page on how to make sure your fixes get pushed back up to debian?
<psusi> email the debian maintainer?
<SpamapS> hah, it sounds so easy.. almost.. too easy
<RAOF> There's a submittodebian command in ubuntu-dev-tools; that sends a bug to the Debian BTS and sets a bunch of usertags.
<ScottK> SpamapS: As RAOF says.
<xnox> SpamapS, i do a debdiff or a patch against Debian packaging $vcs, file the bug in BTS and link it in the lp bug where the patch was introduced. That way the bug is still visible in bugs.launchpad.net/~me and i get updates =) i do set tags manually though
<dholbach> good morning
<NCommander> bdrung__: ping
<NCommander> bdrung__: can you look at https://bugs.edge.launchpad.net/ubuntu/+source/d-shlibs/+bug/579187 again? (I honestly don't understand why you had me respin the debdiff however)
<ubottu> Ubuntu bug 579187 in d-shlibs (Ubuntu) "Merge of d-shlibs from Debian sid" [Medium,Confirmed]
<\sh> moins
<NCommander> morning \sh
<seb128> NCommander, speaking of which bug, did you read my comment about it?
<seb128> NCommander, the debian maintainer disagree with the change
<seb128> NCommander, can you either follow up on the bts or drop the change?
<seb128> either the debian maintainer is right and we should drop the change
<seb128> or he's wrong and somebody should explain why on the bts
<NCommander> seb128: I didn't see your comment before. Let me look at the maintainers comment on the BTS
<seb128> NCommander, thanks
<NCommander> seb128: I didn't see the comment on the BTS before or I would have responded to it. Its indeed possible an issue with eglibc on ARM only, but this is how the .la files are generated on this platform, and the same bug effects Debian as well as Ubuntu. I don't know the subject well enough to say if this is an actual bug in eglibc or not, nor am I strongly happy about the notion of changing glibc at all at risk of greater breakage
<seb128> NCommander, could you at least open a bug against debian glibc pointing to this bts comment?
<seb128> NCommander, so both debian maintainer can argue over the issue and decide where to fix it
<ogra> NCommander, erm
<NCommander> ogra: ?
<ogra> looking at the diff, wasnt that a temporary hack we applied ?
<NCommander> ogra: TBH, I can't remember
<ogra> with doko saying it should only be temporary until its properly fixed
 * ogra remembers something like that
 * NCommander doesn't, but I'll take your memory over mine any day :_)
<seb128> can somebody check with doko before uploading that change?
 * ogra points to the committer :)
<NCommander> doko_: ping, do you remember if the issue that required us to patch d-shlibs (original bug: https://bugs.edge.launchpad.net/ubuntu/+source/d-shlibs/+bug/504365) was fixed?
<ubottu> Ubuntu bug 504365 in d-shlibs (Debian) "[arm] typo of the dynamic load library prevents build-dependent packages from building" [Unknown,New]
<hrw> lool: "import gcc-4.4/4.5 packaging in bzr" work item - I can publish it in my private branch on LP and let someone else import it as official one?
<lool> jrdnyquist: 11:06 < lool> hrw: I think the gcc bzr import is going to relate to moving to  CodeSourcery patches, we're discussing this next Tuesday on the  toolchain WG call (please join if you like)
<lool> hrw: 11:06 < lool> hrw: I'd start on top of lp:ubuntu/gcc-4.4 in the mean time
<lool> jrdnyquist: Sorry
<hrw> lool: hmm.. if gcc-4.4 and gcc-4.5 are already imported then can we just mark that work item as done? looks like it was not needed to be listed
<lool> hrw: This is an import of the package uploads
<lool> hrw: The idea during the session was to import the packaging repo (SVN)
<hrw> svn of gcc source tree?
<hrw> lool: ping me when you will be available.
<hrw> lool: 'extend binutils binary target to produce cross-compilers and drop binary-cross target' - does it mean that during normal build of binutils we want also to build all cross-binutils (armel, powerpc, x86, x86-64, sparc etc)?
<tkamppeter> To fix bug 465916 in Lucid we would need to add a package post-release. Someone knows how to proceed with that?
<ubottu> Launchpad bug 465916 in cups (Ubuntu) "CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting" [High,Triaged] https://launchpad.net/bugs/465916
<lool> hrw: No, it's just that we'd call dpkg-buildpackage and not binary-cross to build them -- after setting a debian/target architecture
<lool> hrw: SVN of packaging tree
<lool> hrw: I'd rather have the conversations on #ubuntu-arm BTW; zumbi is usually following these
<lool> Depends whether you want Matthias or Hector following I guess :-)
<hrw> lool: ok, lets move there
<doko_> NCommander: I remember the issue, but I can't remember if it's needed for 2.10 as well. it's a typical answer of this debian maintainer ;) let's delay this until 2.11 is in debian
<doko_> NCommander: your lzma process is still running on jocote ...
<NCommander> doko_: yeah. its a test build of qt4 to find out why it timed out
 * NCommander brings death to it
<doko_> ahh, ok
<NCommander> doko_: needless to say, we've found out why it times out ;-)
<ArneGoetje> chrisccoulson: ping
<chrisccoulson> hi ArneGoetje
<ArneGoetje> chrisccoulson: which version of xulrunner will we have in Hardy and Jaunty?
<chrisccoulson> ArneGoetje, we will be adding xulrunner-1.9.2, but xulrunner-1.9 will still be in the archive too
<ArneGoetje> chrisccoulson: how about translations? firefox3.0/3.5 and xulrunner 1.9/1.9.1 have split translations, FF3.6 carries both. Means, the current xulrunner1.9 translations need to be stripped from the langpacks, right? Or should they stay?
<ArneGoetje> chrisccoulson: I guess we keep the xul1.9 translations in the langpacks... xul1.9.2 should do the right thing and take the translations from firefox3.6, right?
<chrisccoulson> ArneGoetje, yeah, i'm just trying to work out how this should work
<ArneGoetje> chrisccoulson: thanks
<happyaron> google code has changed and we need a new debian/watch, but what if I need to use dfsg? I mean dealing with googlecode should have and opts=downloadurlmangle=something, and for dfsg an opts=dversionmangle=something, how to make it work?
<chrisccoulson> ArneGoetje, i think we should just drop the translations for firefox-3.0
<chrisccoulson> if we keep them, then they will appear in the firefox extension manager as an unsupported extension, and i'm not sure anything in xulrunner needs those anyway
<Ian_Corne> Het idee van RBO is dat er slechts \'e\'en domein bestaat, namelijk de waarneembare werkelijkheid. Dit wilt ook zeggen dat iedereen alles op dezelfde manier waarneemt en interpreteert.
<Ian_Corne> In de echte wereld is dit echter ver van de waarheid. Waar de meeste Europeanen maar \'e\'en woord hebben voor sneeuw, daartegenover staat dat de Inuit er minstens twee\"entwintig hebben.
<Ian_Corne> Indien men een ontologie per domein of context zou hebben, wordt dit opgevangen. Veel van deze onderscheiden zijn ook subjectief, wat de classificatie moeilijker maakt. Zo hebben de Inuit
<Ian_Corne> ooops sorry
<Ian_Corne> pasted in the wrong channel :)
<ayan> good morning everyone!
<snodnipper> does anyone have a sec to help out with a dpatch problem?
<siretart> james_w: are you going to check with the TB? - I'm not sure what your concerns are...
<nisshh> jcastro: do you have a minute, i have a quick question?
<hrw> doko_: can you take a look at binutils change? http://paste.ubuntu.com/440913/
<hrw> james_w: you take care of lp:ubuntu/binutils imports? it does not have maverick uploads
<psusi> ScottK: Ted said that Scott had argued that e2fsck needs a "clock totally broken" flag for systems with broken real time clocks.  Did he mean you or Keybuck?
<\sh> seb128: could it be that libebook1.2-dev which ships libebook-1.2.pc does have a totally wrong include dir for e-book.h? I'm trying to get giggle compiled, and it complains about e-book.h not being found...and it seems that the include dir in the libebook pkgconfig file is wrong
<seb128> \sh, lucid?
<\sh> seb128: maverick...but it's not wrong as I see now...giggle is doing something strange during the build...*grmpf*
<\sh> strange it finds the libebook1.2 stuff, but doesn't replace EBOOK_CFLAGS in Makefile
<ScottK> psusi: Keybuk
<ogra> psusi, there is a bug upstream about it
<ogra> psusi, http://sourceforge.net/support/tracker.php?aid=2992187
<ubottu> Error: <Bugtracker.plugin.Sourceforge instance at 0x53ea200> bug 2992187 not found
<ogra> pfft
<james_w> siretart: I didn't see a clear statement of their position, but I may be misremembering
<psusi> ogra: you know much about it?  it seems like the problems arise from the clock being set to a very low value when the root is mounted, then corrected later... I thought that this might be resolved by forcing the clock to be >= the mkfs time stored in the root superblock before mounting it
<siretart> james_w: I'm observing that this issue has been open for a really long time now, and I feel it's gotten stalled again now. I'd love to finally get it done.
<ogra> psusi, seems like ted solved it already in e2fsprogs 1.41.12
<ogra> (see the bug comment on SF)
<james_w> siretart: I think it's resolved in the TBs mind, I just don't remember without looking whether it was "there's no problem", or "it's non-free but redistributable"
<james_w> siretart: do you have a reference to the TB meetings where it was discussed?
<siretart> not at hand, would need to search the archives as well
<siretart> hm the last minutes from the technical board minutes are from 2010-04-20:
<psusi> ogra: I don't see a comment at the url you linked... but it sounded like the "fix" was simply to disable the checks entirely by setting an option in the config file on systems with know broken clocks.  It seems it would be better to let the checks run, but after forcing the clock to a sane value
<siretart> it reads: cjwatson to drive libfaac issue to conclusion: * Outstanding
<ogra> psusi, its SF tracker, you need to expand the comments section :)
<siretart> cjwatson: is the libfaac item still outstanding?
<ogra> there is a little arrow
<james_w> hrw: done
<psusi> ahh, there it goes... wasn't obvious that was clickable ;)
<ogra> yeah
<ogra> i dont know what he did though, you need to look at the code
<psusi> pretty sure it's what I just said
<cjwatson> siretart: yes, sorry, it fell down my to-do list.  no time to think about it now
<ogra> psusi, the "fix" we have downstream is that we set the clock to the last mount time from an initramfs script currently
<ogra> and then leave fsck do its duty
<siretart> cjwatson: ah, okay. No problem, I just wanted to know its status.
<siretart> james_w: ^^
<psusi> ogra: yes, I was thinking mkfs time, but last mount time works too... that seems a better fix to me
<james_w> thanks siretart, cjwatson
<ogra> psusi, but its an initramfs script without initramfs you are screwed ...
<psusi> yep
<ogra> so having it in fsck proper is essential
<hrw> have a nice weekend everybody
<psusi> I'm trying to figure out how such systems impact this patch I'm working on to allow us to turn on LAZY_ITABLE_INIT by default so mkfs goes MUCH faster... it clears inodes found with ctime < mkfs time since they obviously are leftover cruft from a previous fs, but if the system clock is broken....
<ebroder> Is there documentation somewhere on the config file format for Upstart? I'm not really sure where to start looking
<smoser> ebroder, man 5 init
<ebroder> smoser: Thanks, I actually just found that
<ebroder> Does upstart not support dropping privileges?
<smoser> it does..
<smoser> or maybe not
<smoser> i'm onts re
<psusi> it's init.. it kinda needs them
<ebroder> I meant for the jobs it spawns
<ebroder> It doesn't look like it can, though
<smoser> i think it may just expect the daemon to do it
<wise_crypt> i really hope this http://ubuntuforums.org/showthread.php?t=1494955 will be fixed soon enough :(
<smoser> ebroder, i would look at how apache works.
<smoser> oh wait.
<smoser> yeah, i just looked at sshd (/etc/init/ssh.conf) it just expects for the daemon to change uid if its doing it.
<ebroder> That's unfortunate. I was very close to not needing my daemons to know anything about daemonizing themselves
<smoser> ebroder, i do recall that it has been on the feature list
<ebroder> smoser: I don't see it in LP - I'll file a bug against the project
<ricotz> seb128, hello
<ricotz> seb128, i have started and worked my way through to a gtk+3.0 package
<bryceh> slangasek or cjwatson, might one of you know where in Launchpad there is a page entitled "Copy archive contents"?
<bryceh> (I'm fiddling with some Launchpad CSS which might affect that page so want to test it locally before committing)
<slangasek> bryceh: never heard of such a page; afaik we still have to do all our archive copying from the command line
<bryceh> mm ok
<bryceh> slangasek, thanks I think I found it
<mkarnicki> hi all, I'd like to setup my lp project (Google Summer of Code) https://launchpad.net/androidu1
<mkarnicki> and I'm not sure to what branch should I push my in-progress sources
<mkarnicki> (a, my mentor is not around, that's why I'm here :) )
<mkarnicki> I just realized how that's done.. trunk for development, and adding 'stable' to version to indicate that.
<mkarnicki> Never like answering your own question ;)
<james_w> heh
<mkarnicki> lol, I was looking for a project with something more than one branch (trunk), and it's actually featured by lp on main page :D exaile it is.
<james_w> mkarnicki: you can push to any branch you like
<james_w> say lp:~mkarnicki/androidu1/trunk
<mkarnicki> james_w: my mentor just didn't want someone to pull my in-progress (= broken?) code ;)
<james_w> then when you have done that you can link it to your "trunk" series and it people can then refer to it as lp:androidu1
<mkarnicki> aa
<james_w> release early, release broken!
<mkarnicki> hahahah =D
<mkarnicki> that made my day, thank you james_w :D (I know 'release early, release often')
<mkarnicki> hahah :) thanks for help james_w
<mkarnicki> james_w: your a gsoc student?
<mkarnicki> *you're
<james_w> nope
<mkarnicki> mentor? :)
<james_w> yes
<james_w> well, co-mentor I guess
<mkarnicki> I see you on ubuntu-gsoc, that's why I asked ^ ^ I think I also recall you from some mailing list
<james_w> or just a helpful lurker :-)
<mkarnicki> james_w: cool ^ ^! thanks for help, good to have to around :)
<mkarnicki> helpful indeed
<james_w> helpful this time
<james_w> at least
<mkarnicki> don't be so modest :D
<james_w> I'm looking forward to trying your project though
<mkarnicki> I'm happy to hear people say that ^ ^
<AgentLime> got a question about ubiquity... anyone have any experience with it?
<fta> siretart, hi, do you plan to re-upload mplayer in maverick?
<fta> siretart, (the last ffmpeg upload killed it)
<bloopbloop> Can anyone here help me compile a kernel module on Ubuntu 10.04?
#ubuntu-devel 2010-05-29
<pwnguin> was libdns53 updated recently?
<ScottK> Probably.  Launchpad knows for sure.
<pwnguin> hmm
<pwnguin> actually, maybe its me and not libdns/lp
<pwnguin> but is (.= 5.3.6) a valid versioned dependency?
<pwnguin> dpkg doesn't seem to think so
<ScottK> Current version is 1:9.6.1.dfsg.P1-3ubuntu0.3
<pwnguin> i had some system instability today, but it seems odd that i would lose one specific character in a few fields
<pwnguin> the number was made up, sorry
<pwnguin> here's a concrete example from /var/lib/dpkg/available
<pwnguin> Depends: libc6 (.= 2.3.4-1), python-2.3
<ScottK> What package?
<pwnguin> python2.3-egenix-mxtools
<pwnguin> is there a way to just clear out /var/lib/dpkg and let apt rebuild it? cuz i dont really trust it right now
<ScottK> Well first, that is an incredibly ancient package.
<pwnguin> i know
<ScottK> If you don't trust /var/lib/dpkg, why do you trust the rest of the system?
<pwnguin> well, it's running, so there's that
<ScottK> That may be just because stuff hasn't been re-read off of disk.
<pwnguin> i just rebooted like twenty minutes ago
<pwnguin> and looked at the file in question with emacs
<pwnguin> this system has been dist-upgraded from 4.10 for the past 5 years
<pwnguin> so im willing to chalk the ancientness of this particular package to a cache that was never cleaned
<ScottK> Why don't you pick a non-ancient package and we'll compare results?
<pwnguin> because that's the one dpkg is failing on
<pwnguin> ok
<pwnguin> found the command
<pwnguin> dpkg --clear-avail
<pwnguin> heh
<pwnguin> apparently my solution of moving the file was bad, but --clear-avail just makes a new empty file and thats okay
<pwnguin> anyways, mystery 1 of ten solved
<pwnguin> ok, now ext3 just went to readonly mode. it may be time to retire this machine =(
<lokpest> has the idea of not having separate distros for each desktop enviroment but instead let people choose DE at install time been discused?
<cody-somerville> Yes.
<lokpest> general conclusion? any links?
<cody-somerville> We want the install to be as simple as possible.
<cody-somerville> No need to bother someone with that question who might not understand it.
<lokpest> ok, but then it should be an advanced option
<stenten> Also, how would you get all that onto a LiveCD?
<cody-somerville> 1. Its possible to install different desktop environments very easily for folks who want to. 2. If someone wants a specific desktop environment, they just download the appropriate CD.
<cody-somerville> and stenten also makes a very very very good point.
<lokpest> its not like everybody has to partion there drives, thats the advanced option
<cody-somerville> We agree with you.
<lokpest> ok, but that was an argument against "being as simple as possible"
<cody-somerville> how so?
<cody-somerville> Oh, I see what you mean.
<cody-somerville> regardless, we still can't fit multiple desktop environments on one CD
<lokpest> not everyone has to partition, but you can if you want to. not everyone should be forced to pick a DE (default for gnome)
<stenten> If you wanted that option, you'd have to have a minimal install, and then reboot into a barebones machine and install the DE.
<stenten> Why would we do that to users?
<stenten> And it would also mean the LiveCD wouldn't be an option, because you wouldn't have the space for an Ubuntu live environment along with all the Qt packages of Kubuntu.
<lokpest> the CD is a dying medium
<cody-somerville> oh please, lets not get into that argument
<cody-somerville> there are tons of people around the world who still use CDs and who have very poor internet connections
<lokpest> ok, but there could be an alternate medium install?
<cody-somerville> there is
<cody-somerville> its called xubuntu, kubuntu, edubuntu, etc.
<lokpest> meh
<lokpest> Canonical favors gnome
<lokpest> the reason for my question is, if I want to use a distro based on ubuntu that does ony come with gnome preinstalled, how do I remove all gnome and gnome apps? sure I can install kubuntu-deskop, but removing ubuntu-desktop is much more tiresome...
<lokpest> as removing the meta-packages dont remove all the apps
<cody-somerville> you download the Kubuntu CD
<lokpest> ....
<lokpest> I dont want kubuntu
<cody-somerville> If you remove gnome and install kubuntu-desktop, you pretty much what you'd get if you installed the Kubuntu CD
<lokpest> I want the kubuntu-desktop of the ubuntu-derivative
<cody-somerville> Do you not understand that Ubuntu, Kubuntu, and Xubuntu are all built out of the same archive and share the same base set of packages?
<lokpest> yes I do
<lokpest> but removing ubuntu-deskop doesnt remove all non kubuntu apps
<cody-somerville> it does nothing, its a meta package
<lokpest> there will still be software that are not kde
<cody-somerville> wow, thats even a more corner case
<stenten> lokpest: http://www.psychocats.net/ubuntu/purekde
<cody-somerville> stenten, he doesn't want pure kde
<cody-somerville> stenten, he wants the tainted, lol
 * stenten facepalms
<lokpest> stenten: ty!
<stenten> rofl
<cody-somerville> lokpest, That'll give you what you'd get if you installed Kubuntu....
<lokpest> yes
<lokpest> and i dont want kubuntu
<lokpest> I want trisquel
<lokpest> but trisquel only comes with gnome
<stenten> you can run gtk apps on kubuntu...
<lokpest> but I know I could install kubuntu-desktop, but that didnt solve the problem that stentens link solves
 * lokpest dislikes where ubuntu is going freedome-wise
<stenten> Couldn't you just install Kubuntu and then install trisquel?
<stenten> i'm so confused :(
<lokpest> huh?
<cody-somerville> Anyhow, this is starting to get off topic for this channel.
<lokpest> trisquel is a distro based on ubuntu
<lokpest> right, mentioning that you dont like Canonicals policies regarding proprietary software is not allowed
 * lokpest *notes down*
<ScottK> stenten: That link doesn't do what it says it does.  The standard Kubuntu install is not pure KDE.
<lokpest> sadly no
<lokpest> it installs OO.org and shit
<lokpest> why anyone would want a word processor beats me
<stenten> My bad. Thanks for letting me know.
<lokpest> I dont know why I let other people pick aplications for me
<asac> lokpest surely can use the alternate installer and start from zero ;)
<ion> asac: Heâd still have Linux, the GNU coreutils, an init daemon etc. chosen for him! Even thatâs obviously too little control.
<asac> lol
<wgrant> Anybody up for a derivative that doesn't even include coreutils?
<wgrant> I think it's a useful market to expand into.
<asac> i can release the "empty" derivate ;)
<ion> But... but... by installing it, youâre still picking the empty for me!
<aburch> ion: Debian at least has a FreeBSD kernel as well. :)
<asac> empty is nothing so i am not picking anything ;)
<wgrant> Indeed, we'd still be choosing a set of applications :(
<wgrant> We cannot win.
<ion> asac: [] is just as valid a set of stuff as [linux, coreutils, ...] ;-)
<asac> [] != NULL
<asac> i go for the NULL
<asac> but yeah. i think there is always the DIY derivate
<aburch> Does libmediawiki-perl have any rdeps in Ubuntu?
<wgrant> At least not in lucid.
<mneptok> no coreutils? maybe then RMS will let everyone call it just "Linux"
<ion> Hah
<wgrant> Haha.
<mneptok> "why anyone would want libc is beyond me. i just want a word processor."
<siretart> fta: can you please file a bug about that? the issue is more complicated as it looks on the first sight, and I think that should be documented in a bug
<fta> siretart, bug 587203
<ubottu> Launchpad bug 587203 in mplayer (Ubuntu) "mplayer relocation error with the new ffmpeg" [Undecided,New] https://launchpad.net/bugs/587203
<siretart> fta: I see. hm. I'm pondering if I should add Breaks to libavcodec on mplayer
<siretart> whay do you think?
<fta> unsure. A rebuild of mplayer + a deps libavformat52 (>= 4:0.6) should be enough,
<fta> i see you have a new mplayer to merge
<siretart> ok
<siretart> also note my comment on the bug
<ion> If a new version of a library breaks existing stuff that uses it, shouldnât there be a soname bump?
<siretart> ion: a) the symbol in question was an unpublished, private symbol which mplayer should not have referenced in the first place, and b) the soname was bumped for libavutil49 -> libavutil50
<fta> yep, it should. libavutil just got one (49->50)
<fta> oh
<siretart> in order to adress the transitive dependency problem, I've introduced symbol versioning, both upstream and in the package
<lool> mdeslaur: Sorry, missed your note on virt-manager; just uploaded my own merge
<lool> mdeslaur: Please replace with yours if I missed anything
<fta> siretart, can't you just backport the ftbfs fix from rc4 to rc3?
<siretart> fta: a) - there is not even a rc4 branch yet and b) there has been over a year of active development in libswscale, and we are talking about implementation internals that are used in the more obscure parts of mplayer. I'm currently discussing them upstream for exactly this reason.
<fta> siretart, do you mean it's also broken in debian/unstable?
<siretart> fta: debian/squeeze will ship ffmpeg 0.5, so I won't upload ffmpeg 0.6 to unstable. period.
<fta> oh, I didn't know that
<siretart> fta: if you would install ffmpeg from experimental, then yes, mplayer will break
<siretart> however maverick has just opened, so its a perfect time to see how many and what packages break with ffmpeg 0.6 :-)
<siretart> mplayer was pretty obvious to me
<siretart> fta: btw, I really lot of folks have demanded to include ffmpeg 0.6 for lucid. in fact, the package was even ready in time, but now you know why I've rejected that :-)
<Chipzz> ion: soname versioning? the mplayer project? surely you are kidding? :)
<fta> siretart, i'm a heavy user of mplayer since ~2001, i've built it from cvs/svn for many years, i know how painful it is
<Chipzz> iirc the best known project for NOT using sonames properly is mplayer and assorted side-projects
<siretart> please stop spreading FUD. a) mplayer doesn't provide any shared libs. at all. and b) I've joined ffmpeg upstream exactly for this reason
<fta> siretart, yesterday, i was caught in that bug so i just downgraded ffmpeg to finish what i was doing. now i'm willing to give a try at whatever solution you may have
<siretart> fta: as indicated, I'd drop the build dependencies on libavcodec-dev, libavformat-dev, etc. and build statically against the included copy as interim hack
<siretart> in parallel, work upstream on getting rc4 in shape
<Chipzz> siretart: good to know you're working with upstream. not wanting to sound sarcastic, but any success in what you're trying to do (which I assume is trying to convince them of the merrits of a more stable API)?
<siretart> Chipzz: depends on what you mean with stable API. if you mean 'no changes' - that would also mean no development and more features.
<siretart> Chipzz: if you mean 'no backwards incompatible changes', that's fairly a non-issue since years
<siretart> Chipzz: the fact that many projects use unpublished headers internals that are subject to change cannot be solved from within ffmpeg. those projects needs to work with upstream to get that functionality public or stop using it
<blue_anna> is the system strftime the one in gnulib package? just a bit confused because I was expecting a something -dev
<StevenK> blue_anna: No, you want libc6-dev for strftime
<blue_anna> StevenK: thank you
<blue_anna> StevenK: I have the libc6-dev installed instead of the libc6-dev-ppc64, and libc6 instead of libc6-ppc -- would that cause problems? :) I was just about to try to debug why strftime's %P and %p weren't working
<blue_anna> I'm on a powerpc architecture :)
<blue_anna> you know, I installed gnulib and %p started working
<blue_anna> lol what a crazy system
 * wise_crypt is away: need a rest, tired looking a fast channel :)
<blue_anna> I just noticed that my system does not have installed the libc6-ppc64 library but does have the libc6 standard. I've been noticing plenty of odd little behaviors and a general slowdown of applications and I'm starting to think it is that the powerpc architechture was built against the wrong set of libs
<blue_anna> any idea how I can scan for libraries that have a -ppc64 alternate that is not installed, when the base library is?
<Q-FUNK> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186
<ubottu> Ubuntu bug 587186 in eglibc (Ubuntu) "libc6 upgrade fails: illegal instruction" [Undecided,New]
<Q-FUNK> is this for real?
<blue_anna> Q-FUNK: what are you doing?
<Q-FUNK> blue_anna: come again?
<blue_anna> Q-FUNK: the page you linked wasn't loading :) I see it now
<blue_anna> Q-FUNK: you've got the wrong architecture package for libc for some reason
<blue_anna> Q-FUNK: i386 instead of i586 for your system, looks like
<Q-FUNK> blue_anna: no, I don't.  see doko's answer to the bug.
<blue_anna> Q-FUNK: the only responces I see in there are from Martin
<Q-FUNK> blue_anna: we never had i586 packages.  i386 has always implied i386 and newer x86 arch.
<blue_anna> ok, but it says in the log Uname: Linux 2.6.32-10-generic i586
<blue_anna> Q-FUNK: what's uname -r say? just to verify -- I mean, if that still works :S
<Q-FUNK> that's the cpu architecture on the hardware as reported by uname.
<blue_anna> Q-FUNK: can you link me the specific responce you meant? I don't see any responces from any "doko"
<azeem_> blue_anna: Matthias
<azeem_> Q-FUNK: so your question is whether 10.10 will only support i686 or not?
<blue_anna> I need a link -- there's no Matthius on the page either, taht I see
<azeem_> "Matthias Klose wrote 2 hours ago:"
<azeem_> blue_anna: maybe you opened the wrong link
<Q-FUNK> azeem_: if that's the case, it should be advertised in a more blatant way.
<blue_anna> Ah no, its that Matthias and Martin look very much alike :)
<azeem_> Q-FUNK: it will be in the release notes I guess
<blue_anna> Q-FUNK: can you roll it back from live cd?
<Q-FUNK> azeem_: you'll notice that this decision will essentially kill LTSP on Ubuntu, btw.
<chrysn> when modifying a debian /contrib package for ubuntu, should it go to universe or multiverse?
<azeem_> blue_anna: I don't Q-FUNK ask for support
<azeem_> asks*
<Q-FUNK> blue_anna: yeah, that's not a problem.  the real problem is ubuntu distributing packages marked as i386 that are really meant for i686.
<azeem_> eh, that's not the problem
<blue_anna> ok, yea that's a problem
<azeem_> i386 is the processor architecture
<blue_anna> glad to hear you're system's not fried :)
<azeem_> that 10.04 already requires i586 I guess, 10.10 would just bump it to i686
<chrysn> (it's in contrib as it depends on libcgal, which is qpl and therefore in nonfree)
<Q-FUNK> azeem_: libc6 was built with -m686, if doko's reply means anything.
<bluefoxicy> this is strange
<bluefoxicy> I have trouble connecting to a wifi access point
<bluefoxicy> what happens is when I connect to it properly, iwconfig shows the correct ESSID
<bluefoxicy> wlan0     IEEE 802.11bg  ESSID:"Public Hotspot - BIHS"
<bluefoxicy> However, in other times when it refuses to connect...
<bluefoxicy> bluefox@icebox:~$ sudo iwconfig wlan0 essid dogs
<bluefoxicy> bluefox@icebox:~$ sudo iwconfig
<bluefoxicy> wlan0     IEEE 802.11bg  ESSID:"dicks"
<bluefoxicy> bluefox@icebox:~$ sudo iwconfig wlan0 essid "Public Hotspot - BIHS"
<bluefoxicy> bluefox@icebox:~$ sudo iwconfig
<bluefoxicy> wlan0     IEEE 802.11bg  ESSID:"%\xCF\x08\xF5\xE9\xE2^S`\xAA\xD2\xB2\xD0\x85\xFAT\xD85\xE8\xD4f\x82d\x98\xD9\xA8\x87uepZ\x8A"
<bluefoxicy> er.  Censor fail <_<;
<bluefoxicy> Ignore the output of my turrets.
<bluefoxicy> at any rate a second try does this
<bluefoxicy> wlan0     IEEE 802.11bg  ESSID:"?b\x80)D\xDE|\xA5\x89NWY\xD3Q\xAD\xAC\x86\x95\x80\xEC\x17\xE4\x85\xF1\x8C\x0Cf\xF1|\xC0|\xBB"
<bluefoxicy> and so on.  Constant garbage
<crimsun> Q-FUNK: I'm presuming that doko didn't follow the link from ProcVersionSignature/Uname in the bug report. Otherwise, were you aware of https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-686-compile ?
<Q-FUNK> crimsun: I wasn't aware of it and now that I am I cannot agree with it.
<ScottK> Until you convince someone to change the design decision, it's pretty clearly not a bug.
<Q-FUNK> ScottK: bedian went through this one when they bumped up the minimal requirement on sparc.  it would be a good idea to follow what they did, to prevent upgrades from taking place on older hardware.
<Q-FUNK> debian, even
<ScottK> I think that's a valid point.
<ScottK> If you reframed the bug that way, I think it's reasonable.
<Q-FUNK> ScottK: well, there is a larger issue at stake:  building with anything newer than -m586 essentially kills the whole LTSP project's ability to run on Ubuntu, since most terminal hardware is 586 generic.
<Q-FUNK> noticing that the blueprint for that m686 idea is a blank template also makes the proposal rather suspicious.
<crimsun> I trying (and failing miserably) to find a recent mailing list post regarding the UDS-Maverick Foundations outcomes, but there's http://oubiwann.blogspot.com/2010/05/ubuntu-foundations-and-maverick-meerkat.html
<jpds> Q-FUNK: http://pastebin.ubuntu.com/441398/
<Q-FUNK> jpds: interesting.
<crimsun> oh good, I was having problems connecting to the gobby doc
<Q-FUNK> all this shows is tha choosing m686 was more of a me-too choice than a properly planned change.  m586 wasn't properly investigated, according to that.
<Q-FUNK> it also shows that whoever is gonna upgrade from lucid to lucid+lts is gonna have a nasty surprise.
 * ogra_tb is pretty sure update-manager will have proper warning mechanisms builtin by then
<Q-FUNK> ogra_tb: back when debian bumped the sparc requirement, they installed a check in libc6's preinst script.   if the hardware was no longer supported, the package refused to be updated.
<blue_anna> what provides all the fstab functionality? getmntent(), etc
<ogra_tb> well, there are more elegant ways in ubuntuu
<Q-FUNK> update-manager is not one of them.  it wouldn't be foolproof
<ogra_tb> solutely foolproof
<ogra_tb> *it's absolutely
<ogra_tb> and already has such checks for ARM
<blue_anna> is 10.10 on eglibc2.12 or still 2.11?
<Q-FUNK> today was the first 2.12 snapshot upload
<aburch> I have one backport request which was ack'ed a month ago but hasn't been uploaded since (LP #550880). Is there anything left to do?
<ubottu> Launchpad bug 550880 in Karmic Backports "Please backport simutrans-pak64/102.2.2-1 from Lucid" [Wishlist,In progress] https://launchpad.net/bugs/550880
<blue_anna> anyone know what handles the UUID /LABEL translation in /etc/fstab? from the manpages you would think it is mntent.c but I just read that and mntent_r.c and its not there.
<blue_anna> so I grepped the entire eglibc tree for UUID and it's nowhere in the code
<blue_anna> just trying to find a foothold
<geser> blue_anna: try looking at libblkid1 as its description seems to match what you look for (and mount depends on it)
<blue_anna> geser: thank you
<blue_anna> anyone here use yaml in C?
<ScottK> aburch: No.  It just waits an archive admin to process it.
<stefanlsd> nigelb: heys. give me a shout when your around. exams finished, so can spend some time on cleansweep
<blue_anna> stefanlsd: you had exams last week?
<blue_anna> it's almost june
<stefanlsd> blue_anna: mm. isnt that normal exam time? (uni)
<blue_anna> dunno, been so long since I was in college :) my brother just finished his about 4 weeks ago
<stefanlsd> blue_anna: im also in africa, stuff happens slower here :)
<blue_anna> lol I doubt that -- but maybe classes
<Sarvatt> is cifs-utils going to brought over from debian for maverick? smbfs hasn't been installable for about a month, had to grab cifs-utils which replaced it from debian to mount some windows shares
<geser> Sarvatt: most likely but the archive admins have to review the list of NEW packages before syncing them which takes time. You might want to poke an archive admin (e.g. cjwatson) to sync it faster.
 * wise_crypt is away: sleeping 
<cherva> can someone help me with to command to get the current source for gnome-screenshot from svn.gnome.org ( http://svn.gnome.org/viewvc/gnome-utils/trunk/gnome-screenshot/ )
 * wise_crypt is back (gone 00:05:37)
<cherva> so I can try to tweak it a little for 10.10
 * wise_crypt is away: 
<arand> cherva: "GNOME has changed to using Git for version control. Current GNOME sources can be found on git.gnome.org. All content on this site is obsolete"
<cherva> arand, 10x
#ubuntu-devel 2010-05-30
<quark2> greetings, anyone here might be able to help me with a mount issue?
<ScottK> quark2: Help is in #ubuntu.
<quark2> tried that got no response, was searching out another room
<LaserJock> ScottK: +1 on the UDS email
<ScottK> LaserJock: Thanks.
<ScottK> quark2: Understand.  That does't make this a support channel.
<gbear14275> I'm trying to debug an error with virt-manager using strace... looking grim.  There are a few dev packages associated with libvirt but I'm not familiar with how to use them... can anyone offer up some advice on perhaps this as a better way to try to troubleshoot
<gbear14275> the problem is am trying to spawn a new VM using virt-manager on a remote machine.  I put the .iso's into the /var/lib/libvirt/images directory and can browse to them and select them but am getting this error on trying to hit next: Checking installer location failed: Could not find media '/var/lib/libvirt/images/debian-504-amd64-netinst.iso'.
<Drakeson> I have a vala question: How does one instanciate http://www.valadoc.org/gio-2.0/GLib.OutputVector.html
<xnox> Drakeson, try #vala on GIMPNet irc network ?
<Drakeson> xnox: I had already done so. I posted here out of despair.
<Drakeson> anyways, sorry about that.
<xnox> Drakeson, on a holliday weekend both in US&UK all channels can be unresponsive ;-)
<antivirtel> re
<antivirtel> !bug 321012
<ubottu> Launchpad bug 321012 in xchat (Ubuntu) "XChat - missing icons" [Undecided,Confirmed] https://launchpad.net/bugs/321012
<blue_anna> I think my system implimentation of binary64 is broken http://pastebin.ws/6tahvb
<blue_anna> I think my system implimentation of binary64 is broken http://pastebin.ws/6tahvb -- according to the ieee754 standard (http://en.wikipedia.org/wiki/IEEE754) doubles should never be inaccurate for 16 digits, and only have a rounding error at the 17th digit
<David-T> oh. he's gone.
 * David-T assumes the rounding error is introduced at the 17th digit of 91.6, which ends up being the 16th digit of 8.4
<blue_anna> are there any scripts that automate making an ubuntu .deb package given a standard configure/make/make install setup?
<Chipzz> blue_anna: dh_make
<blue_anna> Chipzz: thank you :)
<Chipzz> blue_anna: also note that your question regarding binary64 was off-topic for this channel
<blue_anna> Chipzz: I think that the MPC that we use is buggy, I'm building gcc with mpc 0.8.2 to see if it fixes it
<Chipzz> I think the package is called dh_make, and the command dh-make
<ebroder> Chipzz: other way around
<Chipzz> dh-make is not specific to packages using auto* though, it's mostly a convenient way of creating the debian dir for packages in general
<Chipzz> ebroder: ah, I always got that mixed up
<ebroder> blue_anna, Chipzz: dh_make won't do all the work for you, though - you still need to handle setting build-dependencies and dependencies and any special flags to ./configure and stuff like that
<ebroder> Chipzz: Package names can't have underscores; that's how you can tell which is which
<Chipzz> ebroder: I'm aware of that
<BlackZ> I think the right place for that is #ubuntu-motu :)
<Chipzz> ebroder: right, I thought of that after you told me dh-make was the package name :)
<Chipzz> BlackZ: it would be more appropriate there probably, yes, but apparently the channels' rules were changed a couple of months ago, so this isn't off-topic here anymore
<Chipzz> blue_anna: anyway, all dh-make does is generate a skeleton debian dir for you, which you still have to edit afterwards
<Chipzz> but a big step in the right direction nevertheless
<blue_anna> beats typing :)
<blue_anna> even if there's some leftover
<Chipzz> although I'm not sure how usefull that actually still is with the convenience of latest debhelper dh commands
<Chipzz> (note that I said dh commands, not dh_* :))
<blue_anna> I guess I should ask on motu?
<blue_anna> well it won't matter unless this gcc does what I think it is going to
<blue_anna> man this thing takes a day and a half to compile
<wladimir> is there something like a pluginapi available for MeMenu?
<ebroder> Ugh. Looks like linux is stuck in NEW, but linux-meta went through, which is blocking installs
<dav_it> hi
<dav_it> please, someone can explain me why we need this? https://wiki.ubuntu.com/SecurityTeam/Policies#Execute-Permission%20Bit%20Required
<blue_anna> dav_it: its possible that you could find a way to make a system program execute a downloaded file even though it was never set to execute
<blue_anna> dav_it: never set executable
<blue_anna> dav_it: the expectation, I guess, is that users generally will not be allowed to download anywhere else on the system
<dav_it> blue_anna: ok, but for example if I open a terminal, and I type "wine foo.exe" the file will open w or w/out permission bit.
<blue_anna> dav_it: which really blows my mass-data storage drive :P
<dav_it> blue_anna: so, my question is: isn't this only a freakin' workaround?
<blue_anna> dav_it: for you .. I don't ahve wine
<blue_anna> **maybe wine is broken, actually
<blue_anna> because I'd think that's a security bug too
<dav_it> blue_anna: actually it shouldn't be checked that all application that can run .exe can't run files w/out executable bits
<dav_it> ?
<blue_anna> dav_it: well, you're saying that's the way it is now right?
<blue_anna> so ... there you are :)
<dav_it> blue_anna: "there you are" is a synonim for fix it if you want?
<blue_anna> dav_it: fno I thought you said the reverse. are you saying that wine is broken in your opinion, or that if ubuntu is going to have that policy, it should apply to to apps like wine too?
<dav_it> blue_anna: the second one.
<blue_anna> dav_it: yeah ok, I agree with you ...
<dav_it> blue_anna: I think that if Nautilus can't open that file, also wine shouldn't.
<dav_it> who did introduced this feature?
<dav_it> s/introduced/introduce/
<blue_anna> dav_it: wine?? yeah I'm sorry I don't know that, maybe someone else will pipe up
<blue_anna> dav_it: what are the requirements for wine?
<blue_anna> I'm just wondering what scripting language the wrapper script should be in if it's going to be protected
<dav_it> blue_anna: I'm wondering also.
<blue_anna> dav_it: are you going to write one? do it in whatever you want and then offer that as a prototype .. if they want to change languages after the fact someone will translate it
<dav_it> blue_anna: it seems to me somethin' like that security advices from windows vista.
<blue_anna> reading that description, it can't be a wrapper script .. 4th bullet
<dav_it> blue_anna: I'd like to talk before with the guy that introduced this feature, that atm seems me totally nonsense.
<blue_anna> got to actually impliment it in the code -- unless there's a kernel security thing for it there must be a library for it.
<blue_anna> dav_it: I dunno man, looks like crossed wires to me
<dav_it> is there an ubuntu security channel?
<blue_anna> yes, but I think it is for a variant of ubuntu
<arand> dav_it: #ubuntu-hardened
<arand> dav_it: But wine is not their business, afaik
<dav_it> arand: it's their business that a policy doesn't work, I guess.
<blue_anna> what provides tr1/cstdio? I just compiled gcc-4.5 and it won't build anything without it :)
#ubuntu-devel 2011-05-23
<djustice|fff> dgen pkg.. x64 is busted, --force-arch an i38b deb and it's good.. -.- wth..
<pitti> Good morning
<stgraber> good morning pitti
<ajmitch> morning pitti
<didrocks> good morning
<dholbach> good morning
<doko> apw, rtg: could one of you merge kexec-tools?
<apw> doko i don't think i have ever done that, is there some docs on how one does
<doko> jhunt: could you take over the libnih and sysvinit merges?
<apw> (its likely about time i did know how)
<doko> apw: ahh, no, seems to be a lool thing (arm)
<apw> doko, ahh ok
<persia> apw, You may as well try if you want to learn.  Basically grab the debian and Ubuntu sources.  Look at the diff between Ubuntu and the Debian upon which it is based.  Discard that which is unneeded, and rebase the rest on the new Debian.
<persia> (if you are slow, or get it wrong, lots of folk (probably especially lool) would be happy to help)
<apw> persia, yep
<cjwatson> apw: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<apw> cjwatson, ahh thats what i am looking for thanks
<Laney> http://people.canonical.com/~dholbach/packaging-guide/html/udd-merging.html ;-)
<pitti> kees, jdstrand: releasing hardy linux to -security/-updates
<jhunt> doko: looking at it now...
<doko> cjwatson: openssl again builds for i486/i585/i686. merge error?
<cjwatson> doko: where are you seeing that?  no sign of it in https://launchpadlibrarian.net/70883771/buildlog_ubuntu-oneiric-i386.openssl_1.0.0d-2ubuntu1_BUILDING.txt.gz
<pitti> tkamppeter: hey Till, how are you?
<pitti> tkamppeter: has there been a decision of https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-system-config-printer-vs-gnome-3-control-center ? can you please add some work items and clean up the whiteboard, to turn it into a real blueprint? thanks!
<doko> cjwatson: ouch, wrong chroot :-/ one more coffee ...
<cjwatson> heh
<apw> cjwatson, kexec-tools in debian recently added a udeb, we seem to have not pulled that in in previous merges, do we want that do you think?
<cjwatson> feel free to include it
<cjwatson> in general if Debian has something there should be an explicit reason not to have it
<cjwatson> and there isn't, in this case
<cjwatson> (not saying our installer will actually use it though)
<apw> cjwatson, ack
<cjwatson> doko: llvm-2.8 seems to build successfully on current amd64; mind if I do a no-change upload of it to finish the ocaml transition?
<cjwatson> doko: (I'm not in ~pkg-llvm, though, so can't commit to its branch)
<doko> cjwatson: sure; I hope, we can drop it later this cycle as well
<cjwatson> right, no objection to that, just want it off my list for now :)
<cjwatson> oh, lp:~pkg-llvm/+junk/llvm-2.8-ubuntu is out of date anyway, so meh
<doko> my bad
<cjwatson> freeflying: can libofetion be synced, or does it need a merge?  openfetion needs a newer version of it to build
<ElementCracker> :D
<apw> cjwatson, we have some ubuntu specific patches on kexec-tools, but they are not named specially, is there value in prefixing them with ubuntu- for clarity?
<cjwatson> apw: practice varies
<cjwatson> some people like to do that; I don't consider it critical
<tkamppeter> pitti, OK. My plans this week are putting up bug reports on the appropriate packages to make up work items, so that the two Blueprints get implemented.
<pitti> tkamppeter: ah, good; please link the bug reports to the specs, then they automatically become tracked as work items
<tkamppeter> pitti, this was my intention.
<tkamppeter> pitti, for new packages to be added, like colord, I have to link a "Needs packaging" bug?
<tkamppeter> pitti, colord is not really a printing package, but something more general, who should package and maintain this?
<ScottK> pitti: Who is "fboucault" to whom you gave a work item in the CD space spec to split off Qt modules?  It'd be nice if there was some coordination with the Kubuntu team on this.
<pitti> ScottK: I just reordered it, it was already there
<ScottK> OK.
<pitti> ScottK: Florian has worked on unity-2d and some Qt packaging improvements
<pitti> of course this should be coordinated with Debian as well ideally
<ScottK> Yes.
<ScottK> Doesn't seem to be on any channels I'm in for IRC (Kaleo)
<pitti> (pinged him)
<kaleo> hi
<pitti> ScottK: please meet kaleo (Florian), who works on unity-2d
<ScottK> Thanks.
<pitti> kaleo: please meet ScottK, one of the Kubuntu masters (in this context)
<kaleo> :)
<kaleo> hi ScottK!
<ScottK> kaleo: I see you have a work item to split out some Qt modules to save space on the Ubuntu CD.
<ScottK> When you are ready to work on this, I'd like to invite you to join us in #kubuntu-devel to coordinate the change.
<kaleo> ScottK: I think my work item was to list the Qt modules required by Unity 2D
<ScottK> You are, of course, welcome anytime, but I want to make sure that things are coordinated.
<kaleo> ScottK: I just joined
<ScottK> Great.
<seb128> didrocks, ^
<seb128> didrocks, (not sure if you work on that or not, just highlighting in case)
<ScottK> The work item in question is " [fboucault] Split off some more Qt modules which we don't need (> 1 MB):"
<didrocks> yeah, I was supposed to coordinate that with the kubuntu team in case, didn't know kaleo had a WI
<didrocks> seb128: thanks for the hilight :)
<seb128> seems like the wi should be for didrocks
<didrocks> kaleo: reassign me this one
<kaleo> didrocks: I need to find it first :)
<kaleo> (I'm pretty new to using blueprints)
<pitti> or split it into "[florian] figure out needed modules" and "[didrocks] split pacakge"?
<ScottK> https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-cdspace
<didrocks> and anyway, as I already discussed for comaintainance with ScottK, I'll do that with the kubuntu team, once I'll have the list of needed module
<ScottK> OK.  Great.
<kaleo> ScottK: thanks
<kaleo> pitti: good idea, let me do that
<pitti> kaleo: FYI http://people.canonical.com/~platform/workitems/oneiric/canonical-desktop-team.html#fboucault
<pitti> kaleo: has links to the blueprints, etc.
<kaleo> pitti: superb, thanks
<kaleo> didrocks: I split the WI
<kaleo> didrocks: I mean, I just did the split
<didrocks> kaleo: excellent, thanks :)
<kaleo> didrocks: I shall send you an e-mail with the list of modules
<didrocks> kaleo: perfect!
<kaleo> didrocks: done!
<pitti> kaleo: congrats, you are the first to finish all his oneiric WIs on the desktop team page :)
<apw> is there a google calendar for the ubuntu release schedule for oneiric ?  doesn't seem to be in any of the ones already have
<apw> (i suspect i used to be the Ubunt Release calender ... which stopped at 11.04)
<apw> skaet, the Ubuntu Release calender does not have anything for Oneiric in it, is that an oversite or is the info no longer there)
<freeflying> cjwatson: libofetion can be synced, and in terms of the FTBFS of openfetion, will do a upload soon to fix the build dependency
<cjwatson> freeflying: OK, can you file a sync request bug please?
<cjwatson> freeflying: why does openfetion need an upload?  I thought it was just that it needed the newer version of libofetion.
<freeflying> cjwatson: because of the name change of libnotify
<cjwatson> ah
<kaleo> pitti: thanks, I will be glad to get a tiny item next cycle :)
<apw> persia, i wonder if you would have a min to review the kexec-tools merge i've been playing with: https://code.launchpad.net/~apw/ubuntu/oneiric/kexec-tools/merge
<apw> (or indeed anyone who is interested)
<persia> apw, I'd be happy to take a look.  I can't accept the merge.
<apw> np, more worried about the mechanics at this stage
<persia> Speaking personally, when doing packaigng with bzr, I like to have one commit per debian/changelog entry, for ease of comprehension.  This doesn't affect anything: just expression of personal preference (and happens to work really nicely with debcommit)
<apw> persia, mostly this was a scripted package-merge so there is only one change in that sense
<persia> apw, Looks properly formatted and documented to me.  The patches seem to apply/unapply cleanly (I'm not sure if you had to rebase, but if you did, nice work).
<apw> persia, thanks :)
<cjwatson> ogra_,NCommander: FYI, https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-live-build
<skaet> apw,  Updating the ubuntu release calendar for Oneiric is on the to do list for this week.
<apw> skaet, ok cool, just wondering as it appears that a1 is already "next week"
 * skaet nods
<apw> lool, you about?  wonder if you could review a kexec-tools merge i have done, seems you are nominal owner: https://code.launchpad.net/~apw/ubuntu/oneiric/kexec-tools/merge
<jaromil> re all
<jaromil> i'm trying to add our software (apt.dyne.org WIP) to software-center. have so far read the code and the little docu available and couldn't manage to have anything else to appear on the left panel below Canonical Partners
<jaromil> anyone willing to reply a few questions? i'd like to avoid taking drastical decisions, like overwriting software-center code or fork it
<jaromil> maybe i'm doing something wrong, yet adding a .list and .eula into app-install/channels doesn't suffices
<persia> jaromil, app-install-data-partner is a handy reference package for your goal.  Don't forget to include .desktop files (and associated assets).
<jaromil> saw that. ah! .desktop etc. is also needed to activate the display of channel?
<persia> I'm not an expert (I last played with a channel for karmic), but the desktop files are used to display the software choices.
<jaromil> thanks for the tip! i will complete the package with .desktop files for software and see how it goes. cheers!
<lool> apw: Merge looks good on the packaging side, there are some gratuitous changes in the diff which I think result from cleaning the package and then committing the cleaned tree
<apw> lool, yes indeed, is clean the wrong state ?
<jaromil> i'm not sure about the channel, well it sounds worth trying
<lool> apw: I'm speaking of the delta on generated files like ./kexec-tools.spec, ./include/config.h or ./configure
<apw> lool, yeah, unsure what to do with those, i almost feel they shouldn't have been there before
<lool> apw: This is a bug in the upstream and/or Debian build scripts, but it would be best if you would revert to the state before cleanup so that this doesn't show up in the Debian -> Ubuntu diff
<lool> apw: You might want to mention the removal of ./debian/README.debian in the merge changelog entry
<persia> lool, Those are being generated by the clean: rule.  Yes, that's not ideal, but it's happening in Debian as well.
<apw> lool, will do and get back to you
<lool> persia: I understand, it's best if it's not committed to the UDD branch though as it makes the debdiff between Debian and Ubuntu harder to read
<lool> apw: Do you want me to upload this, or can you upload yourself?
<persia> Ah.  That makes sense, sure.
<apw> lool, i believe i can upload it, but i'll clean up the bits you mention first
<apw> lool, and get you to give it the once over
<lool> apw: Okay
<lool> mvo: Oy
<mvo> lool: Yo
<lool> mvo: do you think https://launchpadlibrarian.net/69856446/apt_0.7.25.3ubuntu7_0.7.25.3ubuntu9.3linaro2.diff.gz is applicable to lucid?
 * mvo looks
<lool> mvo: Sorry, that debdiff isn't too readable; https://launchpadlibrarian.net/69855638/apt_0.7.25.3ubuntu9.3linaro2.debdiff is more readable
<mvo> lool: yeah, that should be SRUable, we just need to create a proper testcase for the SRU description, thanks for extracting this
<lool> mvo: Basically I need this change for the linaro-image-tools testsuite to pass under lucid which is still a release we target (via our PPA); I can keep this APT debdiff in our PPA, but it requires updating from time to time
<lool> mvo: Could you comment on https://bugs.launchpad.net/linaro-image-tools/+bug/709895 stating the above?
<ubottu> Ubuntu bug 709895 in apt (Ubuntu Lucid) "Testsuite fails under lucid" [Medium,Triaged]
<lool> mvo: Is it ok if I use the linaro-image-tools testsuite as a test case for whether this works or not?
<lool> mvo: The symptom in our testsuite is that packages from a local repo don't get picked up because they are unsigned; with the fix, they get picked up again
<mvo> lool: ok, pointing to this is probably ok, do you want to do the SRU upload or should i?
<lool> mvo: I don't mind if you do it, you introduce less risk  :-)
<lool> mvo: But I'm happy to do it if it's too time consuming for you
<apw> lool, when you were comparing against debian, how were you doing that, via the bzr tags or some other way.  as adding the files back in identicly actually shows up as a remove and add of identicle contents
<lool> apw: just using "diff" and then | filterdiff -x '*/.bzr/*'
<lool> a bit brutal  :-)
<lool> you can also use bzr diff --old ../debian-branch
<apw> lool, the filterdiff makes most sense to me for this, cool thakns
<apw> lool do you have an offiicial branch for this that i should be merging into, or do we just rely on the importer
<lool> apw: I just used the UDD branch, so yeah, importer
<lool> apw: nowadays, best practice would be to put the UDD branch URL in Vcs-Bzr, but at the time of the last merge, I wasn't aware of that
<persia> Isn't there some advantage to merging into the UDD branch rather than using the importer, or is that only true for most atomic commits?
<lool> feel free to add it or not
<persia> s/most/more/
<lool> apw: Ah you were asking whether you should commit and upload, or just upload; I'd recommend commit and upload
<jaromil> update re: software-center - i've been including desktop files for software as in app-install-data-partner, plus .list and .eula in app-install/channels - YET i can't find a way to show an additional software channel in the left bar, below Canonical Partner
<jaromil> in software-center/backend/channels.py below line 400 it seems that there is a if...then chain
<jaromil> which includes only specific cases, yet i'm not fluent in py so i might be wrong
<apw> lool so push it over the importers branch lp:ubuntu/kexec-tools and then upload
<jaromil> i'll be grateful for any further pointer on this issue, again i'd really prefer leave the software-center code unmodified
<lool> apw: yup
<lool> apw: "bzr mark-uploaded" will tag it with version from debian/changelog, then bzr push (to push the tag), then upload the .changes you get with "bzr bd -S"
<hallyn> lool: hey - the binutils fix to let seabios build, did that get SRU'd for lucid?
<lool> hallyn: I don't think so, doko would tell you whether it's on his list
<lool> hallyn: but is lucid affected?
<lool> That seemed like a 2.21.x regression to me
<hallyn> lool: yes, i get the exact same failure building any seabios on lucid
<lool> doko: ^
<hallyn> (and maverick too, of course)
<lool> hallyn: it did get built under lucid though; odd
<doko> hmm, don't plan to do so
<lool> but then binutils might have been updated afterwards
<hallyn> hm
<SpamapS> pitti: would love to continue my SRU training some time this week if you have some time.
<lool> hallyn: which failure do you get?  the one about the regs or the one about the backward reloc?
<hallyn> backward reloc
<lool> definitely binutils then
<hallyn> i can go aheda and push to lucid-proposed and see what happens
<hallyn> had only tried local builds (with freshly updated lucid)
<lool> hallyn: you could try in a lucid PPA instead of lucid-proposed
<hallyn> allr ight
<apw> cjwatson, is there a simple way to tell bzr bd -S that you need the orig included, akin to -sa ?
<cjwatson> bzr bd -S -- -sa
<apw> cjwatson, ta muchly
<cjwatson> apw: also, bug 499684
<ubottu> Launchpad bug 499684 in bzr-builddeb "Interface to dpkg-buildpackage inconsistent and not well documented" [High,Triaged] https://launchpad.net/bugs/499684
<pitti> SpamapS: did you get my mail about the steps for proposed kernels?
<pitti> I need to run out for a bit, bbl
<SpamapS> pitti: no I see nothing about that. Have been having mail client issues though, so I may have accidentally deleted it.
<jaromil> re-launching, last try: anyone knowledgeable about software-center has little time to spare on it? or any pointers on better com channels to look in?
<pitti> SpamapS: bounced it to you again; Subject: Re: [kernel-SRU] Bottleneck to copying kernels to -proposed
<hallyn> lool: (fwiw, still waiting to build, i'll let you know when i have a result :)
<SpamapS> pitti: ok I found it I had it archived
<SpamapS> pitti: so we should take a step back. I don't even know how to move things from -proposed to -updates yet. We stopped at sru-accept
<pitti> SpamapS: ah, I thought I asked you to try sru-release
<pitti> as I wasn't sure how much privilege you need to do the call
<kees> pitti: hardy> thanks!
 * sebner waves at tseliot 
<tseliot> hi sebner :)
<sebner> tseliot: :) , do you remember what we talked about my touchpad problem at UDS (sry, didn't have time last week)
<tseliot> sebner: kind of... but I still think cnd might know the answer
<sebner> tseliot: then I'll talk to him! Thanks a lot! :)
<tseliot> np
<NCommander> cjwatson: thans
<sebner> persia: if you haven't read the mail yet I might want to add some lines :)
<persia> Heh, sure, go ahead.
<sebner> persia: :), you know, always when you've done something you notice that you forgot something ^^
<persia> If we were perfect, life would be boring
<sebner> persia: but nice and calm ;D
<mneptok> sebner: "Music is the space *between* the notes." - Debussy (emphasis mine)
<sebner> mneptok: I think I've heard something like that already :)
<hyperair> any archive admins here?
<hyperair> might i know why banshee and banshee-community-extensions were rejected from -proposed?
<persia> hyperair, For that, you don't need an archive-admin, you need to look at the affected bug.
<hyperair> eh whoops
<persia> It was rejected by someone on the SRU team.  In practice, most of these are archive-admins, but wearing a different hat.
<hyperair> oh okay
<Laney> hrm hrm
<Laney> I think there should be a general policy for upstream micro releases rather than requiring projects to go through the exception process
<maco> Laney: do you mean per-upload exception process? or do you mean like how we have a standing exception for kde's microreleases?
<persia> Laney: Some projects have aa different definition of "micro".
<Laney> persia: Right, hence guidelines
<Laney> maco: I mean upstreams should be able to do micro releases with the exception that they will be accepted as SRUs
<persia> Is the process that onerous?  I thought it was just "Document that upstream is sane.  Tell the tech board."
<persia> And most members of the SRU teams don't care about version numbers, as long as it solves known bugs, doesn't introduce features, is supportable, etc.
<Laney> I would like to encourage more projects to support our stable releases, and placing process hurdles in their way isn't a way to do that IMHO
 * maxb wonders if there is a sensible channel to ask questions about the use and debugging of sbuild?
<Laney> If the TB could distill their assessment criteria into a policy that'd be a win
<Laney> anyway I think I raised this at UDS and someone got an action item to improve the docs, so we'll see what comes out of that :-)
<cjwatson> Laney: that's part of what we were trying to do with https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html
<cjwatson> though, OK, that was new upstream versions rather than microversions
<persia> maxb: This one works, although if you're not targeting Ubuntu, #ubuntu-packaging is preferred (as some folk object to helping people with PPAs or derivatives)
<cjwatson> I agree we should do better for microversions too
<Take> Good evening
<Take> I'm having a hard time with preseed installation
<Take> I'd need a way to keep one of the existing partitions on the hard drive
<Take> With fully automated installation
<maxb> Hmm - well, I'm not targeting anything specific right now, just trying to get a general-purpose sbuild setup in place for future use. It actually works right now if I run sbuild as root, but as my normal user, I get a "Failed to change directory: Permission denied" error from dpkg-source -x
<micahg> maxb: are you in the sbuild groupo?
<micahg> *group
<maxb> I am
<micahg> did you reboot or run sg sbuild after install?
<maxb> Yes (id confirms that my current login session has me in the group)
<maxb> Hm
<maxb> Ah. I wonder if I'm actually in the sbuild group *inside* the chroot
<maxb> Hm. This error appears to be generated by schroot itself as it tries to chdir to the appropriate directory within the chroot
<soren> is there an easy way to get apt to output all of its configured sources? I'm trying to help someone debug a problem, and it's kind of awkward to explain that he has to collect the various sources.list.d files, but only the ones named *.list or whatnot.
<micahg> soren: apt-cache policy
<soren> micahg: Good point. I guess I could decipher that.
<hallyn> Daviey: hey, around?
<hallyn> lool: confusing - seabios built fine in my ppa for lucid, so i went ahead and pushed to lucid-proposed.  Good news, i guess, except for not liking inexplicably inconsistent results.
<Daviey> hallyn, o/
<hallyn> Daviey: hey, you have a local eucalyptus cluster right?
<hallyn> Daviey: were you looking at all into whether it uses 'phy' for libvirt .xmls?
<Daviey> hallyn, I haven't looked as yet
<Daviey> TBH, i was going to grep the source :)
<hallyn> Daviey: great, all the better, wasn't sure if you had the source available :)
<hallyn> Daviey: thanks
<Daviey> hallyn, not today, mind
<hallyn> Daviey: k
<hallyn> Daviey: if you get bored tonight, and wanted to look over https://bugs.launchpad.net/ubuntu/+bug/787220
<ubottu> Ubuntu bug 787220 in Ubuntu "[needs-packaging] celt051" [Undecided,New]
<hallyn> i could see discussion over that one going badly
 * hallyn wonders whether to ask robbiew to take a look
<persia> hallyn, Is it that hard to port spice?  new oldlibs are acceptable, but usually cause pain later.
<Daviey> hallyn, oh joy
<Daviey> hallyn, What is the concern?
<hallyn> persia: what do you mean by port spice?
<hallyn> persia: oh sorry, i thought you siad port celt
<hallyn> persia: i'ts not htat hard, i think ppa:serge-hallyn/spice in fact is still the one using celt0.7.1
<hallyn> persia: but people pointed out it then won't play nice with redhat
<persia> hallyn, Won't play nice in terms of binary compatibility, or won't play nice in terms of interoperability?
<hallyn> for some additional churn we could try and negotiate that to make it work, but the spice people claim they will never update to a newer celt until a 1.0.0 comes out
<hallyn> interoperability
<hallyn> well, and of course we'd still need celt051 to talk to a spice server
<persia> Oh, that's sufficient justification.  Please make that clear in the bug report.
<micahg> ugh, IIRC, there's a Debian bug on this
<persia> And package it in section "oldlibs" so that nobody else decides it's a nifty idea to start using it for a new project.
<zul> hallyn: oh joy
<persia> Debian Bug 603699 ?
<ubottu> Debian bug 603699 in wnpp "ITP: celt051 -- The CELT codec v0.5.1" [Wishlist,Open] http://bugs.debian.org/603699
<micahg> persia: yeah, I think that's it
<hallyn> persia: ok, thanks, will do
#ubuntu-devel 2011-05-24
<lamont> who is a good target for pestering about invoke-rc.d and the equivalent upstart stuff?
<zul> SpamapS probably
<broder> or slangasek, if you're asking about policy stuff around that
<SpamapS> lamont: What did you want to whine^H^H^H^H^Htalk about regarding invoke-rc.d?
<lamont> SpamapS: puppet uses it to tell what runstate we're in, and well, when puppet starts during system start up, it goes 'zomg dunno', and the dryrun output looks fugly.
<lamont> I'd like something cleaner than: @reboot root echo service puppet restart | at now+2min
<SpamapS> lamont: is puppet starting as a sysv init or an upstart job?
<lamont> sysv
<SpamapS> lamont: if it needs to run before anything else ever.. it needs to be converted to an upstart job most likely.
<SpamapS> lamont: the alternative is starting it manually in an upstart task at the appropriate time
<SpamapS> lamont: I would think puppet should run very late in the boot tho
<SpamapS> like, almost last
<lamont> well, actually, i think the real right answer is not to have puppet cache the startup answer FOREVER
<lamont> since, you know, init level could change
<SpamapS> so it checks the output of the 'runlevel' command ?
<SpamapS> I'm not really sure I understand the problem actually.. :-P
<lamont> invoke-rc.d --query
<lamont> and doesn't like 105, which it then caches forever
<lamont> which I believe to be a bug.
<lamont> so nm... off to file a bug against puppet
<SpamapS> Yeah.. I see now.. 105 is "don't ask me, I just work here"
<SpamapS> They should probably check for an upstart job if 105 is returned.
<lamont> SpamapS: and more to the point "we're in startup, so I really don't know"
<lamont> the job in question isn't an upstart job
<SpamapS> right yeah that sounds like a bug in the way they're handling the uncertainty
<lamont> mind you, ISTR that adding support for upstart was on the roadmap for puppet/oneiric
<lamont> which will be nice
<lamont> as long as upstart doesn't make changes to make that possible
<SpamapS> There's talk of having a more definitive "disable" capability added
<ScottK> Is that the burn with fire option?
<pitti> Good morning
<LaserJock> morning pitti
<ScottK> Whoah.  It's LaserJock.
<ScottK> Hello LaserJock
<pitti> hey LaserJock, how are you?
<LaserJock> I'm doing OK
<ajmitch> morning pitti
<LaserJock> a bit jobless atm (hence being on IRC) but otherwise OK :-)
 * StevenK rubs eyes, looks again
<LaserJock> I know, I know, it's been a while
<ajmitch> no excuses
<StevenK> Haha
<LaserJock> I got a PhD, move to Boston, taught a couple classes at my alma mater, and am now ... here
<hmchinh1986> http://paste.ubuntu.com/612150/ ->ireally need this ! please, help me
<broder> !support | hmchinh1986
<ubottu> hmchinh1986: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<hmchinh1986> ok
<jerry_l> hello room i have to go to bed. sorry...
<StevenK> pitti: Can you think of a library package off-hand that is in main but has some binary packages in universe?
<diwic> StevenK, IIRC for jackd the library is in main but the daemon in universe
<StevenK> diwic: I thought of a victim package already, but thanks
<didrocks> good morning
<diwic> good morning didrocks
<didrocks> hey diwic
<dholbach> good morning
<didrocks> hey dholbach
<dholbach> hi didrocks
<didrocks> the new dbus depends on netbase (>= 4.45ubuntu3), but the one uploaded yesterday was 4.45ubuntu2 ?
<smb> @pilot on
<udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<smb> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smb
<pitti> StevenK: libnotify as well, if you want something tiny; libnotify-bin is in universe
<pitti> SpamapS: FYI, fixing dbus netbase dependency to a version that actually exists, to make dbus installable again
<Laney> is it known that cdbs is uninstallable on ppc?
<cdbs> Laney: Half the archive is not installable on ppc :( Are you talking about Natty or Oneiric?
<Laney> oneiric
<Laney> cdbs is hardly 'half the archive' though â it's a relatively high-up package
<cjwatson> it's probably the dbus breakage, which powerpc is an archive cycle behind on
<Laney>  cdbs : Depends: dh-translations but it is not going to be installed
<cdbs> no idea, I'm not a big archive evaluator, especially not on [ shadeslayer] [ vrodic    ]
<cdbs> oops
<Laney> again I wish for BD-uninst in launchpad ;-)
<cdbs> blame the new gnome-control-center for pasting things randomly
<pitti> Laney: yeah, this really should be considered as depwait
<infinity> Y'know, I had half-finished an uninst->dep-wait parser years ago...
<Laney> pitti: I filed bug 5277245 for that some time ago
<ubottu> Error: Launchpad bug 5277245 could not be found
<Laney> er
<cjwatson> hmm, not dbus
<Laney> bug 5272453
<ubottu> Error: Launchpad bug 5272453 could not be found
<Laney> bug 527245
<infinity> Someone should talk me into finishing it.
<ubottu> Launchpad bug 527245 in Launchpad itself "Implement a BD-Uninstallable build state" [Wishlist,Triaged] https://launchpad.net/bugs/527245
<Laney> argh!
<cjwatson> Package liblwp-protocol-https-perl is not available, but is referred to by another package.
<pitti> hm, and everything FTBFSes on armel :/
<pitti> I've seen a couple of ld segfaults
<infinity> Laney: That build state shouldn't exist, the correct solution is to drill down for the right dep-wait.
<cjwatson> I think I just NEWed that
<pitti> including the dbus fix
<cjwatson> yeah, it's accepted, next publisher cycle should fix it
<Laney> it's more complicated than dep-wait
<infinity> Laney: Not in this case.
<cjwatson> this case should be dep-wait: liblwp-protocol-https-perl
<cjwatson> sometimes discovering the correct dep-wait is AI-complete though
<infinity> Laney: If you literall mean "failed installation", then yes, you can't always intelligently dep-wait on, say, broken postinsts.
<infinity> Laney: But "apt can't even being to install" (which is the case here) is always a dep-wait.
<infinity> Laney: Just not always an immediately obvious one.
<shadeslayer> cdbs: lol
<cjwatson> oh, hmm, liblwp-protocol-https-perl needs an emergency MIR
<cjwatson> in fact that's a split-out, so I'll promote it
<cdbs> shadeslayer: Sorry for the ping, its because the new GNOME3 stack doesn't play well with Unity and can behave really weirdly at times
<Laney> can you dep-wait on multiple packages?
 * cjwatson does the override-in-accepted-queue trick
<Laney> You can call it the same thing if you'd like, but I suspect you'll end up implementing a rather similar solution to that which Debian did :-0
<Laney> :-)
<infinity> Laney: Debian's solution re-checks installability, and is fairly opaque to the end user.  But it's the same concept, yes.
<Laney> it uses an external tool to determine the same information, indeed
<cjwatson> what does it do, edos-debcheck?
<infinity> Laney: (Debian does dep-wait checks before pushing to needs-build, our checks happen at a different time, so the solution is different regardless)
<Laney> cjwatson: yeah
<infinity> cjwatson: Aye.
<shadeslayer> cdbs: yeah no problem ;)
<infinity> Laney: Either way, I agree that the functionality's been missing for a while, it just failed Round Tuit tests, I guess.  And the only person who cared stopped working on lp-buildd for a year and a half...
<infinity> Laney: (The only person who seemed to care about this feature, that is, not lp-buildd entirely)
<tjaalton> huh, cron update broke my personal crontab
<tjaalton> nah, not a package update, but something did corrupt it
<persia> infinity, So, what is a good way to generate a solution.  Cookies?
<infinity> persia: Peanut butter cookies!
<persia> Oooh.  That makes it trickier.
<infinity> You'll sort it out.  You're a clever man.
<mdz> pitti, have you looked into this ffmpeg/libav issue on the t-b list?
<mdz> (April)
<pitti> mdz: we quickly discussed it in the TB meeting
<mdz> pitti, is it safe to let the mails be archived, or do I need to pay attention to it?
<pitti> mdz: the outcome was that we really need to hear both sides of the story, someone had an action item to follow up with siretart
<mdz> ,
<mdz> ok
<pitti> sabdfl: do you happen to have the minutes from that meeting somewhere? we should add them to https://wiki.ubuntu.com/TechnicalBoard/TeamReports/11/May
<sabdfl> pitti: i definitely edited it
<sabdfl> did i forget to save it?
<sabdfl> fml
<pitti> sabdfl: used editmoin by any chance? then they might still be in ~/.moin_lastedit
 * pitti was rescued more than once by that
<sabdfl> no, just in-browser
<pitti> chrisccoulson_: please add full automatic etherpad-like revision control to firefox input fields :)
<chrisccoulson_> heh :)
<arand> pitti: "Lazarus" does that partly ;)
<apw> cjwatson, i am about to do the MIR for the linux-lts-backports-natty backport kernel.  we don't seem to have any written proceedures for this, and its a little  bit of an odd case as its not in universe currently, should i be uploading it to lucid -proposed in advance ?
<cjwatson> meh, I don't think the backport kernel bits need MIRs
<infinity> ^
<cjwatson> technically yes it's a new source package in main, but we've already had source packages with the same purpose in main before
<cjwatson> and basically the same set of code
<infinity> As long as there's a sane rationale for it existing at all, we already trust upstream and downstream maintainers.
<apw> cjwatson, ok so just go ahead and upload it to lucid -proposed and get with your to get it sorted out ?
<cjwatson> well, not me, but yes
<cjwatson> linux-lts-backport-maverick was just uploaded to lucid-proposed
<cjwatson> and it clearly can't go to a development release first
<apw> cjwatson, yeah thats the previous one, so i'll just get it uploaded :)
<cjwatson> except in the sense that the same code is already in the real kernel in newer releases
<apw> right its identicle in code terms, packaging is slightly neutered to produce less architectures otherwise identicle
<persia> infinity, Just to confirm, do the numbers 616, 4640, 52 and 6716 seem likely to be useful?
<infinity> persia: I'm not a cookie expert, but I suspect you might be barking up the wrong tree.
<debfx> cjwatson: do you know why translatoid isn't auto-synced?
<cjwatson> sync-blacklisted: translatoid # james_w: Older version in Debian causing issue for autosyncer, drop this entry later.
<cjwatson> I can retry it
<cjwatson> debfx: seems fine, synced now
<debfx> thanks
<doko> seb128, pitti: could you have a look at component-mismatches? tracker xmldiff lightdm
<seb128> doko, do we care that early in the cycle?
<doko> seb128: yes, I care about buildability
<seb128> doko, ok so you are welcome to file mirs for those ;-)
<seb128> rodrigo is working on dropping the tracker one
<seb128> xmldiff needs investigation
<doko> ScottK: muon tries to pull in libqzeitgeist
<seb128> lightdm needs a mir if it didn't get one yet
<doko> ok, thanks
<ScottK> doko: I'll ask someone to look into that.
<ScottK> I imagine you'll see a MIR shortly since adding that feature was entirely not accidental.
<didrocks> seb128: there is one filed by robert
<seb128> doko, ^ what is the issue with lightdm? there is a mir waiting for it
<seb128> didrocks, thanks
<doko> seb128: ahh, didn't update the page
<seb128> ok
<cjwatson> seb128: if we don't care early in the cycle, we end up panicking latere
<cjwatson> *later
<seb128> cjwatson, well there is some desktop ones we know about but we are just busy and didn't manage to get to those yet
<cjwatson> seb128: sure, nobody expects it to be at zero; all I'm asking is that we don't blow off people when they ask about it
<seb128> cjwatson, ok, fair enough, the question was rather to know if we should drop everything we are doing and prioritize those or if they can wait a few days
<cjwatson> we seem to have this conversation every time somebody from the archive team asks about something :)
<cjwatson> we'll tell you if it's drop-everything urgent ...
<sabdfl> pitti: i found a copy of the minutes i had
<sabdfl> can i just save it to .../11/May ?
<seb128> cjwatson, ok, I never if people ping to raise a bit the priority or just as an informational hint when they do ping about such things ;-)
<cjwatson> well, I would expect that it's generally meant to raise the priority above background-noise, since there's an awful lot of the latter
<seb128> well in any case we might need a better way to list those as "block <....>" where .... can be CD build or other thing because IRC pings are not really the best way to deal with such notices
<seb128> especially than often it doesn't reach the right people
<seb128> like xmldiff is coming from a sync of debian, I'm fine having a look when I will have time but other people might be less busy or have a better clue about it
<sabdfl> pitti, mdz: https://wiki.ubuntu.com/TechnicalBoard/TeamReports/11/May
<mdz> sabdfl, thanks
<shadeslayer> doko: did you promote qt-gstreamer as well?
<shadeslayer> or do we fix the said issues first?
<shadeslayer> thanks!
<ScottK> doko: If you're still on component mismatches, please promote kdegames-card-data-extra binary.  It's a split of an existing Main package that inadvertently dropped to Universe in Natty.  I've just seeded it so it'll show up on the next component mismatches run if not promoted.
<pitti> doko: robert is writing a MIR for lightdm, but that doesn't affect buildability
<pitti> it was just added to the seeds
<pitti> xmldiff seems harmless, we can do a MIR
<pitti> sabdfl: thanks
<seb128> pitti, the mir is already written
<pitti> seb128: IMHO we should fix brasero to not pull in tracker, OK for you?
<seb128> pitti, rodrigo is already on it, we discussed that on #ubuntu-desktop early today
<pitti> ah, cheers
<doko> seb128, pitti: is bacula desktop stuff? tries to pull in postgresql-8.4
<seb128> no it's server
<pitti> probably enough to bump the b-dep to -9.0
<doko> Daviey: bacula ^^^
<pitti> Daviey: ^
<doko> faster ;)
 * Daviey looks
<Daviey> doko, it's 'both' :)
<doko> cool, aliasing 'both' to 'not me' :)
<Daviey> bah.. it's the foundations that ties desktop to server :)
<doko> ScottK: done
<ScottK> doko: Thanks.
<ogasawara> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara, smb
<stgraber> slangasek: I posted the initial review for libtirpc in bug 781516 and I'm now looking at rpcbind. For libtirpc it seems like I could just re-upload the package without the build-dep on libgss-dev as it doesn't seem to be used at all, though if you know that package better than I do, I'd appreciate a second opinion.
<ubottu> Launchpad bug 781516 in rpcbind (Ubuntu Oneiric) "[MIR] libtirpc, rpcbind" [High,Incomplete] https://launchpad.net/bugs/781516
<ScottK> pitti or SpamapS: (I assume) one of you copied qt4-x11 from natty-proposed to natty-updates, but didn't forward copy to oneiric.  I'd appreciate it if one of you would do this to save an upload/multi-day build.
<cjwatson> I could just do another bulk copy run
<ScottK> That would work for m.
<ScottK> m/me
<cjwatson> and it's just qt4-x11 at the moment anyway
<cjwatson> done
<ScottK> Thanks.
<apw> jhunt, who looks after udev ?
<soren> apw: You. Didn't you get the memo?
<apw> pitti, i think you sync'd udev recently?  am getting reports that a full oneiric install is a 25% chance of booting, downgrading udev sorts it ... no real details other than that yet
<pitti> apw: not synced, updated, but yes
<pitti> apw: do you have a machine which reproduces it? works fine here (oneiric du jour, but I never had such a problem any time in oneoric)
<pitti> oneiric .. one eye rick .. whatever
<apw> pitti, i've asked them to get it all in a bug and i'll get the number i
<apw> when i have it ... nothing here with oeniric userspace as yet
<stgraber> apw, pitti: I "think" I have this issue in one of my VMs here. Gets stuck at boot time almost 50% of the time, rebooting eventually makes it start.
<stgraber> it's a simple server VM with just isc-dhcp-server, radvd and ssh installed, so nothing fancy
<apw> stgraber, yep, looks like a broked udev, with udev barfing about Address already in use
<apw> pitti, i'll have to get a vm updated to oneiric then
<apw> sig
<apw> sigh
<pitti> apw: FTR, there are several folks in #u-desktop running oneiric as well, haven't heard about problems from anyone; might that be kvm specific somehow?
<apw> pitti, checking with my reporter ... possible indeed
<apw> pitti, ok this one is a real machine ... will see what i can find out once we have a bug
<hallyn> kirkland: not sure if you get at all into this kind of maintenance for byobu, but one thing that bugs me is that in escape mode, i can't do things like 'f' - it just brings me back to insert mode.  Have you considered fixing that?
<kirkland> hallyn: hmm, i'm not sure I understand the problem, but I'd like to ... can we take this to #ubuntu-server ?
<smoser> doko, do you know how i can see a java console (in firefox) with openjdk ?
<hallyn> k
<dpm> hi pitti. Could you point me to that wiki page where the syntax of work items in a blueprint's whiteboard is explained?
<pitti> dpm: https://wiki.ubuntu.com/WorkItemsHowto#Defining%20work%20items
<dpm> pitti, great, thanks
<geser> doko: do we miss anything important with the last gcc-defaults upload being "Failed to upload"? (https://launchpadlibrarian.net/71061220/upload_2523174_log.txt)
<SpamapS> pitti: huh? did I typo the version?
<pitti> SpamapS: yes, you said >= ubuntu3, but netbase is at ubuntu2
<SpamapS> pitti: oh no the real problem is that I didn't upload netbase 4.45ubuntu3!
<SpamapS> pitti: 4.45ubuntu2 is bad
<pitti> SpamapS: hm, the changelog of https://launchpad.net/ubuntu/+source/netbase/4.45ubuntu2 seemed to add what you wanted
<SpamapS> pitti: but --wait is a non-existant parameter
<SpamapS> pitti: I forgot to debuild -S again and upload.. the .deb I was using to test was 4.45ubuntu3
<pitti> SpamapS: ok, sorry about that; then I figure you need to revert my dbus change as well
<SpamapS> pitti: I'll take care of it
<SpamapS> ahh oops.. I accidentally tried to upload 4.45ubuntu3 to natty.
<SpamapS> thats what I get for not going to inbox 0 every day. ;)
 * SpamapS really wishes the upload process would tell him that and not an email 5 minutes later
<slangasek> stgraber: hmm, I don't know why libtirpc would need libgss-dev, but I also can't categorically say that it's spurious... I don't know what's going on there
<ScottK> dholbach: Where can I find these open backports request statistics?
<dholbach> ScottK, on my local hard-drive - I'll publish in a bit
<ScottK> dholbach: OK.  I was going by the "DONE" status in the work item.
<dholbach> I'll update the blueprint with an url in a bit
<ScottK> I guess the work item was for create.
<ScottK> Sharing would be another one.
<ScottK> ;-)
<ScottK> Thanks.
<cjwatson> [5~/wg 159
<cjwatson> bah
<doko> smoser: I think the icedtea plugin never had one
<doko> geser: know, currently doesn't hurt
<smoser> so how should one go about seeing java console output?
<smoser> is there anything better than running firefox from a console and getting the output there?
<ScottK> doko: I'm promised the libqzeitgeist MIR will be filed 'today'.  Not sure how that relates to today where you and I are, but soon in any case.
<dholbach> ScottK, published the url - the reason they look boring and have no lines is because there's just one data point right now :)
<ScottK> Right.  Thanks.
 * pitti chuckles at SpamapS' dbus changelog -- I declare defeat!
<pitti> SpamapS: now you are TIL again, I'm not unhappy about this ;)
<tkamppeter> pitti, ping
<tkamppeter> pitti, I have reported a CUPS SRU bug, bug 787635. The special thing is that I have discovered the problem and I have fixed it and posted the SRU. How does the verification work then. I have naturally tested the fix and it works for me.
<ubottu> Launchpad bug 787635 in cups (Ubuntu Natty) "Natty SRU: pstopdf not working correctly with non-default paper sizes" [Medium,Fix committed] https://launchpad.net/bugs/787635
<SpamapS> tkamppeter: first it should be fixed in Oneiric actually.
<SpamapS> tkamppeter: once it is in Oneiric, the fixed package should be available in natty-proposed for 7 days at least, and at least one user needs to "verify" the package, then it should move to natty-updates
<ScottK> SpamapS: Looks like a fun FTBFS on armel for you to go with your witty dbus repartee.
<SpamapS> ScottK: yeah I saw the earlier build failure too. :-/
<SpamapS> collect2: ld terminated with signal 11 [Segmentation fault]
<SpamapS> Toolchain bug?
<stgraber> slangasek: as building with and without libgss-dev gives me an identical resulting lib, I'd be tempted to just drop the build-dep. I'll poke the Debian maintainer see if he knows why the build-dep is there.
<infinity> SpamapS: ld should never segv, so yes.  But you may be able to work around it fiddling with flags.
<infinity> SpamapS: (Which can be handy in isolating the bug too)
<slangasek> stgraber: cool, thanks
<stgraber> slangasek: the Debian maintainer is planning on uploading a new upstream release and will drop the build-dep in that upload. I guess we can just wait for it then.
<slangasek> cool
<SpamapS> infinity: I suppose first tep would be getting access to armel hardware.. :-P
<infinity> SpamapS: qemu, go?
<SpamapS> I have zero experience w/ this
<SpamapS> if there's a HOWTO tho.. I'd be interested in playing
<slangasek> SpamapS: https://wiki.linaro.org/Resources/HowTo/Qemu-beagleboard
<slangasek> that's for full-system emulation
<slangasek> alternatively, you can do a qemu chroot
<slangasek> not sure if we have a howto for that somewhere
<SpamapS> slangasek: ty!
<slangasek> SpamapS: if you just want syscall emulation on a chroot, you can install qemu-user-static and use /usr/sbin/qemu-debootstrap to set up a chroot
<slangasek> (will run faster than whole-machine emulation)
<stgraber> SpamapS: I was planning on setting up my pandaboard with LXC a bit later today so I can easily run multiple Oneiric ARM systems for testing. I can probably give you access to one of them once it's ready ;)
<infinity> But won't catch if your ld segv is actually a kernel bug.
<infinity> (But it probably isn't)
<SpamapS> slangasek: I think given the segfault I want full machine
<infinity> SpamapS: Generally not, unless you really do suspect the kernel.
<infinity> SpamapS: And then, you need to run against the same kernel the buildds are using...
<slangasek> SpamapS: what infinity said; 9 times out of 10 you'll be able to reproduce with just syscall emulation, which is faster *and* easier to configure, so you might as well try it first
<SpamapS> Ahh ok
<infinity> SpamapS: Realistically, if the kernel *is* breaking ld, you'd be seeing it across many/most builds.  If you're just seeing it in a specific case, it's probably binutils.
<infinity> SpamapS: (And it's binutils being tickled by a very specific grumpy output from gcc)
<infinity> *handwavy*
<RoAkSoAx> kirkland: ping, did you find the bug against gnome-settings-daemon?
<jhunt> SpamapS: I'm seeing armel toolchain weirdness too (that upstart FTBFS plus nih)
<RoAkSoAx> barry: ping
<barry> RoAkSoAx: pong
<RoAkSoAx> barry: I have a qcuik question about UDD that's driving me crazy :)!! Should be submit branches with patches applied or not?
<RoAkSoAx> barry: cause when doing some merges I encounter the situation that there's diff's in .pc/what-ever-patch.patch
<barry> RoAkSoAx: you're not alone about that one ;)  it's somewhat of an open question, but current thinking is that your branch will both have the debian/patches file(s) *and* the patches applied in tree
<barry> RoAkSoAx: thinking goes:
<barry> when you branch, you have the patches applied, so you'll just make your changes, do a bit of magic to generate the d/p file, commit and push
<barry> RoAkSoAx: yes, that's one large suck about the process.  i think the best thing to do is to revert the .pc directory before you push
<kees> cjwatson: how do I check to see if a given LP user has package upload rights? where is that visible?
<RoAkSoAx> barry: right, so I';d revert the .pc directory and leave the patches unapplied?
<maco> kees: cant do it in lp itself
<maco> kees: pull down ubuntu-archive-tools from lp
<barry> RoAkSoAx: you can certainly do that.  when i said "revert the .pc" directory, i mean 'bzr revert .pc' so that could lead to a patches applied push
<kees> maco: I thought not. But I don't know where to look. Ah-ha.
<maco> kees: and run edit_acl.py
<stgraber> kees: bzr+ssh://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/
<barry> RoAkSoAx: just realize that this is a very uncomfortable place you're in, and something the bzr guys have a high motivation to fix
<RoAkSoAx> barry: but would it hurt to  push with patches un-applied?
<barry> RoAkSoAx: no, i don't think it would because a reviewer is mostly going to be looking at the debian/ directory anyway
<maco> ./edit_acl.py query -p lpusername
<maco> kees: ^
<barry> RoAkSoAx: and they should be able to 'quilt push -a' for example if they wanted to see the effects in tree
<kees> maco: oh, it can be done. you meant LP web, not LP API?
<barry> RoAkSoAx: so i think you're okay either way
<maco> kees: right
<maco> kees: sorry, this is the part of my brain that likes guis talking :)
<RoAkSoAx> barry: right, cool! Cause I've run into situations that I unpack the source and end up with patches applied with nothing under .pc, however, when quilt push -a, it fails to apply patches because they are already applied
<RoAkSoAx> so I have to do some magic to get that fixed
<barry> RoAkSoAx: yep.  when you 'bzr branch ubuntu:foo' you always get patches applied
<barry> RoAkSoAx: just as an example, i've rewritten that section in the udd docs like three times already ;)
<RoAkSoAx> barry: cool I think I'll just start pushing without patches applied cause at the end generates issues when extracting the source with dpkg
<RoAkSoAx> barry: hjehe yeah grey area :)
<RoAkSoAx> barry: but anyways, Thanks for the input I now have a clearer view
<barry> RoAkSoAx: please do feel free to email the udd list and/or submit bugs for any problems or experience you have.  i know the bzr guys would love to get more data points :)
<RoAkSoAx> barry: hehe will do ;) thanks!
<barry> np!
<kees> maco: who was supposed to put brad-figg in ~ubuntu-kernel-uploaders ?
<maco> kees: i dont know but i guess i could do it now
<maco> ok. did.
<kees> maco: thanks!
<maco> np
<stgraber> ogra_: you may be interested by bug 787749
<ubottu> Launchpad bug 787749 in linux-ti-omap4 (Ubuntu) "Missing configuration for LXC containers on omap4" [Undecided,New] https://launchpad.net/bugs/787749
<seb128> slangasek, you broke gdk-pixbuf in oneiric! ;-)
<slangasek> seb128: I won't claim to be surprised ;), but I don't know what's broken - pointer?
<seb128> slangasek, IRC reports but
<seb128> https://launchpadlibrarian.net/71185137/gdk-pixbuf_2.23.3-0ubuntu1_2.23.3-0ubuntu2.diff.gz
<seb128> +            /usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \
<seb128> +                /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/2.10.0/loaders/*.so \
<seb128> slangasek, the gdk-pixbuf-2.0/gdk-pixbuf-query-loaders dir is false it's in #MULTIARCH# as well
<seb128> slangasek, that broke today with the librsvg update, the trigger empty the cache and no icon can be loaded
<seb128> slangasek, you forgot to push your update to the vcs also btw
<seb128> slangasek, do you want to fix it or should I add that to my list for tomorrow?
<slangasek> seb128: oh, indeed; I see that I had the right path in postinst configure, but wrong for postinst trigger, doh
<seb128> (it's 10pm and I was about to go but I can fix that tomorrow when I start my day)
<slangasek> seb128: I'll try to get to it today but no promises
<seb128> slangasek, ok, thanks
<seb128> well seems easy enough, let see if I can get that done now before going
<slangasek> Vcs> sorry; further evidence that this some-UDD-some-not world is error prone :/
<seb128> slangasek, do you have the vcs revision and forgot to push or should I fix that?
<seb128> slangasek, debcheckout is your friend ;-)
<slangasek> seb128: I have it all on the wrong Vcs (the UDD branch), you should probably go ahead and fix it
<seb128> (we just sort of decided today in the desktop team meeting to stay away from UDD for another cycle)
<seb128> slangasek, ok
<slangasek> eh, no, debcheckout isn't my friend, it doesn't have a sensible fallback to UDD
<brendand> i have a problem with logging into unity, every few times i login the desktop doesn't appear
<brendand> anyone have any thoughts on which logs i should be checking to see what's hanging?
<psusi> brendand: .xsession-errors
<brendand> psusi - in?
<charlie-tca> ~/.xsession-errors
<brendand> a bunch of nm related warnings at the end
<brendand> compiz (core) - Error: Plugin 'text' not loaded.
<brendand> ?
<brendand> not sure if that should do any harm
<charlie-tca> psusi knows more than I do about that stuff
<brendand> this happens seemingly randomly
<brendand> and so far has never happened when trying to login to classic desktop
<ogasawara> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smb
<slangasek> SpamapS: OOI, why is it dbus that needs to 'stop on deconfiguring-networking', rather than network-manager?
<SpamapS> slangasek: because network-manager also needs to 'stop on stopping dbus'
<SpamapS> slangasek: in order to express it differently, we have to jump through similar hoops to the portmap issues...
<SpamapS> slangasek: I don't like it.. but until we have 'while' ... the hacks are going to pile up. :(
<slangasek> SpamapS: oh, because n-m shutdown would race dbus shutdown, heh
<slangasek> got it
<SpamapS> As proud as I am of wait-for-state .. I'm hoping to avoid actually using it again. :)
<slangasek> SpamapS: can you document in dbus.conf that this is a workaround, so someone like me doesn't go "fixing" it later? :)
<seb128> slangasek, ok, gdk-pixbuf vcs sorted and new version uploaded to fix the path issue
<slangasek> seb128: you rock :)
<seb128> ;-)
<SpamapS> slangasek: sure. Would pushing a change into lp:ubuntu/dbus w/o an upload be a good way to do that?
<slangasek> SpamapS: should work
<SpamapS> slangasek: its still not clear to me if that is a good way to stage low priority changes.
<slangasek> it's a method I endorse :)
<seb128> 'night
<slangasek> seb128: 'night!
<cpatrick008> i was wondering when the daily and daily-live isos are coming out because they are not out yet and the natty ones came two weeks eairler in the cycle
<broder> cpatrick008: there's some major re-working of the cd build process happening this cycle
<broder> and i think iso builds have been turned off until that's finished
<cpatrick008> ok thanks
<cjwatson> broder: actually not as such, I just haven't really got round to it
<cjwatson> plan is to do it tomorrow morning, assuming the desktop's still installable
<broder> oh, ok. /me shrugs
<cjwatson> mostly didn't get round to it because initially it was thoroughly blocked by various transitions, and I got distracted into running those
<stgraber> I did a desktop netinstall today and it installed. It doesn't "work" but it installs ;)
#ubuntu-devel 2011-05-25
<broder> kees: is liberal application of polkit not sufficient for solving the apport issue?
<kees> broder: dunno, frankly. pkexec is kinda crazy
<broder> (it seems like polkit is less of an awful hack than gksu and friends)
<broder> hmm...i'd probably have a dbus backend so you could group all of the "gather some file" actions under a single polkit permission
<Keybuk> isn't polkit going away?
<Keybuk> I can't remember
<broder> it is?
<broder> that's news to me, but i could be underinformed
<micahg> the only think I heard about it going away was being folded into systemd
<ScottK> SpamapS: re pushing low pri changes to a UDD branch.  I hope you noticed slangasek said he endorses the practice.  He didn't claim it was a good idea.
<slangasek> heh
<james_w> consolekit is going away
<slangasek> well, no
<slangasek> that's yet to be seen
<james_w> ok, some people want it to go away :-)
<slangasek> it's not going to be used in Fedora, but Ubuntu isn't going to switch to systemd any time soon
<broder> that makes a bit more sense, at least
<broder> consolekit always seemed like a bit of a solution looking for a grand vision that wasn't materializing
<ScottK> Someone wanted me to install webkit on a server the other day for some kind of PDF generation tool.  I suggested the internet facing box wasn't the place.  These kits are definitely out of control.
<broder> i'm still waiting for KitKit :-P
<Keybuk> KitKit does exist
<broder> ...wait, seriously?
<micahg> ScottK: wkhtml2pdf?
<ScottK> You've got to have one kit to rule them all.
<Keybuk> it was what Lennart was going to write to replace libnih
<Keybuk> but he seems to just copy&paste
<SpamapS> kitkit was created by the Department of Redundancy Dept.
<ScottK> micahg: Sounds right.
<ScottK> micahg: Have you used it?
<Keybuk> ScottK: to be fair, if I was rendering content, I would probably use webkit for layout too
<ScottK> Keybuk: Sure.  I just don't like having such a steaming heap of security vulnerabilities even installed on an internet facing server.
<micahg> ScottK: yeah, I actually created a wrapper that used it to rip some web pages to PDF, it seems to be pretty good (wouldn't put it on a web facing server though :))
<Keybuk> ScottK: I would not describe WebKit as such
<slangasek> cjwatson: is bug #425979 tractable?
<ubottu> Launchpad bug 425979 in grub2 (Ubuntu) "Holding shift fails to display grub2 menu" [Undecided,Confirmed] https://launchpad.net/bugs/425979
<ScottK> Keybuk: It's entirely possible I am being unfair.
<Keybuk> it's had roughly the same number of CVEs in recent history as TeX, for example
<ScottK> In this particular case there wasn't a need to do it on that box.  It was just simpler.  Fortunately it was an ancient BSD version and there were issues.
<kees> Keybuk: did you just imply that webkit has as many CVEs as TeX?
 * kees can't tell if that's intentional trolling or not :) (270 vs 19)
<Keybuk> kees: in recent history ;)
<cjwatson> slangasek: I think I mostly got agreement last-but-one UDS that if we could get the post-GRUB experience really smooth then we could reintroduce a short delay and drop the hold-shift requirement
 * ScottK just noticed http://blogs.technet.com/b/security/archive/2010/03/09/ubuntu-cve-tracker.aspx
<cjwatson> slangasek: but didn't quite finish that off
<Keybuk> kees: though webkit is cross-platform, and I was just looking at LWN
<ScottK> Kind of interesting in a not really, but they're talking about us, way.
<cjwatson> slangasek: I doubt it's tractable otherwise
<slangasek> cjwatson: ok
<cjwatson> slangasek: (well, aside from UEFI systems, where we seem to be failing to notice that modifier detection isn't currently available judging from one bug I've seen, but I doubt that's what's at issue here)
<slangasek> heh
<kees> Keybuk: in recent history. 5 months. webkit: 64. TeX: 1
<Keybuk> kees: clearly webkit is better maintained ;-)
<kees> ScottK: yeah, I had a chat with Jeff Jones when he first published that
<kees> Keybuk: that's one way to look at it ;)
<andersk> seb128: librsvg2-common.postinst still uses the wrong path in 2.34.0-0ubuntu3, so things break if librsvg2-common was configured more recently than libgdk-pixbuf2.0-0.
<slangasek> so I wonder why binfmt-misc + suid seems to fail
<TheMuso> I just wish the underlying parts of the desktop infrastructure would stop changing. i.e we have consolekit, if it has flaws, lets improve it. If we have policykit, lets just improve it etc.
<andersk> slangasek: Did you use the 'C' flag?  See bug 519228.
<ubottu> Launchpad bug 519228 in binfmt-support (Ubuntu) "Support for C flag" [Undecided,Fix released] https://launchpad.net/bugs/519228
<slangasek> andersk: I used the qemu flag
<micahg> andersk: yeah, I just asked in -desktop if anyone wants to fix it
<slangasek> andersk: /usr/share/binfmts/qemu-arm does have flags: OC
<psusi> so I can reliably cause unity-window-decorator to crash after it prints several GLib-GObject errors... what is the function that prints these so I can set a breakpoint and see what's going on?
<micahg> slangasek: we should be migrating away from non-multiarch paths instead of suppressing errors about the dir not found, right?
<andersk> (Where âmigrating awayâ means âdropping support now even though some packages still use the old pathsâ?)
<slangasek> micahg: I don't understand what errors you're referring to
<micahg> slangasek: something like this: http://web.mit.edu/andersk/Public/ubuntu/librsvg_2.34.0-0ubuntu3_multiarch.debdiff as opposed to http://paste.ubuntu.com/612527/
<slangasek> micahg: ah, no, we definitely need to look in both the old and new dirs on a transitional basis
<micahg> slangasek: and suppress errors if the old dir doesn't exist?
<slangasek> that would be reasonable
<slangasek> I hadn't bothered to do that with glib2.0 or gdk-pixbuf, for instance
<slangasek> so upgrades are a little noisier right now... but suppressing those would also be fine
<micahg> slangasek: would it be better to do an optional check on the non-multiarch dir and append to the loaders.cache if it exists?
<slangasek> micahg: also perfectly reasonable
<slangasek> provided the cache is line-based and you can do an append
<micahg> appears to be so
<broder> maco: the link in your blog post doesn't seem to work for me
<broder> i get a 404
<maco> crap
<maco> thanks
<maco> broder: what about https://spreadsheets.google.com/spreadsheet/viewform?formkey=dGRLSmxTQ05VYzh6NmdBN3BsakhpM3c6MQ#gid=0   ?
<broder> maco: wfm
<maco> ok thanks
<broder> maco: the second question is totally unfair to all of the developers who have installed ubuntu dozens of times in dozens of ways :-P
<micahg> slangasek: thanks, I think we'll go with andersk's solution as it matches the other package (gdk-pixbuf)
<maco> bradm: haha
<maco> er?
<maco> broder: haha
<maco> bradm: not you
<slangasek> micahg: given that I wrote the gdk-pixbuf bit and had a bug in it in the first pass, you should feel free to change both of them if you think it can be improved :)
<broder> maco: (i'm pretty sure i've installed ubuntu in all of the ways you list at one point or another)
<maco> broder: its there so that on the "rate the ubuntu installer" part, its possible to tell which one they're referring to
<maco> surveys have textboxes for a reason ;)
<broder> maco: some clarification in that section (e.g. "if you've installed ubuntu in multiple ways, rate the one you selected above", or something)
<micahg> slangasek: ok, maybe later, thanks
<TheMuso> c
<hallyn> ogra_: hey, I was told I should ask you about install ubuntu on the ARM AC-100/Dynabook AZ.  Is there a url where to get directions?  Do I just follow linaro directions, or is that different?
<persia> hallyn, Stop by #ubuntu-arm: there are a number of folk who can answer that (I'd be happy to, but it's long).
<hallyn> persia: thanks (in that case i guess i'll do that tomorrow)
<qchn> Happy Towelday! \o/
<pitti> Good morning
<SpamapS> pitti: I did some more sru-release's .. all > 7 days and verification-done ..
<SpamapS> pitti: and I did sru-release -d natty fwts just now to copy it to oneiric
<pitti> SpamapS: ah, good; working well for you then?
<SpamapS> pitti: yes, its perfect. :)
<pitti> SpamapS: it tends to time out for big packages
<pitti> well, not the script, but Launchpad
<pitti> those will need to be done on cocoplum
<pitti> but for the majority it should work indeed
<SpamapS> pitti: is there a bug open for launchpad then? Thats one time where a timeout exception should be made.
<StevenK> pitti: Still?
<pitti> SpamapS: I asked for bumping the timeout for this as well as the +queue page, but they didn't like that
<pitti> StevenK: have you used the +queue pages?
<pitti> sometimes you have to try and binNEW or accept from unapproved four times, and for some it just never works
<SpamapS> pitti: the other option would be to make it asynchronous
<pitti> AFAIR the primary problem that has a linear or higher time behaviour is the closing of the bugs
<pitti> that should indeed happen async
<pitti> well, that, or the timeout should scale with the number of bugs
<SpamapS> I think the former is simpler
<StevenK> pitti: I keep cheating and using q on cocoplum
<SpamapS> time is abused constantly in programming IMO
<StevenK> pitti: https://launchpad.net/ubuntu/natty/+queue or some other page?
<pitti> StevenK: yes
<StevenK> I suspect it could benefit from some pre-loading
<StevenK> pitti: It looks okay with 9 -- when does it start timing out?
<pitti> StevenK: feels like 10 seconds, yes
<StevenK> pitti: Sorry, let me be clearer. It looks okay here with 9 items in unapproved.
<pitti> StevenK: oh, displaying is fine
<pitti> StevenK: it often times out when you accept stuff
<pitti> like override in NEW and accept
<pitti> and sometimes even UNAPPROVED and accept SRUs, but that's less common
<StevenK> pitti: Ah, right
<StevenK> Indeed, bug closure is a bugger, there
<pitti> sync bug closure and fixed timeouts just don't work well together
<StevenK> Bug closure should be faster
<pitti> it should be async, or the timeout should disappear
<pitti> or be set to something like 5 minutes
<StevenK> pitti: 5 minutes?!
<StevenK> pitti: Your browser will give up long before then
<pitti> StevenK: launchpadlib won't?
<StevenK> Doesn't that use curl?
<pitti> StevenK: I've seen copy-packge taking a minute for some packages like kernel, ubuntuone, etc.
<StevenK> Which might, I'm not sure
<pitti> making closing bugs twice as fast won't help
<StevenK> pitti: In the general case -- let me hand wave and say it should always work and not timeout
<StevenK> Larger packages may present other issues, but for the small package and one or two bugs, it should be snappy.
<StevenK> pitti: I'm not arguing that we're there right now -- but we *should be*
<pitti> it's just that we tend to SRU the kernel more often than any other package :)
<StevenK> Seeing an OOPS would be helpful
<StevenK> I think there is a bug about this
<SpamapS> async seems the way to go...
<StevenK> lifeless: ^
<SpamapS> a job handle should be returned.. "Ok, I'll do that, you can check status via this job ID:"
<StevenK> SpamapS: async inside Launchpad is a *lot* of work
<SpamapS> Thats changing is it not?
<SpamapS> "The rabbit has landed"
<StevenK> Slowly
<lifeless> StevenK: context?
<SpamapS> One more pebble on the scale.. eventually it will tip. ;)
<StevenK> lifeless: We have a bug for accepting/rejecting packages from +queue timing out?
<lifeless> https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout
<pitti> or correspondingly, launchnpadlib syncSource() timing out for the same reason
<lifeless> bug 745799
<ubottu> Launchpad bug 745799 in Launchpad itself "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,Triaged] https://launchpad.net/bugs/745799
<lifeless> bug 641338
<ubottu> Launchpad bug 641338 in Launchpad itself "Archive:EntryResource:syncSource timeouts" [Critical,Triaged] https://launchpad.net/bugs/641338
<lifeless> pitti: patches accepted!
<lifeless> SpamapS: rabbit makes async lower latency
<pitti> "bump timeout to 1 minute"? :-)
<lifeless> pitti: on POSTS, thats a recipe to make other requests timeout
<lifeless> pitti: due to lock contention, increased DB bloat and greater request backlogs
<pitti> lifeless: but the shell tools on cocoplum take just as long anyway?
<lifeless> pitti: and cause problems.
<lifeless> pitti: they will be turned off as soon as we can
<pitti> so we usually try a couple of times with +queue or syncSource() and then ssh in and have the command take a minute there
<StevenK> If we fix the root cause they should both be quick
<pitti> lifeless: right, but that's a chicken-egg problem; we desperately need them as long as we have the timeouts
<SpamapS> lifeless: so even doing it "the old way" is hard?
<StevenK> 1,200 queries looks like death-by-SQL to me
<lifeless> pitti: and thus those bugs are critical
<SpamapS> I'd have thought by now there's be a nice architecture for anything one wants to do asynchronously.
<lifeless> SpamapS: there is a tolerable one yes.
<lifeless> SpamapS: and StevenK's team is working on making package copies be async
<StevenK> Read as: "I want to commit harikari every time I use it."
<lifeless> SpamapS: but backend things still have to have timeouts
<StevenK> Not my team :-P
<lifeless> StevenK: well, you're seconded, so gnar gnar gnar :P
<StevenK> lifeless: For another 2.2 days
<lifeless> oh? cool.
<lifeless> StevenK: you'll be on timeout patrol then ?
<StevenK> lifeless: No, disclosure
<lifeless> StevenK: or disclosure?
<lifeless> ah, cool
<StevenK> With the rest of Teal
<SpamapS> lifeless: sure they should have timeouts. I think backend things can justify finer grained timeouts due to the fact that there's no browser spinning waiting on them.
<SpamapS> lifeless: and the fact that one can control just how much impact one will have at any one time
<lifeless> SpamapS: sure, we have that
<lifeless> SpamapS: but any timeout that is substantially longer than the lowest timeout we have /will/ cause operational problems.
<lifeless> SpamapS: so we won't do that.
<lifeless> we need to fix these problems.
<didrocks> good morning
<smb> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Tm_T> hi dbarth, have a moment?
<lucidfox> Hmm
<lucidfox> why wasn't tomcat7 autosynced from unstable?
<StevenK> Because it's a new package, that's a seperate process
<dpm> hey pitti, good morning, thanks for the feedback on universe translations. I've got one last question: one of the approaches we were talking about was whitelisting (either a list within pkgbinarymangler or on the packages themselves using something like "XS-Ubuntu-Use-Langpack"). On the first approach (a list in pkgbinarymangler) you're mentioning that we'd need to maintain the list in Launchpad as well. Why is that? Assuming LP would be modified to acc
<dpm> ept universe translation tarballs, would it not just import anything pkgbinarymangler feeds it?
<pitti> dpm: but we already build/import all translation tarballs
<pitti> dpm: we could of course stop doing so for universe packages
<pitti> and only build a translation tar for the whitelisted ones
<dpm> pitti, ok, I got you now, I had not taken into account that we're already importing universe translations tarballs
<dpm> pitti, "only build a translation tar for the whitelisted ones" <-- yes, that's what I was thinking of
<pitti> dpm: WFM
<pitti> dpm: followed up with that proposal
<dpm> pitti, ah, right, thanks. I'm just writing a reply, let me read yours first...
<cjwatson> lucidfox: synced now
<cjwatson> micahg: are you working on the sslsniff FTBFS?
<lucidfox> cjwatson, thanks
<apw> pitti, do you know (off the top of your head) how the udev handoff from initramfs to / is done, i will go look if not
<pitti> apw: what is the "udev handoff"? I thought it'd just rebind the /dev mount from initramfs into /root?
<apw> pitti, no i am wondering about how udevd gets replaced by the one in /
<apw> pitti, will go look no worries
<pitti> # Move /dev to the real filesystem
<pitti> mount -n -o move /dev ${rootmnt}/dev
<apw> # Stop udevd, we'll miss a few events while we run init, but we catch up
<apw> pkill udevd
<apw> t'is that bit i was wondering about, found it now ... basically hoping we hand off in a sensible way, seems not
<pitti> I wonder why we need the pkill there
<pitti> we basically start it in initramfs, kill it, then start it again from upstart, and do a coldplug trigger
<pitti> but can't we reuse the original instance here?
<apw> well the reasoning is that we should get a nice fresh one from / in case it has been updated
<pitti> ah, I guess we couldn't atomically do the move mount and tell the udevd process about it
<ogra_> cjwatson, hmm, do we actually need changes to live-build for jasper ? is there no mode where it just rolls a default initrd and we could have jasper through a seed ?
<apw> though we could bind mount it
<cjwatson> pitti: if you keep the old process, you can never free the initramfs memory
<apw> pitti, cjwatson typically noone else does this as it is exposing an issue with address reuse on the udev control socket
<apw> with the new 170 version
<cjwatson> ogra_: well, there is --initramfs none I guess, though I suspect it will still need some of the same changes as otherwise you end up with boot=none (though I know we aren't currently using the modes where live-build's ideas of kernel parameters matter, but still)
<cjwatson> I can give it a try
<ogra_> i think that would be nicer than having jasper hardcoded in the build system
<cjwatson> ok, this is why I cced you :-)
<ogra_> :)
<pitti> dpm: is there a separate spec for universe translations? you have three WIs on https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-qin-ubuntu-china which don't seem directly related
<dpm> pitti, there isn't a separate spec for universe translations. I put the universe WI there after someone in the UDS discussion mentioned that OEM would like to have more control over the translations they ship for selected universe packages and complete them in langpacks. The discussion then went on on whether these packages should just be promoted to main, or if we don't/can't promote them to main, whether its translations could be imported regardless o
<dpm> f them being in universe. I put the WI there as a reminder for me to do the research and provide the results, as an aid to whoever is making the decision or either doing a MIR for those packages or get their translations imported into LP
<pitti> dpm: ah, thanks
<dpm> pitti, so I'll just summarize your feedback and danilo's, put it in the whiteboard now and mark it as done
<persia> Unless it makes things incredibly more complicated, it would be convenient if a future-looking solution allowed one to provide translations for arbitrary batches of packages (that happen to be in universe), rather than specifically being related to the packages being in universe.
 * cjwatson boots oneiric in a VM
<cjwatson> http://people.canonical.com/~cjwatson/tmp/oneiric.png - new desktop style? :-)
<dpm> persia, let me paste the options we've been discussing on the whiteboard in some minutes. We've been discussing something along these lines.
<cjwatson> (I assume this is partly the lack of either a classic session or unity-2d)
<geser> cjwatson: is your gdk-pixbuf loaders.cache empty (0 size)? (do you get messages about unknown image formats?)
<pitti> cjwatson: welcome to gnome 3: )
<persia> dpm, Thanks.  Everything I've heard before was along those lines: I just get worried when people start talking about "universe" foo.
<pitti> cjwatson: right, gnome-session-fallback needs to be seeded
<cjwatson> geser: already killed the vm
<pitti> seb128: ^ btw, there was  nothing wrong with my upgrade; it's currently a suggests: of gnome-session, not a recommends
<pitti> geser: that got fixed last night, and with that bug you didn't even get to nautilus
<pitti> cjwatson: so you got an oneiric live CD to build? nice!
<pitti> cjwatson: let me seed it, and rebuild u-meta
<geser> pitti: I managed somehow
<dpm> pitti, as per the other 2 WIs, they are basically the same thing: someone asked how we track and fix translations bugs, and how we can improve that. Colin asked me something similar a while ago (to have some guidelines for the bugsquad -or anyone else- on how to report and triage translations bugs), so I added it as an action for me, so I get it done this cycle
<cjwatson> pitti: last night
<pitti> didrocks, seb128: hm, so do we want gnome-session to pull in -fallback, or explicitly seed it?
<didrocks> pitti: so, for alpha1, we will have gnome-session pulling in -fallback
<pitti> cjwatson: ok, so the next rebuild should also pick up the pixbuf fix
<pitti> didrocks: ok; do you want to do the g-session upload for this, or want me to?
<didrocks> pitti: so, once gnome-panel is transitionned, it recommends -fallback, and we will remove the dep from gnome-session on -fallback
<didrocks> pitti: will do it today, once I've managed unity-2d
<seb128> pitti, what didrocks says
<pitti> hm, that sounds backwards
<seb128> pitti, gnome-panel should bring the session corresponding to it in
<pitti> shouldn't -fallback depend on gnome-panel, not the other way round?
<didrocks> pitti: we won't install gnome-panel on oneiric
<seb128> but we can't build gnome-panel now that e-d-s is on gtk3
<seb128> sounds like a circular depends indeed
<didrocks> pitti: that was what we discuss with mvo yesterday on #ubuntu-desktop, we only want gnome-panel for upgrade, not new install
<didrocks> gnome-session-fallback dep on gnome-panel, but gnome-panel recommends -fallback
<pitti> didrocks: ah, I see; and we wouldn't install -fallback, just unity-2d
<didrocks> pitti: exactly
<pitti> ok, then we shouldn't seed it either
<didrocks> just not possible for alpha1 as gnome-panel (with the new recommends on -fallback) is build-dep waiting
<didrocks> right
<seb128> didrocks, pitti: that's still sort of a circular depends,recommends not sure if that's an issue or not
<seb128> the other option would be to ship the session file in gnome-panel
<didrocks> seb128: hence the fact I asked yesterday with mvo. IIRC, we already have tons of deps <-> recommends relationship like that
<seb128> didrocks, ok, great, less work then ;-)
<didrocks> seb128: yeah, less divergence :-)
<doko> barry: why does virtualenv point to /usr/share/pyshared at all?
<ev> pitti, seb128: there's a workitem in https://launchpad.net/ubuntu/+spec/desktop-o-gtk3-gnome3 for demoting cheese or writing an MIR for gnome-video-effects. As I understand it, the latter is *just* the effects.
<ev> so is there another reason to demote cheese?
<seb128> ev, why is it in main?
<ev> seb128 what, cheese?
<seb128> yes
<seb128> I'm never clean what's the point to have things which are not on the CD in main
<ev> well, if I dig back up the python bindings and integrate it into the installer, for that :)
<kirkland> can anyone point me to some good documentation on po-debconf and dh7 ?
<seb128> ok, fine to keep it there, I just figured it would be easier for contributors to work on it if it was in universe
<cjwatson> kirkland: I've generally found the man pages fine
<kirkland> or, perhaps a source package that does this well already?
<ev> seb128: sure thing, I just wanted to be sure it wasn't going away for some other reason
<kirkland> cjwatson: interesting approach :-)
<kirkland> cjwatson: let me dig there
<seb128> ev, no, didrocks mentioned that empathy is going to use libcheese as well I think so we will need to keep it in main anyway
<ev> okay, cool
<cjwatson> kirkland: generally you only need to make sure translatable text is marked properly, create debian/po/POTFILES.in, and run debconf-updatepo
<cjwatson> kirkland: you could try e.g. man-db
<kirkland> cjwatson: yeah, looks like i've been overengineering this
<kirkland> cjwatson: thanks, manpg.es/po-debconf has what i need ;-)
<tkamppeter> pitti, ping
<pitti> hey tkamppeter
<kirkland> cjwatson: do you run debconf-updatepo manually when something changes?  or do you do it at build time?  release time?
<kirkland> cjwatson: i don't see a call to debconf-updatepo in your man-db sample, so I presume you run that manually?
<tkamppeter> pitti, I have now set up the WIs for the color management Bleuprint, https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-icc-color-management
<tkamppeter> pitti, looks all doable for Oneiric.
<hallyn> mdeslaur: all right, so i think it's time to call in the big guns to try and coax the community into being interseted in implementing netcf for debian :)
<hallyn> mdeslaur: it looks like so much fun, but i can't responsibly commit to it
<hallyn> mdeslaur: you were suggesting asking dholbach and who else?
<mdeslaur> hallyn: well, let's start with dholbach to see if he has any ideas
<cjwatson> kirkland: manually
<hallyn> mdeslaur: ok, thanks.  he's not in right now it appears, drat.
<cjwatson> kirkland: changes are rare so I don't find it a problem
<cjwatson> kirkland: some packages run it on clean - I find this irritating personally as it keeps resulting in minor changes that cause desync from revision control
<cjwatson> kirkland: (there's a lintian warning for if I forget to run it)
<kirkland> cjwatson: okay, cool, thanks
<kirkland> cjwatson: appreciate the advice
<pitti> tkamppeter: ah, good; do you want to work on this (i. e. packaging the missing bits, etc.)?
<mdeslaur> hallyn: I wonder why the netcf page says networkmanager uses it...AFAICT, it doesn't
<hrw> hi
<hrw> did someone tested upgrade from evolution 2.32 to 3.x?
<hallyn> mdeslaur: fedora might have custom patches that aren't upstream?
<hallyn> or they're lying
<hallyn> did you know every distro is using.... nm
<pitti> hrw: I'm using evo 3 now, yes
<tkamppeter> pitti, I will at least allpy all patches to the printing-related packages.
<hrw> pitti: I had to move ~/.local/share/evolution to not make it crash
<hrw> pitti: now fetching back 1GB of mails
<pitti> hrw: my calendars etc. still work; I only have local mail in evo (using offlineimap and mutt)
<tkamppeter> pitti, gnome-color-manager seems to be well maintained by Robert Ancell, so he should continue maintaining it also after it got transferred to Main.
<hrw> pitti: migration from mbox -> maildir was asked once and then died. no question anymore - just crash
<pitti> tkamppeter: ah, sure; the linked bugs should be assigned to persons then (like g-color-manager to Robert, foomatic to you, etc.)
<tkamppeter> pitti, I do not know, but perhaps Robert has knowledge about color management and so it could be good if he would also take maintainership on Argyll and colord.
<pitti> tkamppeter: ok, let's wait for Robert to come back (he's sick with ubuflu right now)
<tkamppeter> pitti, what is ubuflu?
<pitti> tkamppeter: the illness which half of the people get at UDS :)
<tkamppeter> pitti, so one week of UDS makes him going away for two weeks, not very efficient ...
<hrw> shit. evo is crashing like crazy
<tkamppeter> pitti, the instructions for MIRs tell to not assign the MIR to anyone, is there any problem then with having a MIR as a WI?
<pitti> tkamppeter: ah, leave that one unassigned then
<hrw> cyphermox: is it normal that any ~/.local/share/evolution/ contents == crash of evolution in oneiric?
<cyphermox> no
<seb128> pitti, robert_ancell is not likely wanting to maintain those
<cyphermox> hrw, any time you have anything in evo you should have stuff in that directory
<hrw> cyphermox: I know
<seb128> pitti, he didn't want to take on that previous cycles when the topic was discussed and said he would focus on lightdm and step away from maintaining things this cycle
 * pitti nods
<hrw> cyphermox: when it is empty then evo starts, asks me to accept ssl cert of my private mail and fetches mails. if I quit and start evo then it crashes
<seb128> he's also not maintaining those component because he's interested, he just did some updates because they were updated
<seb128> we shouldn't do it if we have nobody interested to maintain the stack
<seb128> we have enough other things to deal with already this cycle...
<pitti> yeah, we already have 30% more WIs than in natty even without this :/
<cyphermox> hrw: if you start evo from the command-line, it should probably list what's wrong. something must have not migrated properly
<hrw> cyphermox: https://pastebin.linaro.org/95/
<pitti> tkamppeter: if you have time and want to work on it, sounds fine; otherwise it's probably something for the next cycle then
<pitti> when we don't have a gnome 3 and lightdm transition to do?
<hrw> cyphermox: thats backtrace with evolution-dbg
<hrw> cyphermox: http://paste.ubuntu.com/612796/ is whole output of crashing evo
<cyphermox> hrw: can you re-paste what you put in pastebin.linaro.org, I don't have access to that
<hrw> oops
<tkamppeter> pitti, only problem is that next cycle is LTS. So I will look into starting color management support and if it is not too complex start it and look for distributing maintainership on UDS-P.
<hrw> cyphermox: http://paste.ubuntu.com/612797/
<pitti> tkamppeter: right, seems this can be done one step at a time indeed
<cyphermox> hrw: do you use unity? I'm curious if you're not seeing this crash due to the issues we had with gdkpixbuf loaders yesterday?
<hrw> cyphermox: xfce
<hrw> cyphermox: I avoid unity as it does not fits me
<hrw> cyphermox: I did 815MB upgrade today and did not restarted x11 session since that
<cyphermox> ok
<hrw> but it should not crash just because of that
<cyphermox> well, the gdk-pixbuf loaders missing do crash evolution :)
<cyphermox> hrw: just to make sure, check that /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/gdk-pixbuf-2.0/2.10.0/loaders.cache isn't zero size
<hrw> -rw-r--r-- 1 root root  146 2011-05-25 15:28 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
<seb128> there is a bug in the package, it lacks a depends on dpkg-dev for dpkg-architecture, I will fix that in a bit
<seb128> that seems smaller than it should be
<hrw> cyphermox: so it is empty
<hrw> only comments inside
<hrw> and 17:30 hrw@home:build$ sudo gdk-pixbuf-query-loaders |wc -l
<hrw> 139
<cjwatson> seb128: uh, is this a runtime package?
<seb128> cjwatson, it's a postinst
<hrw> no update-gdk-pixbufs command anymore?
<cjwatson> seb128: runtime packages need to not depend on dpkg-dev
<cyphermox> hrw: no, that's what gdk-pixbuf-query-loaders does
<seb128> how do we get the multiarch dir without that?
<cjwatson> seb128: you could substitute in the output of dpkg-architecture at build time instead
<cjwatson> assuming you're not arch all
<hrw> 17:32 root@home:build# gdk-pixbuf-query-loaders >/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
<hrw> and then evo works
<tkamppeter> pitti, all bugs of the ICC Blueprint are assigned to me now, so now everything on this Blueprint should be OK now.
<cjwatson> a runtime dependency on dpkg-dev is a multi-megabyte CD size penalty (or will be once I get lintian adjusted)
<seb128> cjwatson, can we get something in the standard install that gives you the multiarch directory?
<seb128> having to sed .in files during the build for that is annoying and as you pointed doesn't work in arch all cases
<cjwatson> seb128: -> slangasek
<seb128> slangasek, ^
<cjwatson> (I believe there was some discussion of that in the context of the FHS/LSB)
<seb128> cjwatson, but noted, no dpkg-dev depends
<apw> can anyone remind me what determines which architectures a source package will attempt to build.  i am naievly expecting it to be the union of all of the Architecture: lines
<Laney> I believe it is for all archictures, unless overridden by the Packages-arch-specific file
<slangasek> seb128: yeah, no good solution for that yet :(  as cjwatson says, we want to avoid a runtime dep on dpkg-dev for dpkg-architecture
<seb128> slangasek, can you fix librsvg then to use something at build time when you have some time then? ;-)
<slangasek> seb128: is this in an arch: all package, or is the problem the maintenance inconvenience of having to postprocess the maintainer scripts?
<slangasek> yeah
<tkamppeter> pitti, still there?
<seb128> slangasek, not, it's just that I went for what was easy to do since that was late yesterday evening and I wanted to fix the issue of the empty cache breaking loaders before going to bed
<slangasek> yep
<seb128> slangasek, I'm not sure what the's best way to do it dynamically at build time so if you have a clue please do it ;-)
<slangasek> will fix it up today
<pitti> tkamppeter: yes (was typing a long email sermon)
<slangasek> I have an example or two of this on my hard drive at the moment :P
<tkamppeter> pitti, is all OK with the ICC Blueprint now?
<pitti> tkamppeter: should be, yes; I'll accept it, but as we discussed don't worry if you don't get to it; it's still a target of opportunity
<apw> Laney, is that file available somewhere for viewing?
<tkamppeter> pitti, OK and thanks for your help.
<Laney> apw: http://anonscm.debian.org/gitweb/?p=mirror/packages-arch-specific.git;a=blob_plain;f=Packages-arch-specific;h=f654079cf2f07e7a7b6253d3762ee13c9b92380e;hb=HEAD
<persia> Don't we have a separate copy of that in Launchpad now?  I thought there was some kerfluffle in 2009 about it.
<apw> yeah we seem to have a bzr branch for it
<Laney> I thought it was a mirror
<Laney> and git.d.o happened to be handier to retrieve, but ymmv :-)
<cjwatson> https://code.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu is what's actually deployed for Ubuntu
<cjwatson> it's a (not very large) branch
<cjwatson> off a bzr mirror of the Debian git branch, of course
<apw> cjwatson, is that the only thing which defines which arches build things, as i don't see anything for linux-lts-backports-maverick and that builds on amd64 i386 and all only
<persia> apw: There's also the Architecture: bit in the packages, and some oddities if one uploads to a virtualised PPA and pocket-copies
<cjwatson> yeah, it's basically because you have Architecture: amd64 i386
<apw> so that makes sense, a new package in the ckt PPA (the natty lts backport) has errored on all the other architectures and i'd not expect it to have done so
<cjwatson> if it's failing on architectures you don't care about, just ignore it
<cjwatson> not worth worrying about
<apw> it seems identicle in Architecture: configuration to the other and yet behaving different
<apw> ok
<Daviey> I know last year there was an issue with linux-any
<cjwatson> apw: yeah, probably tedious differences between real archive and PPAs
<cjwatson> Daviey: I believe that to be sorted
<Daviey> yeah, it is now
<rsalveti> is there a way to get notifications for new ftbfs entries?
<rsalveti> I'll be helping filling and triaging ftbfs bugs for arm
<dmart> doko, barry: Hi there ... I've been looking into an "exceptions bootstrapping error" which occurs when libpython is used to embed an interpreter in another application -- specifically, this causes adonthell to ftbfs
<dmart> I've tracked this down to a failed sanity check in PyType_Ready, called from _PyExc_Init
<stgraber> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<dmart> The failure happens on the call PRE_INIT(BaseException) at Objects/exceptions.c:2080
<dmart> (in python2.6-2.6.6)
<stgraber> cjwatson: hey, while I think of it. Remember the edubuntu-live package at UDS? I uploaded it in Oneiric but can't find it available for translation on LP, did I forget to do something so that it shows up there?
<dmart> doko, barry: ^ any thoughts about what's going on / what I should be looking at?  AFAIK this failure has only been seen on armel, but that may be incorrect
<tkamppeter> sabdfl, hi
<sabdfl> hi till
<dmart> james_w: removed the series goal and milestone target from that blueprint.  I'll follow up with the platform guys to see whether this needs to get rescheduled.
<barry> dmart: hi, i was at lunch
<barry> dmart: no idea.  i've never seen that before.  could it be a memory problem?  it's been a while since i've read through PyType_Ready but i think if you were memory constrained, it could fail
<tkamppeter> sabdfl, ping
<SpamapS> hm, is sbuild confused by Build-Dependencies like " locales-all | language-pack-de" ?
<SpamapS> where locales-all doesn't exist...
<persia> Yes.
<SpamapS> is the answer pbuilder?
<persia> When generating alternative Dependencies, Recommendations, and Build-Dependencies, one needs to choose a real package followed by others.
<persia> No, because if it happens to work with pbuilder, it will FTBFS when you upload it and LP runs sbuild.
<SpamapS> This is the debian maintainer for PHP wanting to make the package easier to merge...
<persia> That's doing it wrong.  Debian also uses sbuild for the wanna-build network.
<slangasek> persia: your comments are a significant departure from historical practice in Ubuntu
<persia> slangasek, Hrm?  How do?  We've always needed to put real packages before virtual packages in | constructs.
<slangasek> Build-Depends: $not_in_main_in_ubuntu | $ubuntu_preferred_package has been a standard technique for quite a while
<SpamapS> In this case its $not_in_ubuntu_at_all | $not_in_debian_at_all
<slangasek> and sbuild as used in Ubuntu has been specially trained to consider non-default alternatives for this reason
<persia> Ah, yes, and I suppose $not_in_main_in_ubuntu ~= $does_not_exist
<SpamapS> aha
<SpamapS> --check-depends-algorithm
<SpamapS> =alternatives .. lets try that
<slangasek> yeah, no idea how you get this behavior out of the current /packaged/ version of sbuild, I'm afraid; I don't think the LP one runs from a package
<persia> It doesn't.  The remaining differences are small though, and mostly related to build-harness stuff.
<persia> OK.  I'm confused.  Policy 7.1 clearly states that anything is fine, but I'm sure I've previously been told on many occasions to have the first in a | list be some real package.
<SpamapS> damn.. -C alternatives didn't work
<slangasek> persia: I think this may have been a recent policy clarification.  In general, you don't want to have listed as the first alternative a virtual package that's provided by multiple real packages, because it causes nonintuitive behavior
<slangasek> and if the first alternative isn't available in Debian, the package will FTBFS in Debian
<slangasek> but otherwise, it should work no matter what you do
<persia> Ah, so the recommendation once matched what I've said, but in practice the only case where one needs to worry is when the first alternative is virtual and multiply-provided?
<persia> If the first alternative isn't available in Debian, it will certainly FTBFS?
<slangasek> yes, and yes
<maco> persia: dontcha love it when the rules change under your feet?
<Laney> Currently, although there was some talk about switching resolver.
<SpamapS> So the issue is, php's test suites needs either locales-all or language-pack-de ... both of which are unique to Debian and Ubuntu respectively.
<persia> SpamapS, I don't believe you can usefully locally build-test that construction: send it to a PPA.
<persia> SpamapS, Also, please file a bug against sbuild for that: there's been talk about switching LP to distro sbuild, and this change is one that isn't in the patches-needed-for-sbuild I was given last week.
<SpamapS> I'm trying it w/ build-dep-resolver=aptitude too
<SpamapS> Will do on the bug
<slangasek> so I think that using the apt, aptitude resolvers will actually work for your purposes in Ubuntu
<persia> maco, Actually, yes, because this tends to mean 1) I learn and 2) the world is a better place
<slangasek> ... unless rleigh has since patched them to be more Debian-like :)
<slangasek> SpamapS: btw, it is possible to generate a locale at package build-time, spit it out to a local directory, and point a package at that, er, local locale... in the grand scheme of things that seems more sensible to me than build-depending on locales-all
<slangasek> but that's probably out of scope for what you're trying to accomplish right now :)
<persia> slangasek, There's definitely talk about switching the default resolver away from the internal sbuild one.  I thought I saw a clear statement in my oneiric NEWS.Debian.gz file, but my Oneiric system isn't responding to pings right now, so I'll be a bit confirming.
<persia> I suspect that if it's intentional that first-alternative-unavailable causes FTBFS, the aptitude resolver is likely to support that model.
<slangasek> it was discussed at length on debian-devel, anyway
<slangasek> I don't know what's been implemented to date
<SpamapS> slangasek: I believe the tests specifically require de
<slangasek> yes, and you can generate a de locale using this method
<persia> One could generate de locally
<SpamapS> Ah interesting
<slangasek> because the source data is always available under /usr/share/i18n
<SpamapS> so just the tool is necessary then? Where would the locale information come from?
<SpamapS> ah
<slangasek> you could look at /usr/sbin/locale-gen, if you really want to go down that rat hole :)
<SpamapS> I'm hesitant to even care since we will *always* have a delta w/ Debian on PHP ..
<SpamapS> I mean unless 4 or 5 upstreams get their act together and start being main-worthy
<SpamapS> btw aptitude did resolve this issue, there are other issues now w/ the libdb transition
<SpamapS> slangasek: looks like db4.8's merge is blocking libdb-dev from working properly
<slangasek> really?
<SpamapS>   libdb-dev: Conflicts: libdb4.8-dev but 4.8.30-5ubuntu2 is to be installed.
<SpamapS>   libdb5.1-dev: Conflicts: libdb4.8-dev but 4.8.30-5ubuntu2 is to be installed.
<slangasek> nah, that's not the merge that's blocking
<slangasek> something in your build-dep chain needs to transition to the newer version
<slangasek> libdb4.8-dev and libdb5.1-dev aren't coinstallable
<SpamapS> everything in libdb4.8 has to be migrated I take it?
<SpamapS> rather, all of the rdepends ?
<slangasek> eventually they all do
<slangasek> for your purposes, you probably just need apache / apr to do so
<stgraber> jhunt: hey! is https://code.launchpad.net/~jamesodhunt/ubuntu/natty/upstart/fix-for-770532/+merge/59348 already in Oneiric's upstart?
<SpamapS> slangasek: yeah, apr-util
<SpamapS> slangasek: I requested sync on apr-util .. the delta was applied upstream.. if you could maybe make that sync happen that would help quite a bit. :)
<SpamapS> I know I have aa rights, but I don't have permission just yet. ;)
<SpamapS> anyway, bbl
<stgraber> jhunt: ok, apparently not. Do you want me to apply that diff to Oneiric, upload it and then upload the same as SRU in natty-proposed?
 * micahg thought the build dep alternative issue was only for versioned build-deps
<slangasek> SpamapS: done-ish
<jhunt> stgraber: that would be great, thanks.
<micahg> would some type of helper like dh_multiarch be useful that does substitution?
<stgraber> jhunt: ok, working on that now then.
<jhunt> stgraber: FYI - http://package-import.ubuntu.com/status/upstart.html - does that affect what you'll be doing?
<stgraber> jhunt: oh, thanks for the warning. Yes it'd have :)
<stgraber> jhunt: I'm going to do it as a good-old upload then (without UDD)
<stgraber> or can try to fix the branch, if that's just one missing tag.
<jhunt> stgraber: you might want to discuss with SpamapS. I'm still not clear if I should have created that tag as the proposer (?)
 * micahg of the opinion the tag should be created by the uploader in cases of sponsorship unless it has been previously discussed
<slangasek> isn't the issue here that the branch didn't use merge-upstream?
<stgraber> yep, that was the issue. I'm going to manually add the tag, that should help
<slangasek> manually add it to what?  I don't think you have a commit on there you can add it to that matches what's expected
<stgraber> slangasek: r1311 is what bumped configure.ac from 0.9.6 to 0.9.7
<slangasek> "upstream-0.9.7" should point to a commit that contains the entire upstream *tarball*
<slangasek> there is no such commit in the current history
<stgraber> hmm, right
<stgraber> slangasek: suggestions? should I just go with non-UDD upload until the branch is fixed somehow? SpamapS commited 0.9.7-2 to the branch but apparently didn't use debcommit as the 0.9.7-2 tag is missing, so it's not clear what to do with the branch :)
<slangasek> stgraber: I was going to poke the missing bits in now with merge-upstream
<slangasek> but I can't find the source branch that maps to what I see merged in the history
<slangasek> jhunt: is there an upstream upstart branch that maps to what shows up as 0.9.7 in the lp:ubuntu/upstart history?
<slangasek> lp:~jamesodhunt/upstart/0.9 specifically does not appear to be it
<slangasek> oh, lp:~upstart-devel/upstart/0.9, here we go
<jhunt> slangasek: right.
<slangasek> stgraber, jhunt: FYI: bzr merge-upstream --last-version=0.6.7 --version 0.9.7 /mirror/ubuntu/pool/main/u/upstart/upstart_0.9.7.orig.tar.gz
<jhunt> SpamapS: could you take a look at the work items on https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-upstart-for-admins/ when you get a chance to make sure I haven't missed anything.
<SpamapS> jhunt: sure, I'll give it a closer look tonight
 * SpamapS is running out the door for an appointment
<highvoltage> don't run with laptops!
<Bert_2> Is this channel suitable for questions concerning licenses on certain ubuntu packages ?
<slangasek> stgraber: branch should be more or less cleaned up now for you to work against
<stgraber> slangasek: thanks!
<barry> okay, here's a package version numbering question for you: i'm manually merging debian's python-numpy 1:1.5.1-2 to our 1:1.5.1-1ubuntu2.  we still need to carry one extra ubuntu-specific patch.  bzr merge-package succeeded with no conflicts but leaves me with a version number 1:1.5.1-2, however because of the ubuntu-specific patch, this is not identical to the debian version.  i think i should change our version to 1:1.5.1-2ubuntu1
<barry> before i commit the merge and uplload.  is that correct?
<slangasek> yes
<micahg> barry: yes, and there should be tags for both
<slangasek> bzr merge-package doesn't autoincrement the changelog, AFAIK
<slangasek> well, the 1:1.5.1-2 tag should already be there courtesy of UDD
<micahg> right
<seb128> seems like a bug in the merge tools I was about to say
<barry> it doesn't autoinc the changelog but it does merge changelog entry from the debian package
<slangasek> yep
<seb128> slangasek, why is the version not updated?
<seb128> (just curious)
<slangasek> seb128: I didn't write any of the code in question, perhaps no one thought of it yet :)
<barry> indeed, after bzr merge-package the 1:1.5.1-2 tag is there (uncommitted as of yet)
<slangasek> honestly, I usually use 'bzr merge' instead of 'bzr merge-package'
<barry> and the bzr mark-uploaded will add the 2ubuntu1 tag
<barry> or at least *should* ;)
<slangasek> but 'bzr merge-upstream' *does* kick off a new debian/changelog entry, so it seems merge-package ought to as well
<seb128> slangasek, that's still better than us desktopers, we just keep our debian dir in the vcs and do merges the good old way ;-)
<barry> so just to be clear, i do not need both changelog entries, right?  and i should probably include the fact that we're still carrying an ubuntu-specific patch in the 2ubuntu1 changelog entry, right?
<slangasek> oh, here's a question
<james_w> yeah, it needs both changelog entries
<slangasek> bzr merge-package isn't specific to Debian->Ubuntu merges... what should it auto-increment the changelog entry to, and how should it decide?
<james_w> so it's whether it should add dch -i at the end
<james_w> I didn't because you may not be doing that
<seb128> barry, so seem weird questions ;-) usually a merge is "take what is in debian and add the ubuntu changes with an entry listing those"
<barry> james_w: ah, so my commit should contain two changelog entries, one from the merge-package (i.e. copied from the top debian changelog) and another with the ubuntu-specific patch mentioned
<slangasek> barry: yes, the changelog for a merge should document the remaining delta
<james_w> we could add a flag for it, and a --distribution option
<seb128> james_w, hey
 * micahg thinks it shouldn't add anything on top since you could just be merging in the current version
<james_w> hi seb128
<seb128> james_w, do you know why http://reports.qa.ubuntu.com/reports/sponsoring/ got quite some merge requests from you on series going back to edgy?
<barry> seb128: hi, yeah i know it seems a bit weird.  i think common case would be where we could drop the ubuntu-specific change (but i don't have enough data oints to know for sure).  in this case, we can't
<seb128> james_w, it seems pretty weird old series like edgy get activity now
<slangasek> barry: common case> heh, not hardly, I'm afraid
<barry> ;)
<barry> slangasek: okay, maybe i'll do a merge proposal and have you take a quick look for sanity?
<seb128> barry, well, I would rather think that things we have a diff on the diff is there for a reason ;-)
<james_w> seb128, iz james_w bog
<slangasek> seb128: I think he means that the next merge from Debian would commonly include the changes from Ubuntu and we would be back in sync... wishful thinking though :)
<slangasek> barry: can do
<james_w> the importer gets thoroughly confused and thinks someone uploaded something there that conflicts with what is in the branch, when obviously they didn't
<james_w> the reason it sees uploads now is that it has failed in the past, and so hadn't finished importing edgy
<james_w> I haven't had chance to go through and investigate and file appropriate bugs yet
<seb128> slangasek, indeed ;-)
<seb128> james_w, ok
<barry> slangasek: right, that was my hope, false as it is ;)
<barry> slangasek: https://code.launchpad.net/~barry/ubuntu/oneiric/python-numpy/merge-deb-1_1.5.1-2/+merge/62367
<slangasek> barry: grabbing
<slangasek> barry: the convention for the changelog entry on a merge from Debian is to declare something like "merge from Debian unstable, remaining changes:" so it's clear from context that this isn't a new change you're introducing
<barry> slangasek: would that be on the first changelog entry or the second?
<slangasek> also, some of us changelog addicts will go so far as to document why each other bit of the delta has gone away ("merge upstream", "merged in Debian", "no longer relevant", etc)
<seb128> slangasek, btw I assigned bug #788115 to you (that's about changing the dpkg-architecture call in the librsvg postinst by a build time generation)
<ubottu> Launchpad bug 788115 in librsvg (Ubuntu) "[Oneiric] dpkg error when upgrading librsvg (2.34.0-0ubuntu4)" [Undecided,Confirmed] https://launchpad.net/bugs/788115
<slangasek> barry: the top one; you only want to modify the changelog entry for the Ubuntu upload you're doing
<slangasek> not for the Debian upload you've merged
<slangasek> seb128: ack, thanks
<barry> slangasek: ack, thanks
<seb128> slangasek, thank *you* for working on it ;-)
<barry> slangasek: update pushed, but no need to review it if you don't want.  thanks again for the advice
<slangasek> no prob :)
<barry> come back launchpad, we still love you
<cjwatson> stgraber: edubuntu-live> hmm, not sure - I'd suggest asking dpm to check it out, as I'm pretty rusty on that stuff
<stgraber> ok, will poke him tomorrow
<stgraber> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Darxus> What determines what section a man page generated from pod ends up in?  For spamd.raw, it's ending up in 8 for Debian, and apparently 1 for others:  http://svn.apache.org/viewvc/spamassassin/trunk/spamd/spamd.raw?view=markup
<Darxus> (Debian and Ubuntu).
<slangasek> Darxus: see man(1) :)
<slangasek> er, no
<slangasek> sorry, I misread your question
<slangasek> well, pod2man takes a --section option
<cjwatson> kirkland: when you last uploaded a bug-fix to newpki-server, you set yourself as the Maintainer.  Now it needs to be rebuilt for the OpenSSL 1.0.0 transition, but it's unbuildable because newpki-lib has been removed.  Upon investigation I found that all the newpki-* packages have been removed from Debian, and newpki-server is the only one left (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572740).  Do you care enough ...
<ubottu> Debian bug 572740 in ftp.debian.org "RM: newpki-server -- RoQA; orphaned, dead upstream, rc" [Normal,Open]
<cjwatson> ... about this to stop me removing newpki-server from Oneiric?
<cjwatson> (I probably wouldn't have asked except that you'd set yourself as Maintainer rather than ubuntu-devel-discuss)
<kirkland> cjwatson: hmm, let me refresh my memory, grabbing sources now....
<Darxus> Ah, I found the change, the man page got renamed in debian/rules.
<cjwatson> kirkland: if you care, you'll need to at least track back to why newpki-lib was removed, fix those problems, and reintroduce that package
<bdmurray> I see there are no pilots but perhaps someone would sponsor my upload?
<bdmurray> its in bug 781874
<ubottu> Launchpad bug 781874 in aptdaemon (Ubuntu Natty) "<type 'exceptions.TypeError'>: __init__() takes exactly 2 arguments (1 given)" [High,In progress] https://launchpad.net/bugs/781874
<kirkland> cjwatson: that was a drive by patch;  i fixed a one-liner papercut bug
<kirkland> cjwatson: must have inadvertently set myself as maintainer
<kirkland> cjwatson: https://bugs.launchpad.net/ubuntu/+source/newpki-server/+bug/598027
<ubottu> Ubuntu bug 598027 in Ubuntu Server papercuts "newpki-server should not recommend newpki-client" [Medium,Fix released]
<cjwatson> yeah, I read that bug but wasn't clear how much interest it implied
<kirkland> cjwatson: i have no vested interest whatsoever
<micahg> it sets the maintainer to debemail if there's no internet connectivity (at least it used to)
<cjwatson> OK, I'll just remove it then.  Thanks for checking
<kirkland> ttx filed the bug ...
<kirkland> cjwatson: no problem, thanks!
<slangasek> micahg: doh, how suboptimal
<micahg> slangasek: might have been fixed in a later version of u-d-t
<slangasek> bdmurray: I can take a look a little later this afternoon if no one else jumps on it
<hallyn> isn't lsb-base supposed to always be installed?
<slangasek> hallyn: lsb-release is, but not lsb-base
<cjwatson> they both have the same status
<cjwatson> both are Priority: required and in ubuntu-minimal; neither is Essential: yes
<hallyn> my more immediate q, i guess, is whether it should be sane for a system to not have sed :)
<cjwatson> so in practice almost certainly installed, but you must still depend on them if you're using them directly
<cjwatson> hallyn: sed is different - it's Essential: yes, and you do not need to depend on it
<hallyn> apache-common needs sed but doesn't call it out in its dependencies
<hallyn> hm
<hallyn> this box failed bc sed was not found :)
<hallyn> bug 788348
<ubottu> Launchpad bug 788348 in samba (Ubuntu) "package samba-common 2:3.5.8~dfsg-1ubuntu2.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 127" [Undecided,New] https://launchpad.net/bugs/788348
<cjwatson> in fact, policy says you should not depend on essential packages unless you need a specific version
<hallyn> good to know.
<cjwatson> hallyn: invalid state, samba isn't required to work around that situation
<hallyn> ok thanks
<cjwatson> and if you look through that log, all sorts of stuff is breaking
<cjwatson> either filesystem corruption, or the user ignored a REALLY BIG WARNING from the package management system
 * hallyn taps his fingers
<cjwatson> I suspect the former TBH
<hallyn> all due to sed missing though, that i see
 * micahg hugs the creators of the transition tracker
#ubuntu-devel 2011-05-26
<psusi> how long does it usually take to become a member of ubuntu after being approved by the dmb?
<micahg> service apport status
<micahg> psusi: ^^ should've been in -desktop
<smoser> anyone aware of something like: https://wiki.ubuntu.com/UbuntuDevelopment/Merging that handles UDD ?
<slangasek> smoser: it's in the Ubuntu Packaging Guide now: http://people.canonical.com/~dholbach/packaging-guide/html/
<slangasek> http://people.canonical.com/~dholbach/packaging-guide/html/udd-merging.html
<slangasek> barry: ^^ could you do some backlinks checking on those pages you've deleted? :)
<RAOF> slangasek: Is there any particular reason not to merge the ubuntu-multiarch branch of mesa into oneiric?  It looks like the i386 package should properly handle being included in ia32-libs for now.
<RAOF> Bah!  Stupid git-autocomplete-killing-zsh.
<slangasek> RAOF: only that it requires coordination because it will break the X server :)
<slangasek> RAOF: I meant to do it right after UDS; didn't happen; I'll likely get to it this week
<RAOF> Oh, of course.  The X server will need a rebuild to pick up the new location.
<slangasek> source changes and a rebuild, I think
<slangasek> also, I know of one outstanding bug in that branch which I should probably fix... since it renders the -dev packages useless
<RAOF> Heh.
<RAOF> I'm merging mesa now (so that it builds against libdrm 2.4.25 again); I'd be happy to merge in the multiarch branch myself if you like.
<slangasek> RAOF: well, you can, but caveat mergetor :)
<RAOF> No-one will notice if I accidentally break indirect rendering!
<slangasek> heh
<hallyn> slangasek: bug 783541, user wants to run pam_smbpass as non-root.  I assume it requires things other than access to /etc/shadow or otherwise is unsafe?
<ubottu> Launchpad bug 783541 in samba (Ubuntu) "pam_smbpass should not check that it is running as root" [Undecided,New] https://launchpad.net/bugs/783541
<slangasek> hallyn: it requires access to something even worse than /etc/shadow :)
<slangasek> hallyn: for non-root, they ought to use pam_winbind instead
<hallyn> that's what the readme said, wasnt' sure if htat did the same thing
<hallyn> I'll recommend it, thanks.
<slangasek> /var/lib/samba/passdb.tdb contains hashes that are plaintext-equivalent wrt the CIFS protocol, and are also in general easier to brute force than the ones in /etc/shadow.  pam_winbind requires running winbind locally, but... them's the breaks
<hallyn> slangasek: thx
<highvoltage>  
<wcchandler> Does testdrive need to be run as root?
<micahg> wcchandler: no
<broder> ScottK: what was the process for getting dh 7 backported to hardy? i'm starting to wonder if we're going to want dh 8 backported to lucid soon
<pitti> Good morning
<pitti> hmm, I just got a whole lot of expiry emails from Launchpad, including me getting thrown out of ~ubuntu-sponsors without any prior warning
 * TheMuso saw that also.
<pitti> all ~work-item-tracker-hackers members also expired
<TheMuso> Oh wow.
<TheMuso> Something broke.
<Simira> uh
<Simira> my Ubuntu membership expired?
 * TheMuso is asking in #launchpad.
<wgrant> Hmm.
<wgrant> The expiry script has been broken for a week or so... but I thought it was still sending warnings.
<wgrant> (a fix was just deployed)
<pitti> thanks
<wgrant> All the expiries were legitimate, just without warning :/
<wgrant> Let's see.
<Simira> I didn't get any warning... but off to work now, will take it to #launchpad later
<Simira> I'm not doing that little, although my local work doesn't show in launchpad :P
<wgrant> Looks like about 300 memberships would have expired without warning.
<Simira> ouch
<didrocks> good morning
<lifeless> win!
<RAOF> lifeless: 32?
<lifeless> 42
<sladen> wgrant: just seen that on the papercuts team too.  ~30 people expired
<ttx> cjwatson: me filing the patch on newpki-server implied no interest whatsoever. The bug was caught by one of my "what brings X libs to server installs" scripts.
<wgrant> sladen: Exactly 30 :)
<ttx> cjwatson: I actually never installed it :)
<sladen> wgrant: 1 from ~papercutters; 26 from ~papercutters-ninjas I think.  Suspect more will arrive soon
<cjwatson> ttx: OK, good :)
<doko_> seb128: do you have an idea why the python3-doc documentation isn't shown in devhelp?
<seb128> not off hand no
<pitti> it's not?
<pitti> I see "Python 3.2 documentation" in devhelp here
<apw> cjwatson, FYI I just booted up the daily from yesterday on i386 and ...well it sort of boots.  the EMS is working fine, root is moutned.  comiz seems to be crashing
<pitti> is that already using live-helper?
<apw> pitti, no idea how i would tell
<pitti> I wondered because it's not oversized although we added some packages (GTK3, etc.)
<pitti> ISTR that live-helper uses a more efficient squashfs building, saving 5 MB
<doko_> seb128, pitti: hmm, install python-doc too, and you won't see python3-doc anymore ...
<pitti> Package: python-doc
<pitti> Status: install ok installed
<pitti> this one?
<doko_> yes
<pitti> hm, it's an empty package by and large (just /usr/share/doc/)?
<doko_> pulls in python2.7-doc
<pitti> indeed, I don't see python 2.7 docs in devhelp, only 3.2
<doko_> do you see both 2.7 and 3.2 in devhelp?
<apw> cjwatson, if i run X applications by hand they work so things are half there ... compiz/unity are just dumping core of course
<pitti> doko_: is that an alternative?
<doko_> pitti: no
<pitti> lrwxrwxrwx 1 root root 21 2011-03-03 18:34 /usr/share/doc/python/html -> ../python2.7-doc/html
<pitti> lrwxrwxrwx 1 root root 24 2011-05-06 07:24 /usr/share/devhelp/books/python3.2 -> ../../doc/python3.2/html
<pitti> but that dir also has a python2.7 symlink, and I don't see that in devhelp
<doko_> $ ls -l /usr/share/devhelp/books/
<doko_> total 0
<doko_> lrwxrwxrwx 1 root root 24 2011-05-26 11:43 python2.7 -> ../../doc/python2.7/html
<doko_> lrwxrwxrwx 1 root root 24 2011-05-18 13:18 python3.2 -> ../../doc/python3.2/html
<doko_> ?
<pitti> same here
<hrw> should apparmor 'profile_load' and 'profile_replace' messages appear in dmesg?
<didrocks> ogra_: hey, small question on unity-2d: did you have a script to pack the changelog from the vcs commits?
<ogra_> didrocks, nope, did that manually, best would be to train the guys to add changelog entries with their commits though, since the packaging is in the branch anyway
<didrocks> ogra_: right, or having tarmac doing that during the merge req. ok, thanks for the answer!
<ogra_> its not like i did 100s of uploads so manual was ok
<didrocks> ogra_: yeah, it wasn't the list of bug fixes I had with unity-3d :-)
<ogra_> kaleo usually has a nice list of bugs for each of their milestones
<ogra_> so it should be easily scriptable to pull from that
<kaleo> we were slacking :;)
<kaleo> or not
<didrocks> ogra_: well, that's what I'm doing for unity-3d, take from milestones all "fix committed", retarget to next one, and suchâ¦
<ogra_> yeah, i thought so
<didrocks> ogra_: but as the vcs is clean for unity-2d, I prefer taking from the source, luke :-)
<ogra_> heh
<ogra_> k
<pitti> ev, cjwatson: will I break anythign in the installer by removing all langauge-support-* packages from oneiric?
<pitti> (they are now entirely obsolete, replaced with check-language-support)
<doko> pitti: see bug #741675, apport seem to be broken again to assign these bugs to the correct package
<ubottu> Launchpad bug 741675 in ocrfeeder (Ubuntu) "python2.7 crashed with AttributeError in convertPixbufToImage(): 'NoneType' object has no attribute 'get_colorspace'" [Undecided,New] https://launchpad.net/bugs/741675
<pitti> PythonArgs: []
<pitti> hmm
<pitti> doko: I'll have a look, thanks
<ev> pitti: yes, it will break things, but we can fix that.
<cjwatson> apw: no point telling me about compiz stuff :)
<cjwatson> pitti: we aren't using live-build yet, no
<pitti> I promised cjwatson to not break CDs, that's why I ask
<ev> err actually, perhaps not
<pitti> ev: do you know what to fix? can I add a WI for you on https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-clean-up-language-support to rip out installation of l-support-*?
<ev> I was looking at a chunk of code that's a fallback for when check-language-support doesn't exist :)
<pitti> ev: ISTR that ubiquity only installs it if it's available
<cjwatson> pitti,ev: as far as I know we don't rely on language-support-* any more; but how were you planning to seed things on those images that have more than trivial language support?
<pitti> but I better want to check before I purge all those
 * cjwatson does a fresh round of CD builds
<pitti> cjwatson: I replaced -en in the seeds for alternate/desktop I'd actually prefer a more dynamic solution using check-language-support in the CD build, but until then I'd just build the seed from check-language-support output
<apw> cjwatson, :) indeed, am happy it boots at all myself
<cjwatson> apw: incidentally, what's the "EMS"?
<apw> cjwatson, ahh EHS, emergency holographic shell
<cjwatson> pitti: about three UDSes ago I suggested using extra overrides
<cjwatson> apw: ah :)
<apw> i mixecd it up with EMH
<pitti> cjwatson: we currently have -support for 5 extra languages on the DVD, it's not too painful to replace them with the full package list right now; it's not very elegant, of course
<doko> cjwatson: was the debian-installer rebuilt in oneiric?
<pitti> cjwatson: extra overrides?
<doko> launchpad is spamming with bug mails for new imports from upstream trackers
<cjwatson> doko: yes
<cjwatson> pitti: like Task only not
<cjwatson> pitti: I guess you haven't looked at other flavours then?
<cjwatson> edubuntu has dvd-live: * /^language-support-[^-]+$/
<pitti> I need to convert those before removing l-s, yes; currently doing ubuntu, the other flavours are on the list
<doko> cjwatson: wondering about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623710
<ubottu> Debian bug 623710 in binutils "New binutils break library reduction in d-i" [Serious,Open]
<pitti> cjwatson: could I add a dvd-langsupport and dvd-live-langsupport file, generate that with check-language-support, and add these to STRUCTURE as dvd/dvd-live dependency?
<pitti> might be cleaner than editing it in-place
<doko> Daviey: please could you merge sysvinit?
<cjwatson> pitti: I guess, yeah
<cjwatson> doko: I'll have a look at that today
<cjwatson> seems more likely to be a mklibs problem, but we'll see
<pitti> cjwatson: then we'll actually include the full set of necessary packages (l-s was quite incomplete, it didn't catch the conditional depends from check-language-support)
<cjwatson> pitti: or else get the live builder to run check-language-support and install stuff from that; but it's probably better to do that after switching to live-build
<cjwatson> rather than doing the work twice
<pitti> *nod*
<pitti> until then a generated seed will do
<Daviey> doko, I didn't plan to :/
<Daviey> doko, Is it unfair for me to suggest this is a foundations area?
<doko> Daviey: is it unfair to suggest the axis2c and erlang build failures to be a server area?  ;-P  and maybe other build failures
<Daviey> doko, no, axis2c is a linaro area :)
<doko> Daviey: eucalyptus is linaro? interesting ...
<Daviey> doko, no, but they fixed the FTBFS for axis2c.
<Daviey> doko, It does look like more of a complex merge than we'd prefer.  I am happy to help.
<doko> Daviey: sorry, I don't see the linaro relationship, just because janimo did fix a failure, which the server team didn't address. please see the history of this package
<cjwatson> doko: no more than sysvinit has a server relationship :)
<cjwatson> let's not get all team-oriented about merges when we don't need to
<cjwatson> we're all developers
<cjwatson> sysvinit seems likely to be bound up with the /run transition; I haven't checked lately where Keybuk has got to with that
<doko> right, I won't touch this then for now
<Daviey> doko, Seems like this merge would greatly benefit from UDD... sadly the package-importer is blocked on it.  bum.
<Daviey> doko, I've prodded the UDD admins into fixing the bzr branch..  Hopefully that'll be resolved by the time we have some news from Keybuk.
<www2> hi i have a problem with cmake in my x68-64
<doko> Daviey: thanks!
<www2> * x86-64
<mvo> DktrKranz: hey, when you have a bit of time I would appreciate a quick look at lp:~mvo/gdebi/gtk3
<cjwatson> doko: I don't seem to be able to reproduce #623710 on unstable/i386; but it's possible that it was slightly more architecture-specific than claimed in the bug.  Asking Jurij ...
<doko> cjwatson: and maybe joey too? it wasn't only seen on powerpcspe
<cjwatson> well, I asked on #debian-boot, so others can chime in
<cjwatson> the original report was amd64
<cjwatson> I don't have a suitable testbed to hand for that right nw
<cjwatson> *now
<soren> xen is failing to build on Ubuntu apparantly because for some reason -Wl,-Bsymbolic-functions is being passed to ld (rather than GCC). Before I go diving into that, is that a common well-understood problem?
<geser> soren: sound like $(LD) $(LDFLAGS) in the makefile instead of $(CC) $(LDFLAGS)
<geser> when linking
<soren> geser: That would make it fail in Debian, too, wouldn't it?
<cjwatson> there are a few packages that do that.  If it's impractical to have them use gcc as the linker instead, then 'unexport LDFLAGS' in debian/rules is a workaround
<cjwatson> no, Debian doesn't default to -Wl,-Bsymbolic-functions in dpkg-buildpackage
<soren> No but..
<soren> err..
<soren> That is our default for... what? LDFLAGS?
<cjwatson> yes
<soren> Oh
<soren> Wow, ok.
<cjwatson> which the vast majority of packages give to gcc, so it's formatted for use by gcc
<doko> soren: as cjwatson says. ld is directly used in xen. or you strip the -Wl, from LDFLAGS
<cjwatson> but of course the -Wl, breaks ld
<soren> I wouldn't have expect "-Wl," in LDFLAGS :)
<geser> soren: it would fail in Debian too if LDFLAGS would contain -Wl,... there too
<cjwatson> soren: if you don't put -Wl, in LDFLAGS (and it's non-empty), then most of the rest of the archive breaks
<cjwatson> xen is one of the exceptions
<mterry> kees, can you please add me back to ubuntu-sponsors?  I got expired without noticing
<soren> Right, it makes sense now. I just thought LDFLAGS is what would passed to ld, not what would be passed to gcc to get it to pass it on to ld.
<soren> No problem, I just misunderstood LDFLAGS, apparently.
<soren> mterry: Just fyi, not your fault. The "you're about to expire" thing in LP has been broken for the last week, iirc.
<mterry> soren, ah, odd
<soren> mterry: (cf a conversation a few minutes ago in #launchpad)
<jml> hello
<jml> some community contributors are interested in implementing a wiki within Launchpad
<soren> jml: \o/
<jml> I thought, gosh, Ubuntu has a big wiki and might be able to help us avoid some of the problems that they've had
<jml> who specifically should I speak with in order to get that kind of information?
<soren> cjwatson: I'm not completely sure what -Bsymbolic-functions does. Instead of just unexporting LDFLAGS, should I instead tweak it to just read "-Bsymbolic-functions" (i.e. strip off the "-Wl,")?
<cjwatson> it's documented in ld(1)
<cjwatson> I don't feel all that strongly either way though.  Across the whole distro, it's an efficiency win; for a single package, meh
<cjwatson> jml: isn't that the kind of scope creep you're trying to avoid?
<cjwatson> I'd be pretty worried about implementing YA wiki rather than e.g. borging in some existing software
<soren> In this day and age, people seem to consider a wiki a required part of a project hosting site.
<jml> cjwatson: oh yeah, I probably want the solution to be borging in some existing software
<jml> cjwatson: but I also want it to be a much, much better borging than loggerhead was for code browsing
<cjwatson> jml: I'm not sure whom you'd want to speak with.  Maybe the sysadmins?
<jml> so getting clear on requirements is a good first step
<elmo> step #1: avoid moin
<elmo> step #2: see step #1
<jml> heh
<elmo> :-P
<cjwatson> I think "avoid plone" ought to be in there somewhere too
<soren> cjwatson: Thanks for your help!
<jml> elmo: what about moin makes it so bad?
<doko> cjwatson: I would like to modify vendor flags in dpkg to pass -D__BUILDD_<random-string>__  in CFLAGS, CXXFLAGS, FFLAGS, and -Wl,-z,buildd-<random string> in LDFLAGS, to catch packages which don't honour the vendor flags
<jml> cjwatson: that's a given for any Launchpad work.
<cjwatson> doko: I'd prefer that go through #debian-dpkg I think
<cjwatson> though I'm a bit concerned that that sounds like it adds a certain amount of footprint to every compiled binary
<doko> well, to the log, not to the binary
<elmo> jml: I'm mostly being facetious - we're stuck on an old version of moin (not for long) and it hurts.  but moin doesn't have many wikis running at ubuntu scale and has lots of painful areas in terms of scaling (search, page subscriptions, page layout on disk)
<cjwatson> doko: hmm, well, that's better
<cjwatson> doko: still, once multiarch lands, we should be in sync with Debian dpkg at long last, so it would be nice to preserve that property :)
<doko> and debian could argue, that you can change the config file
<cjwatson> doko: no, Debian is much more likely to argue that it should go into the Ubuntu vendor hooks maintained as part of the dpkg repository
<cjwatson> same place -Wl,-Bsymbolic-functions lives
<jml> elmo: thanks. it's good to know. I'm not sure whether I should be insisting that whatever these guys come up with has to be Ubuntu scale.
<doko> ok, so add it to the vendor hooks, and then submit it to debian
<elmo> jml: oh - and how the hell did I forget this - it's very bad at being cachable for anonymous users
<jml> (if I put the wiki page in /dev/null, does that make it Ubuntu scale?)
<elmo> we had to do some truly sick things to get it to cache as much as we have it caching now
<cjwatson> doko: other way round would be nice, to avoid churn in case they suggest changing the name :)
<Alexqw> Does anyone know if apt 0.7.26 will be released for Lucid?  My labs are affected by bug #250909, and we cannot deploy some of our software as a result.
<ubottu> Launchpad bug 250909 in apt (Ubuntu) "Apt-get does not support packages of 2.5 gig..." [Medium,Fix released] https://launchpad.net/bugs/250909
<doko> well, ok ...
<cjwatson> Alexqw: in general, new versions don't get released directly, but asking for a particular fix to be backported is different
<cjwatson> mvo: ^-
<cjwatson> I've created a lucid task on that bug
<Alexqw> cjwatson: ok.  that makes sense.  Should I open a new bug in this case?  it seems redundant.
<Alexqw> cjwatson: oh, excellent ;-)
<cjwatson> Alexqw: please do not open a new bug
<jml> elmo: thanks.
<Alexqw> cjwatson: I'll be sure not to.  Thanks for your help
<cjwatson> (I mean, for this. :-) )
<Alexqw> heh
<bluefoxicy> heh I don't actually know what cflags stuff is compiled with on Ubuntu
<jdstrand> hrw: re apparmor> yes, that is completely normal
<bluefoxicy> ah well, I guess it doesn't much matter as long as everything is -O2 -fomit-frame-pointer -fstack-protector -Wl,-O1 and executables are -Wl,-pie
<bluefoxicy> although some silly people like to use -fstack-protector-all o_O
<doko> maybe you should turn on verbose build logs, then you see what you get
<bluefoxicy> if I build something here it'll build it exactly as it's built on the build servers?
<bluefoxicy> doko wa doko desu ka?
<DktrKranz> mvo: hi! sure, I'll have a look this evening
<bluefoxicy> heh... doko wa doko ni sundeimasu ka?
<mvo> Alexqw: hi, we can make a SRU of this particular fix
<Alexqw> mvo: great.  I'm glad to hear
<mvo> Alexqw: I need to look at this though, it maybe that it actually requires a abi break in which case its not something we can do easily
<Alexqw> mvo: ok.  I appreciate you taking the time to look at it.  Hopefully it doesn't cause problems.
<real_ate_> hi all... i'm just wondering, what is the "correct" way for a deb to replace default configurations? I'm creating an ubuntu deb for on of our company's applications and it needs to replace the default configuration of one of its dependancies... but i keep getting a message: trying to overwrite '/etc/tilecache.cfg', which is also in package tilecache 0:2.10-1~jaunty1
<hrw> jdstrand: thx
<lool> mvo: BTW thanks for the apt upload to lucid-proposed!
<mvo> lool: yw
<mvo> pitti: quick question, is there anything holding back software-center from entering natty-updates?
<pitti> mvo: no, it's past 7 days now, should be fine
<pitti> mvo: hm, why is bug 776706 not fixed in oneiric, but the other three are?
<ubottu> Launchpad bug 776706 in software-center (Ubuntu Natty) "Software Centre doesn't show ratings on a fresh install" [High,Fix committed] https://launchpad.net/bugs/776706
<pitti> I can't copy it to oneiric, it's got a newer version
<chrisccoulson> pitti - could you copy the firefox update in natty-proposed to natty-updates please? :)
<pitti> ah, you guys got me; ok, dropping stuff and doing SRU :)
<geser> broder: Hi, can libassuan2 be dropped in favour of libassuan0 (now also at version 2.0.1 in oneiric)? see also bug #788473
<ubottu> Launchpad bug 788473 in libassuan2 (Ubuntu Oneiric) "package libassuan0 (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/libassuan.so.0.1.0', which is also in package libassuan2-0 2.0.1-0ubuntu2" [High,Triaged] https://launchpad.net/bugs/788473
<mvo> pitti: that bug is fixed in oeniric, its a leftover, sorry
<pitti> great, thanks for checking
<pitti> cjwatson: FYI, all seeds updated to drop language-support-* (mythbuntu and ustudio don't pull in any, so I left those untouched)
<pitti> cjwatson: so what I'd like to do now is to drop l-s-* from oneiric, then wait for the next daily CD build, and test them to see what breaks
<pitti> cjwatson: but you wanted to build a CD right now, so I better postpone the removal for a bit?
<smoser> if a debian package (python-boto) does not use a patch system, would it be generally preferable to continue that in ubuntu delta? or would it be better to add a patch system to maintain the debian->ubuntu delta more easily.
<pitti> stgraber: btw, to remove a branch from teh sponsors list, set the status to "work in progress" (if it needs fixing), or "rejected" (if it's broken)
<stgraber> pitti: how can I dod that when I'm not part of ubuntu-branches or ubuntu-sponsors? Is simply adding a review enough to have it gone?
<stgraber> *do
<pitti> stgraber: ah, you can't change the status?
<pitti> stgraber: I changed https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/mountall/natty-201104141818/+merge/57748 to "rejected" now
<stgraber> pitti: right, you need to be in ~ubuntu-branches to do it apparently (you are a member of it through the TB)
<pitti> ugh, that would be qutie strong
<pitti> I think you only need to be able to upload the package
<pitti> well, that's how it should be, anyway
<pitti> set https://code.launchpad.net/~holizz/ubuntu/natty/gnome-terminal/cursor-blink-mode-ui/+merge/58904 to rejected as well
<stgraber> I agree, seems like we're missing some LP bits to have that working :)
<pitti> stgraber: for the bugs, it should be enough to unsubscribe the sponsors team
<stgraber> which you can only do when you are part of the team, right?
<pitti> ah, right
<pitti> and I'm not any more since this morning, when LP unhelpfully kicked out tons of people without prior warning
<pitti> and no DJ Holy Holbach around to add me back
<stgraber> kees, TheMuso and nhandler are also administrators of ubuntu-sponsors so they should be able to add you back to it
<cjwatson> pitti: I did a CD build earlier today
<pitti> nhandler, kees: can you please add me back to ~ubuntu-sponsors? thank you in advance!
<pitti> cjwatson: ah, good; I don't see one in http://cdimage.ubuntu.com/daily-live/ (just a failure email)
<cjwatson> pitti: let me check then
<stgraber> nhandler, kees: Can you also add me to that team? would be quite useful when doing patch pilot. Thanks!
<geser> smoser: if a package doesn't use a patch system it's preferred to keep it that way (else you end with some patches applied directly while others through the patch system)
<cjwatson> smoser: we've generally considered (a) adding a patch system to be a change in packaging style (b) changing packaging style in an Ubuntu delta to be rude)
<cjwatson> pitti: ah, yeah, it failed due to the same seed breakage
 * cjwatson tries again
<stgraber> pitti: thanks for rejecting the merge proposals
<smoser> geser, cjwatson thank you.
<smoser> so, in that case, would it still be preferred to carry the list of ubuntu delta in the changelog ?
<broder> geser: the soname is going...down? that seems odd. but i don't know anything about the package - the changes i was making were just for multiarch stuff and didn't actually touch the software
<cjwatson> smoser: yes, that should be done regardless
<geser> broder: libassuan was for a  long time on version 1.0.5-1 and got only recently updated to 2.0.1, while Ubuntu in between packaged it as libassuan2
 * broder shrugs
<broder> pitti, stgraber: there's a bug where people that can upload a pkg can't change the status of MPs against the release pocket branches post-release, but i can't find the bug at the moment
<geser> broder: I hoped you know if we can drop libassuan2 (and move any delta to libassuan) as you were one of two person touching it
<broder> pitti, stgraber: ah - bug 612391, there it is
<ubottu> Launchpad bug 612391 in Launchpad itself "Cannot change status for merge proposals that target a released series" [High,Triaged] https://launchpad.net/bugs/612391
<broder> geser: i was only applying a rote change to it along with a bunch of other packages. i didn't dig into it any more than that
<geser> ok, thanks anyways
<stgraber> broder: thanks for the link!
<bdmurray> mvo: do you know if bug 659438 is really fixed?
<ubottu> Launchpad bug 659438 in aptdaemon (Ubuntu) "Installation/Removal fails because of package which could not be located (failure in apt.Cache.required_download)" [Critical,In progress] https://launchpad.net/bugs/659438
<mvo> bdmurray: let me check
<bdmurray> mvo: thanks some duplicates have been coming in recently
<mvo> bdmurray: oh, ok :/ that is bad
<pitti> hey, a working classic gnome on the current oneiric live CD in kvm
<bdmurray> mvo: yes, that's what I'd thought
<dpm> hi pitti, I've just been talking to kyleN re: the conversation of selectively enabling the translation of universe packages in LP, and he was telling me that this would be useful for OEM. There is no WI for that on the China ISO spec for that, but given that you mentioned that it'd be a 15 m change in pkgbinarymangler, do you think we could go for it? If so, shall I add a WI or file a bug for it? I'd then coordinate it with the LP guys for the work that
<dpm>  would be needed on the LP side
<pitti> dpm: fine for me to add these WIs to the cleanup-language-support spec, fits better there
<pitti> or just file it as a wishlist bug and assign to me
<pitti> I don't mind which, whatever you prefer
<pitti> with a bug we could also have a LP translations task
 * pitti -> bbl
<dpm> pitti, cool thanks. I'll do that now, then.
<chrisccoulson> bdrung_, is mozilla-devscripts broken in oneiric? https://launchpadlibrarian.net/72460854/buildlog_ubuntu-oneiric-i386.webfav_1.17-0ubuntu6_FAILEDTOBUILD.txt.gz :)
<stgraber> cjwatson: just talked with dpm, the reason why edubuntu-live's translation template isn't imported in LP is because the package is in universe. I'll have to file a MIR for it apparently.
<cjwatson> ok
<bdrung_> chrisccoulson: that looks like a bug in python-librdf
<chrisccoulson> bdrung_, do you want to take a look at that, or shall i?
<bdrung_> chrisccoulson: you. it's outside of my scope.
<chrisccoulson> ok, no problem
<james_w> jamespage, hi, https://blueprints.launchpad.net/ubuntu/+spec/server-o-jonas refers to "fbenoit", which isn't a valid LP account. Does that person have an LP account?
<soren> james_w: ~florent-benoit probably
<soren> james_w: seeing as he's subscribed to that very blueprint it seems like a reasonable guess :)
<james_w> soren, ah, good thinking!
<james_w> thanks
<Alexqw> mvo: I read the updates in bug 250909.  Does this mean that it's a low likelihood that the fix will be back-ported to Lucid?
<ubottu> Launchpad bug 250909 in apt (Ubuntu Lucid) "Apt-get does not support packages of 2.5 gig..." [Medium,Triaged] https://launchpad.net/bugs/250909
<mvo> Alexqw: unfortuantely yes, it should be straightforard to apply the diff, but I don't think we can make this a official SRU as it will break unreleated software (without rebuilds and patches)
<mvo> Alexqw: in what context do you need the feature? i.e. large scale deployment or just one (or a small number) of machines?
<Alexqw> mvo: hmm. ok.  Do you have any suggestion for how I should deploy packages larger than 2.5 GB to 64bit lucid clients then?
<Alexqw> mvo: deploying to dozens of machines
<Alexqw> mvo: so not hundreds, but enough to be a pain manually
<mvo> Alexqw: would it be a option to build the updated apt in a PPA just for those machines?
<Alexqw> mvo: yes
<mvo> Alexqw: I'm happy to assist with that so that the other people suffering from the bug can use the PPA
<mvo> too
<Alexqw> mvo: excellent.
<Alexqw> mvo: I don't have a public ppa setup, just an internal repo
<SpamapS> If the UDD branch for a package is out of date, is the only way to bring it back up to date to go through the publishing history, manually doing package imports?
<lool> juliank: Hey there, I am looking at fixing https://bugs.launchpad.net/update-manager/+bug/610820 in natty/maverick but it's not yet fixed in oneiric; do you have an ETA for oneiric?  Should I grab the patch and apply it on top of current oneiric sources?  I understand it's a matter of replacing all Py_BuildValue("k", ...) with MkPyNumber?
<ubottu> Ubuntu bug 610820 in python-apt (Ubuntu) "Download size discrepancies" [Undecided,Fix committed]
<juliank> lool: It's in Debian (experimental, 0.8.0~exp2), so it basically needs to be merged. But as 0.8 breaks API, you may want to do something else
<lool> juliank: I was wondering whether there is a plan to merge 0.8 in Ubuntu this cycle
<lool> mvo: Might also be something you track?  ^
<juliank> lool: Better this cycle than next one.
<lool> that's right
<juliank> lool: APT 0.8 will hit unstable soon, oneiric could follow afterwards
<lool> juliank: Ok; thanks
<lool> juliank: Is it ok if I upload something like your patch in the mean time?
<juliank> lool: There's also always the option to reenable the 0.7 API. The code still exists.
<mvo> lool: I have a local branch with the 0.8 merge that keeps the old api around
<lool> adjusting the Py_BuildValue("k", ...) call sites
<mvo> I used it for local test, but it should be fine
<lool> mvo, juliank: To clarify, I'm contemplating SRU-ing this bug, first step is getting it fixed in oneiric, which is why I'm asking about timeline etc.
<juliank> lool: You can always just cherry pick the patch. It should work on 0.7.100 as well, the differences to 0.8 are not really large.
<lool> ok thanks
<tkamppeter> sabdfl, ping
<mvo> lool: SRU should be fine, but given the nature of it we need to carefully regression test
<fta> doko, hi, is ld-gold still experimental?
<doko> fta: I don't know; maybe I should do daily builds of binutils and gcc-4.x on all series to find out
<fta> doko, for chromium, ld-bfd is way too slow, it takes so long to link the final binary that it makes the builders timeout and ftbfs
<lool> mvo: yes; is the python-apt testsuite a good base for that?  it seems it's run during build
<fta> doko, and upstream chromium now uses it anyway, so i just moved my dailies to use it too
<mvo> lool: it should be, but I'm not sure how well this part if covered by the tests
<doko> fta: well, then you have the answer. if you see issues, please file reports both upstream and for ubuntu
<fta> doko, ok. i'm slightly concerned by dists i don't use / can't check
<mvo> lool: fwiw I upload my merge now, but its ftbfs because of some py3 issue, I need to look into that
<juliank> mvo: I also just wanted to upload 0.8 to unstable, but the Alioth changes broke the pre-build script - is this not happening in the ubuntu branch?
<lool> mvo: I pushed python-apt with the patch some minutes ago
<lool> mvo: about 4 minutes before you said you're uploading your merge; would you mind including the diff?
<lool> mvo: will provide a debdiff in a sec
<juliank> lool: mvo: The ubuntu branch seems to run utils/get_debian_mirrors.py > data/templates/Debian.mirrors as well and should thus be broken as well.
<lool> mvo: http://paste.debian.net/118065/
<lool> juliank: is thata different bug?
<juliank> lool: We can't fetch the Debian mirror list from Alioth, as their redirects are broken and checkout is disabled; pre-build.sh thus fails. This makes me wonder how you got it to build, if the pre-build stage fails
<juliank> lool: OK, it's commented out now, my branch was outdated.
<lool> mvo: sorry, ignore the debdiff, you have the changes from 0.8
<mvo> juliank: I disabled the update-mirror for debian too, indeed. I looked briefly into this but it seems its disbled completely on alioth to just get the raw file from cvs instead of the markup version. kind of anoying
<lool> juliank: I didn't testbuild it
<mvo> juliank: just fyi https://launchpadlibrarian.net/72473733/buildlog_ubuntu-oneiric-amd64.python-apt_0.8.0~exp4ubuntu1_FAILEDTOBUILD.txt.gz - the bug itself looks like a py3 issue, I wonder why 2to3 did nt catch it
<mvo> lool: sorry for the duplication, I should have pushed my branch earlier
<juliank> mvo: It took the wrong file. It should look in ../build/lib.linux-x86_64-3.1, but looked in ../
<juliank> mvo: 3.2 in this case
<lool> mvo: are you using the UDD branch?
<mvo> lool: I use lp:~ubuntu-core-dev/python-apt/ubuntu, thats a branch from the upstream debian bzr
<lool> mvo: You might want to put that in Vcs-bzr
<juliank> lool: It's at least documented in the "Contributing to python-apt" part of the documentation.
<bdrung_> RoAkSoAx: is the sponsorship still too slow even with the patch pilots?
<RoAkSoAx> bdrung_: sometimes. Depends who;s piloting
<lool> juliank: you presuppose I would read any kind of package specific doc before uploading a patch  :-)  if anything, debian/README.source could mention it
<RoAkSoAx> bdrung_: at the moment, I have couple merges sitting there for a week
<RoAkSoAx> bdrung_: maybe everybody is busy with other stuff due to UDS, but I've faced this before until the point that I had to nag ppl a lot to be able to get my fix uploaded
<RoAkSoAx> bdrung_: it has obviosly improved a lot when patch pilot was introduced
<bdrung_> urg, the sponsors queue is full again (110 items)
<seb128> bdrung_, new cycle, UDS, dholbach not being around recently and james_w buggy requests contributed to put it back there yes
<bdrung_> seb128: what should i do with james_w requests like https://code.launchpad.net/~ubuntu-branches/ubuntu/feisty/gnumeric/feisty-201105201650/+merge/61811 ?
<seb128> not sure, cjwatson wrote some details about those in his previous piloting summary, maybe read his email
<james_w> bdrung_, given that no-one is going to be uploading to feisty that can likely be rejected without looking at it
<james_w> bdrung_, generally though look at the diff and see if it brings in something useful
<james_w> if there is something odd (like in this case that it has no unmerged revisions), please file a bug at https://bugs.launchpad.net/udd/+filebug and point to the merge proposal
<bdrung_> RoAkSoAx: but sync request are processed fast ;)
<RoAkSoAx> bdrung_: hehe :)
<bdrung_> james_w: bug #788731 - should i do that for the other ones too?
<ubottu> Launchpad bug 788731 in Ubuntu Distributed Development "Empty merge proposal for gnumeric" [Undecided,New] https://launchpad.net/bugs/788731
<james_w> bdrung_, anything that is an empty merge for an old release is likely the same problem. If you see other symptoms then another bug is probably appropriate
<james_w> thanks!
<bdrung_> james_w: what should i do if there is a commit, but no changed content?
<james_w> that's likely not wanted either, so a bug and rejection is likely appropriate
<kees> pitti, stgraber, nhandler, mterry: yikes, I saw all the unsub emails. should I just subscribe everyone back to it?
<mterry> kees, seems right
<lool> juliank, mvo_: I tested the oneiric package and a maverick build with the patch, both fixed the issue exposed by lp610820.py in the bug; thanks!
<bdrung_> RoAkSoAx: you should mark your debdiffs as patches
<lool> mvo_, juliank: Uploaded python-apt to natty-proposed and maverick-proposed -- pending approval etc.
<RoAkSoAx> bdrung_: I usually do (and wait long to get sponsored :)) Today testing something different hehe
<bdrung_> RoAkSoAx: i recommend to ask the cluster-glue maintainers to run wrap-and-sort
<RoAkSoAx> bdrung_: will do
<RoAkSoAx> thanks for looking at it
<bdrung_> np
<RoAkSoAx> bdrung_: guess he didn't look that there was a bug filed against cluster-glue cause my merge bug report is older than that
<bdrung_> RoAkSoAx: yes
<smoser> anyone know what colors mean at https://merges.ubuntu.com/main.html ?
<bdrung_> smoser: IIRC the complexity
<bdrung_> the greener the simpler
<smoser> i'm sure its not perfect, but 'hostname' (merge at https://code.launchpad.net/~smoser/ubuntu/oneiric/hostname/merge-debian) surely woulldn't have earned a "pink"
<bdrung_> right
 * micahg thought it was based on priority/essential
<bdrung_> that sounds more plausible
<micahg> hostname is priority: required
<cjwatson> yes, it's priority
<smoser> i was looking to merge adduser , it has conflicts (http://paste.ubuntu.com/613393/) that are all translations (http://paste.ubuntu.com/613394/)
<smoser> how should those be handled ? does launchpad translations affect that ? I'm complete newbie to translations.
<geser> hmm, for fixing bug 788473, is a Conflicts enough or should it be Conflicts+Replaces?
<ubottu> Launchpad bug 788473 in libassuan2 (Ubuntu Oneiric) "package libassuan0 (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/libassuan.so.0.1.0', which is also in package libassuan2-0 2.0.1-0ubuntu2" [High,Triaged] https://launchpad.net/bugs/788473
<micahg> geser: I think the policy manual says Breaks + Replaces in cases like this actually
<micahg> geser: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
<SpamapS> re libassuan .. isn't the bug that libassuan2-0 shouldn't have that file?
<geser> SpamapS: yes and no, libassuan2 should get removed now from the archive but this doesn't automagically remove it from systems where is installed, libassuan0 needs to be told to replace libassuan2-0
<SpamapS> Replaces should be enough then..
<SpamapS> though yeah, Breaks + Replaces is probably a more complete solution.
<geser> ideally libassuan2-0 should get removed from those systems having it installed
<micahg> SpamapS: replaces just replaces files, not remove packages
<SpamapS> micahg: right, he wants it off.. Breaks+Replaces it is then.
<geser> thanks, Breaks+Replaces does what I need
<micahg> bdrung_: BTW, libnet-ssleay-perl was promoted to main in oneiric, so it could remain a recommends of devscripts now
<bdrung_> micahg: i will remember it for the next merge
<NCommander> @pilot on
<udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<NCommander> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: NCommander
<NCommander> *ALWAYS does that*
<NCommander> bah
<JFo> :)
<NCommander> Anyone need anything sponsoring before I go fishing in the queues :-)?
<geser> NCommander: bug 788473 if you want
<ubottu> Launchpad bug 788473 in libassuan (Ubuntu Oneiric) "package libassuan0 (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/libassuan.so.0.1.0', which is also in package libassuan2-0 2.0.1-0ubuntu2" [High,Triaged] https://launchpad.net/bugs/788473
<ssweeny> hey folks, can anyone tell me if aufs is still the preferred unioning solution for the livecd?
<broder> ssweeny: it is currently, although my understanding is that overlayfs is close to being merged into the kernel, at which point it sounds like we might switch to that
<ssweeny> broder, cool, thanks. does it look like that will happen for oneiric?
<broder> ssweeny: i couldn't say
<ssweeny> broder, fair enough. appreciate the help
<achiang4> micahg: ping, question about firefox in lucid. the only updates in recent history have been security updates, not anything like performance improvements or such, right?
<achiang4> micahg: i'm trying to find the delta between 3.6.15 and 3.6.17
<micahg> achiang4: well, they've been minor version updates, which include security fixes
<micahg> achiang: firefox includes bug fixes as well
<micahg> achiang: is there a regression?
<achiang> micahg: no regression, don't be scared. :)
<broder> Laney: did you test the backport in bug #622836 or just change the title?
<ubottu> Launchpad bug 622836 in lucid-backports "Please backport codeblocks 10.05" [Undecided,Confirmed] https://launchpad.net/bugs/622836
#ubuntu-devel 2011-05-27
<pitti> kees: thanks for adding me back
<pitti> good morning
<elmo> 0
<cpatrick08> i think oneiric will be better than natty even in this very early stage of development it is better than natty
<cpatrick08> is there any way to get the gnome-shell on oneiric
<didrocks> good morning
<mdke> does anyone have an idea what might be causing bug 788949. I've seen a couple of them for ubuntu-docs but have no idea what the dpkg error message means
<ubottu> Launchpad bug 788949 in ubuntu-docs (Ubuntu) "package ubuntu-docs 10.10.4ubuntu0.1 failed to install/upgrade: failed to stat (dereference) existing symlink `/usr/share/gnome/help/keeping-safe/vi/keeping-safe.xml': Input/output error" [Undecided,New] https://launchpad.net/bugs/788949
<geser> mdke: looks like the harddisk is dying if I read the dmesg correctly
<mdke> geser: aha, what do I look for in there? I have a couple of other similar bugs that I need to check too
<geser> mdke: see the lines with "sd 0:0:0:0" and "ata1.00" at the end of dmesg.txt where the kernel logs it unsuccessfull attempts to write something to the harddisk
<mdke> geser: that's great, thanks a lot for the help
<DktrKranz> mvo: hi! I checked your branch yesterday, it looks good. I also tested it with a GNOME3 box, and worked fine
<mvo> DktrKranz: awsome, thanks a lot, sounds like a candidate for uploading then :) what is the state of the gir stuff in debian? is it in unstable yet or would this be experimental?
<DktrKranz> mvo: still experimental, there are some pieces still to be fixed, and release team to assign a spot to schedule transitions
<DktrKranz> probably, it won't happen before 3.2
<DktrKranz> some pieces are in unstable, but at least not vte. so experimental is the only way right now
<Laney> broder: No, I didn't. But it looked OK to me (since there are no rdepends and the reporter says he test it runs)
<Laney> tested
<mvo> DktrKranz: ok, thanks. that should be fine, I guess its best to push it in ubuntu first then so that it gets wider testing (but I feel its pretty solid)
<micahg> good morning pitti, would you be able to pocket copy chromium from -proposed to -security/-updates for lucid-natty, bug 787846
<ubottu> Launchpad bug 787846 in chromium-browser (Ubuntu Natty) "11.0.696.68 -> 11.0.696.71" [High,Fix committed] https://launchpad.net/bugs/787846
<pitti> micahg: yes, can do
<cjwatson> mdke: I've no idea why we still file bugs for "Input/output error" - it's defined to mean physical read/write errors, i.e. almost exclusively not software bugs
<micahg> pitti: thanks
<DktrKranz> mvo: sounds good. we could also asking for testing via planet debian, I see it attracts more people
<cjwatson> I assume it's simply because at the apport level it's awkward to figure out reliably which errno was involved, e.g. due to translations
<pitti> micahg: all done
<micahg> pitti: great, thanks, have a good day
<zaytsev> hi! does anyone know of the top of their head, how the livecd decides if it will autologin in casper or show the dialog "install or try ubuntu blah-blah-blah"?
<cjwatson> zaytsev: the 'maybe-ubiquity' boot parameter causes the latter to happen
<zaytsev> I am trying to remaster the official natty livecd as per LiveCDCustomization wiki page and everything was fine, but now I updated the packages in the chroot and somehow the resulting image autologins without showing this standard window
<zaytsev> cjwatson, oh, thanks! it means that somehow I unknowingly changed the boot options :-/
<cjwatson> zaytsev: our gfxboot theme adds 'maybe-ubiquity' if it's booting in splash mode, which happens if 'hidden-timeout=1' is in /isolinux/gfxboot.cfg
<cjwatson> it's a bit convoluted, I'm afraid
<infinity> Just a tad...
<infinity> I know how it works, and that still confused me. :P
<cjwatson> it confuses me and I wrote it
<zaytsev> oh right, so I have hidden-timeout=2 in gfxboot.cfg, I didn't change it though. It was like this in the official media.
<cjwatson> =2 should be fine too
<StevenK> infinity: What's wrong with Canadian lamb? :-)
<infinity> StevenK: A general lack thereof.
<infinity> StevenK: Canadian ranchers are silly and keep letting them grow up.
<infinity> StevenK: And mutton is crap.
<cjwatson> zaytsev: also I don't think it will take you into the try/install dialog if you press a key at the CD boot splash screen to get the boot menu
<zaytsev> nah, I didn't press a key and still it autologins :-/ I am trying to boot my kvm test vm off the official media and it shows the prompt. when I do the same with my remastered one it doesn't. and now that I sort the files by date the only thing that really changed is the chroot which I updated with the latest packages from natty-updates. what a looser...
<cjwatson> zaytsev: you could just hardcode maybe-ubiquity into the kernel parameters
<cjwatson> (kind of wrong, but whatever)
<fta> doko_, hi, here are my ld-gold results: http://paste.ubuntu.com/613663/
<fta> doko_, i wonder if it has to do with the PIE hardening
<doko_> fta: ok. please cc kees on hardening issues too
<apw> ev, are you aware that usb-creator-gtk is now triggering 4-5 "not permitted by policy" popups per install ?
<zaytsev> cjwatson, so I should add maybe-ubiquity to the first (default) boot option in /boot/grub/loopback.cfg ? and how to reliably achieve the opposite effect, is there something like no-ubiquity ?
<zaytsev> the thing that bugs me here is that I updated the chroot and now it autologins. tomorrow I will do this again and it will show ubiquity instead. I would kind of like a defined behavior.
<ev> apw: yeah, it was to fix a security issue.  I plan to dig into making it less of a pain in the ass a bit later in the cycle
<apw> ev, eek
<cjwatson> zaytsev: wait, you're using grub to boot this?
<zaytsev> cjwatson, I have no idea :-) I have downloaded the original image and use whatever it uses. then I found an article on Ubuntu wiki how to unsquashfs the filesystem and make your customizations (install/update packages). then I remastered the image again using the updated chroot
<zaytsev> also, the difference is that when the image that boots to ubiquity starts, it changes purple background to black and yellow letters and when it autologins directly it stays purple
<cjwatson> zaytsev: /isolinux/isolinux.cfg, then
<cjwatson> zaytsev: if I were you, rather than just comparing file lists, I would loop-mount the old and new images and use 'diff -ru' to compare them
<cjwatson> one of the changes listed by that will be responsible
<zaytsev> cjwatson, in isolinux.cfg I would just add a line that says maybe-ubiquity ?
<infinity> diff -ruN even, could be a new file poviding an override to something.
<zaytsev> cjwatson, ok, reasonable I will do that. thanks.
<cjwatson> zaytsev: sorry, I meant /isolinux/txt.cfg.  change the 'append' line corresponding to the relevant menu label.  (but analyse the image with diff first; this is just a fallback option for if you can't find what changed.)
<private_> I am looking for a programmer to hire to clean up some code
<zaytsev> hmm, manifests are different (updated packages), filesystem size, filesystem AND /isolinux/isolinux.bin has a different checksum. weird.
<zaytsev> and compared to the original image, there are even more differences. I wonder it it's rsync's fault, maybe I called it with the wrong flags. ok, will try to figure after lunch
<zaytsev> actually, it seems that the md5sum generation command is wrong
<zaytsev> find -type f -print0 | sudo xargs -0 md5sum | grep -v isolinux/boot.cat | sudo tee md5sum.txt <--- should be grep -v isolinux, because the original md5sum doesn't include any of the isolinux stuff.
<zaytsev> https://help.ubuntu.com/community/LiveCDCustomization
 * doko_ looks away from NBS
<jibel> pitti, are these files useful on the ISO ? http://paste.ubuntu.com/613655/
<jibel> pitti, The raw size is 25MB but that would save something like 3 to 4MB of CD space
<pitti> jibel: apt lists are, I think
<pitti> 4.3M 2011-05-27 10:22 srcpkgcache.bin
<pitti> that's something I keep asking mvo about
<pitti> we just ditched it in a project, and it doesn't seem to be very useful
<pitti> but I keep forgetting why we need it
<jibel> *bin files are regenerated on first run of apt
<pitti> right, we could remove it from the CD certainly
<pitti> and I think the dpkg -old files can certainly go
<pitti> jibel: thanks for pointing these out!
<jibel> and apt list files are regenerated on first run of apt-get update.
<pitti> these are pretty much "nice to have", if you do an apt-get install etc.
<pitti> in the live system
<didrocks> maybe we can run an apt-get update as soon as internet is available?
<didrocks> on the live/ubiquity
<didrocks> (well s/internet/any network/)
<jibel> if you don't have an internet access you only need cd rom list, if you have one we can run an update at some point
<pitti> right
<geser> hmm, if available-old is 1.3M, I guess available is around the same size. What was the purpose of available again?
<jibel> and since the update timestamp on the CD is far behind the time the user actually uses the CD, update-manager will propose to run a check anyway
<cjwatson> jibel: that's already going away with live-build
<cjwatson> (pkgcache.bin etc.)
<cjwatson> no point analysing the current CD
<cjwatson> the -old files go away with live-build too
<pitti> nice
<jibel> cjwatson, oh cool, not analyzing the CD, just playing with the freshly backed isos, and found this.
<superm1> cjwatson, there's a plan to switch to live-build for this cycle?
<cjwatson> yes
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-live-build
<ohsix> is live build cooler than casper and sealing up your own images
<cjwatson> live-build and casper are apples and oranges
<ohsix> ok
<ohsix> last time i looked it was casper, dunno what's on live images now
<superm1> ah v. good thanks.
<cjwatson> ohsix: casper stays where it is.  live-build replaces livecd-rootfs.
<ohsix> i see
<cjwatson> as would be clear if you'd looked at my URL
<ohsix> did
<ohsix> no idea what role that stuff plays, going to read about livecd-rootfs
<zaytsev> cjwatson, Binary files image-orig/isolinux/boot.cat and image-new/isolinux/boot.cat differ, Binary files image-orig/isolinux/isolinux.bin and image-new/isolinux/isolinux.bin differ, is that normal when re-generating the ISO file?
<zaytsev> I checked up on isolinux.bin and it shows one bit flipped: http://paste.ubuntu.com/613701/
<zaytsev> are these cosmic rays or what?
<cjwatson> I think it probably depends on your installed syslinux(-common) packages
<zaytsev> oh, I'm on maverick, and re-generating image from natty, but I'm just using mkisofs, I don't even have syslinux installed. I'm not doing the bootstrapping from scratch
<zaytsev> and also same 82 -> 83 byte flipped in boot.cat
<cjwatson> I don't know if that's relevant, anyway
<cjwatson> it may just be because the rest of the ISO is different and so mkisofs needs to fiddle with the catalog
<zaytsev> I think it's mkisofs, because the file has the modification date is when I ran it
<cjwatson> I doubt it's relevant to your problem
<zaytsev> well, all the other changes that diff picked up are in package lists (updated packages) and squashfs file system
<zaytsev> so it can only be the file system, but that's a bit big to diff :-(
<zaytsev> ok, I added append  file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash maybe-ubiquity -- to live
<zaytsev> it still logins directly
<cjwatson> are you sure you still have ubiquity in your squashfs?
<cjwatson> (at this point, I would loop-mount the squashfses and diff them, particularly /etc)
<zaytsev> and when I press esc on boot it shows my modified commandline. so this is fine.
<zaytsev> no I am not sure, although I didn't remove it. will do as you say. thanks.
<zaytsev> diff -Naur on etc only revealed differences in fs-old/etc/ld.so.cache fs-new/etc/ld.so.cache... hmmm. will do whole fs.
<zaytsev> hopeless, there was a libreoffice upgrade, so the diff is polluted by 200 mb of binary files :-(
<mdeslaur> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: NCommander, mdeslaur
<zaytsev> here are the updated packages: http://paste.ubuntu.com/613720/ ... I don't see anything dangerous in here.
<zaytsev> could it have to do with motd? I changed the motd.
<cjwatson> no ...
<zaytsev> is there like a way to debug stuff?
<zaytsev> I now see it's being launched by upstart
<zaytsev> the file /usr/bin/ubiquity-dm is in place
<zaytsev> ok, I have an idea of what could have gone wrong
<zaytsev> maybe it's initctl, there was an advice to add a diversion on the wiki, maybe I screwed it up
<cjwatson> you'd certainly need to undivert that at the end of the build
<zaytsev> I'VE GOT IT~!, it's initctl. somehow in the new image it doesn'
<zaytsev> exist anymore at all. maybe I ran some command twice
<zaytsev> many thanks for all your help
<zaytsev> I learned a lot
<cjwatson> glad you got it sorted
<fta> doko_, I tried ld.gold on natty without PIE, it still crashes.
<tkamppeter> Any UDEV expert around? Is there some mechanism which removes files from /etc/udev/rules.d/?
<tkamppeter> pitti, ping
<pitti> hey tkamppeter
<pitti> tkamppeter: how do you mean, mechanism? there are standard recipes for removing obsolete conffiles, yes
<tkamppeter> pitti, what I do is connecting an HP LaserJet 1020 (the ugly thingy which needs firmware loaded).
<tkamppeter> pitti, this triggers the command "sudo hp-plugin" to be run and this installs a bunch of fresh files into /etc/udev/rules.d/. You can try "sudo hp-plugin" manually and then see what you get in /etc/udev/rules.d/.
<pitti> er,what?
<pitti> an udev rule calls sudo?
<pitti> no, I don't think I'll run a program like that
<tkamppeter> pitti, probably the rule does it without sudo.
<tkamppeter> pitti, the rule simply runs hp-plugin.
<tkamppeter> pitti, now I check whether the newly installed rules in /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules actually load the firmware into the printer.
<pitti> hm, I only see /lib/udev/rules.d/56-hpmud_support.rules
<pitti> tkamppeter: how does the file get there?
<tkamppeter> pitti, these rules get installed if you run hp-plugin.
<pitti> so we have an udev rule which calls hp-plugin which installs udev rules into /etc/?
<tkamppeter> pitti, so run "sudo hp-plugin" on a console and you get the files.
<tkamppeter> pitti, they get into /etc because HP does it this way.
<pitti> can we please kill hp-plugin?
<tkamppeter> pitti, and how do we support these printers then?
<pitti> and perhaps just ship the sensible part of their rules directly in hplip, in /lib/udev/rules.d/
<pitti> ?
<tkamppeter> pitti, we must support rules in /etc, to support third-party software.
<pitti> yes, but hplip is not a third-party software, it's an Ubuntu package
<cjwatson> having udev rules themselves go around installing udev rules is a different matter, though!
<pitti> which aren't supposed to install rules into /etc/udev/rules.d
<pitti> and as such it shoudn't do crazy things like that
<pitti> right, what cjwatson says
<tkamppeter> pitti, but the proprietary driver plugin of HPLIP is a third-party software, as it gets installed separately.
<pitti> tkamppeter: how is that related to the initial rules?
<tkamppeter> pitti, the initial rules which we ship in /lib are 100% OK.
<pitti> tkamppeter: what are the rules that hp-plugin installs doing?
<tkamppeter> pitti, the rules which get installed by HP's proprietary plugin are doing the auto-upload of firmware into HP's cheapo lasers.
<tkamppeter> pitti, the problem which I am experiencing is that these rules get executed once (the first time when I power-cycle the printer) and after that the rules file (only the one for my printer) gets removed.
<geser> who removes them?
<tkamppeter> geser, pitti, I do not know.
<geser> hopefully not the script doing the firmware upload
<pitti> can we stilll kill hp-plugin, or the part of it that does the crazy rules install?
<cjwatson> nothing in the standard distribution should be removing files in /etc/udev/rules.d/.  However, given that you already have a crazy thing automatically installing rules into /etc/udev/rules.d/ (rather than using a single static rule which uses IMPORT or something to import properties from a program), all bets are off
<pitti> tkamppeter: so, to get back to your original question, we certainly don't have a "standard mechanism" to remove any files from /etc, as this is EBW
<tkamppeter> geser, pitti, the script gets removed exactly after its first use. After having run "hp-plugin" and completed the wizard I wait some seconds and power-cycle the printer. The printer loads its firmware and the /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules is gone. All other 86-hpmud-hp_*.rules files stay.
<pitti> so I guess the rules that it puts into /etc/ have a builtin auto-destruct and delete themselves?
<tkamppeter> pitti, here is the rules file: http://paste.ubuntu.com/613748/
<pitti> so, apart from them using an outdated syntax, it seems that /usr/bin/hp-firmware removes them?
<tkamppeter> pitti, /usr/bin/hp-firmware is a Python program and I do not find anything in it which deletes the UDEV rule.
<tkamppeter> pitti, I have copied 86-hpmud-hp_laserjet_1020.rules into /lib/udev/rules.d/ now and there it survives. I can do as many power-cycles as I want and the file survives and every time the firmware gets uploaded.
<tkamppeter> pitti, is there a way to find out which program has deleted a file?
<hallyn_afk> seriously, people, "Development is completed for the 'natty' version of Ubuntu, so you should use technical support channels unless you know for certain it should be reported here?' is not a question
<Laney> what?
<hallyn> kirkland: thanks for the quick byobu (uh, screen) fix :)  now lemme see if i can reliably reproduce it before upgrading
<tkamppeter> pitti, still there?
<pitti> tkamppeter: not retroactively; you could grep your entire file system for files which contain the name, though
<geser> tkamppeter: try setting the rules file in /etc to immutable and check if something complains that it couldn't remove it
<pitti> I thought nothing would remove it again?
<pitti> and this is entirely after-the-fact debugging?
<tkamppeter> geser, how does one set /etc/ to immutable?
<geser> tkamppeter: not the whole directory but only /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules
<geser> sudo chattr +i /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules (as long as the file exists)
<tkamppeter> geser, the "chattr +i" actually protects the file, but I did not see any error. Nothing in syslog.
<geser> hmm
<geser> then I'm out of ideas
<pitti> few programs actually check the result of unlink()
<tkamppeter> pitti, I have also two other files in /etc/udev/rules.d/ which seem to be generated by programs from our distro: 70-persistent-cd.rules and 70-persistent-net.rules.
<pitti> I'd go with grepping the file system for "86-hpmud-hp_laserjet_1020.rules"
<pitti> might take ages, but it's effective
<pitti> tkamppeter: those are expected
<tkamppeter> pitti, I have started the search now.
<jibel> ev, can you look at bug 789152 when you have a minute or maybe that's expected at this stage of the release.
<ubottu> Launchpad bug 789152 in ubiquity (Ubuntu) "When booting an ISO, "try or install" dialog doesn't start" [Undecided,New] https://launchpad.net/bugs/789152
<cjwatson> jibel: dup of bug 788859?
<ubottu> Launchpad bug 788859 in ubiquity (Ubuntu Oneiric) "3D session selected even if not supported; availability of 2D session not obvious" [High,Fix committed] https://launchpad.net/bugs/788859
<ev> almost certainly is a duplicate
<cjwatson> ev: (are you planning to upload ubiquity today, BTW?)
<charlie-tca> jibel: I tried yesterday from the cd menu to just get to a live desktop in VBox, and got the same screen with top and bottom panels
<ev> cjwatson: yes
<charlie-tca> There was no icon to install, though
<cjwatson> excellent
<ev> more towards EOD though, might see how well this pygi stuff works
<ev> but probably without that merged in
<kirkland> hallyn: its only a partial fix
<kirkland> hallyn: but you should be okay, as long as you don't split screens
<kirkland> hallyn: i need to cherry pick a couple of patches from git against screen to get the real fix going
<kirkland> hallyn: but before doing that, I need a way to reproduce it ;-)
<jibel> cjwatson, yes maybe, but I was unsure because on this report there's a mix of "try/install" doesn't start and some 3D/2D bits with "oh no" dialogs, that's a bit confusing.
<tkamppeter> pitti, geser, I did more tests: I renamed the file to /etc/udev/rules.d/00-x.rules and did NOT make it immutable and it survives. After having done so I have created an empty file /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules and after the rules which are actually in 00-x.rules being executed the file 86-hpmud-hp_laserjet_1020.rules gets removed, 00-x.rules still surviving.
<infinity> tkamppeter: Sounds like a recursive grep of doom is in your future.
<tkamppeter> pitti, any file fitting the mask ??-hpmud-hp_laserjet_1020.rules gets removed.
<hallyn> kirkland: yeah i can't reproduce it...  (and i dno't split screens)
<pitti> tkamppeter: ah, so extend your grep to search for "hpmud-hp_laserjet_1020"?
<kirkland> hallyn: darn
<hallyn> i assume a flaky connection is the key
<pitti> cjwatson: I assume it's ok for you if I steal the gnome-python merge from you?
<cjwatson> pitti: absolutely, I think I marked it as "feel free to take" on MoM
<doko_> sladen: ping
<ogra_> pitti, any idea why the WI tracker didnt pick up all specs for ubuntu-armel yet ?
<ogra_> they should all be in approved state, targeted to oneiric and have a priority set
<ogra_> so i dont get why http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html isnt picking them up
<james_w> ogra_, have an example of one that isn't showing up?
<ogra_> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-o-arm-netinstall
<ogra_> and all the others from https://blueprints.edge.launchpad.net/~davidm?searchtext=o-arm
<pitti> ogra_: it's just proposed for oneiric, not accepted
<james_w> ogra_, "Proposed for oneiric", it needs to be accepted
<ogra_> davidm_, ^^^
<ogra_> davidm_, you need to accept all our specs for oneiric
<ogra_> approving isnt enough
<lool> Hmm language-support-en isn't in the archive anymore; are these deprecated?
<lool> (and language-support-writing-*)
<davidm_> ogra_, working it now
<ogra_> davidm_, thx
<davidm_> Sorry missed that step
<ogra_> me too
<pitti> lool: yes, they're gone
<ogra_> else i would have shouted earlier :)
<pitti> lool: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-clean-up-language-support FYI
<lool> pitti: thanks
<pitti> lool: we have had the split l-support-* and the dynamic check-language-support for a while, but that's a bit of a mess
<lool> pitti: Ok; makes sense
<lool> (more dynamic language support)
<kirkland> pitti: finally just started using lp-project-upload :-)
<kirkland> pitti: awesome :-)
<pitti> kirkland: :)
<kirkland> pitti: i have wasted too many clicks, for too long
<kirkland> pitti: question for you...  is it possible to pass the changelog as stdin or a file argument, or something?
<kirkland> pitti: i can easily carve that out of my debian/changelog, from the top entry
<pitti> kirkland: hm, haven't tried that; I just :e them in vim, and then edit them a bit
<Bagatelle> who can help me with this? A username and password are being requested by http://localhost:49810. The site says: "bookmarkable-user-auth"
<kirkland> pitti: yeah;  i take care to maintain my debian/changelog so that it doubles as my upstream release changelog
<Bagatelle> it seems there are problems with a port, but I dont know anything else
<kirkland> pitti: if i patch lp-project-upload to optionally take the changelog text on STDIN, would you accept that change?
<pitti> kirkland: of course; it's in ubuntu-dev-scripts, have at it :)
<kirkland> pitti: ie, if there's input on STDIN, use it as the changelog text?
<kirkland> pitti: sweet, thanks
<pitti> kirkland: just keep in mind that there's two editors -- one for changelog, one for release notes
<pitti> you can add options for both, and allow one to be '-'
<kirkland> pitti: right
<kirkland> pitti: i was wondering how to handle that
<pitti> good night everyone, have a nice weekend!
<kirkland> pitti: i only ever use changelog, and always leave releasenotes
<kirkland> blank
<pitti> kirkland: you could do --changelog --notes /dev/null or so
<kirkland> pitti: yeah
<pitti> or --notes ''
<kirkland> pitti: that would work
<kirkland> pitti: i'll get to it
<kirkland> pitti: thanks for the awesome tool;  i feel dumb for not having used it before :-)
<pitti> kirkland: so you'll use some dpkg-parsechangelog | sed | lp-project-upload chain?
<pitti> kirkland: heh, one day I got so fed up with the 20 clicks you have to do, that I just wrote it
<pitti> and since then I'm actually making more releases, as it's a lot less painful
<kirkland> pitti: yeah, something like that
<kirkland> pitti: currently, i'm using:
<kirkland> grep -B 10000 -m1 '^ \-\- ' debian/changelog
<pitti> heh, that'd work
<kirkland> pitti: yeah, it gets me what I want
<kirkland> pitti: see bikeshed's 'release' and 'release-build' scripts
<kirkland> pitti: it's the two scripts I use to release and publish 20+ upstream projects and packages
<pitti> ah, grep -B, clever
<kirkland> pitti: i use a standard naming scheme for all my projects/packages
<pitti> I had used sed -n '/^ --/ q; p' or so
<kirkland> pitti: always register both the team name and the project name in LP
<kirkland> pitti: always create a ppa
<kirkland> pitti: and when I release, I always release backports of the package to PPA for each of the supported ubuntu releases
<pitti> kirkland: I have "do-release" scripts, too, with that I could actually integrate the uploading as well
<kirkland> pitti: so people can track ppa:powernap/ppa for current powernap on older ubuntu releases
<kirkland> pitti: this is my step 1: http://paste.ubuntu.com/613820/
<kirkland> pitti: release-build ^
<kirkland> pitti: and my step 2 is http://paste.ubuntu.com/613821/
<kirkland> pitti: release ^
<pitti> I bet if we throw together everyone's release scripts, everything would be fully automatic
<pitti> well, build recipes in LP certainly went a long way towards automation
<mdeslaur> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: NCommander
<slangasek> doko_: you comment that the rpcbind dependency is "still outstanding" for the nfs-utils merge, but there's an MIR for it?
<cjwatson> smoser: I already had a busybox merge partly done :-(
<cjwatson> do I have to reconcile it all now?
<cjwatson> that's about twice as much work as just doing it (I was touched-it-last)
<smoser> cjwatson, bah. sorry.
<smoser> well, you can take a look at my diff. i think it is done. but if you want to pitch it, feel free.
<smoser> sorry for not asking first.
<smoser> take a quick look, and if it doesn't look like you think it should, then ditch it.
<smoser> i pretyt throughally went through all the changes from debian and made sure that everything in the changelog delta list was accounted for and that nothing else really was.
<smoser> theres a ppa build of my merge at https://launchpad.net/~smoser/+archive/ppa/+packages
<smoser> is 'lsb-release -is' the "right way" to determine if this release is ubuntu versus if it is debian ?
<j1mc> dpm: i'm not sure if you're the right person for this, but the openstack team just updated some of their site, and they
<j1mc> they've done some interesting stuff on their community page: http://www.openstack.org/community/
<j1mc> i like the 'developers in action' bit that shows real-time commits
<j1mc> they use launchpad, so i'd be curious to know how they did that.
<j1mc> ... just thought i would pass that along
<ScottK> smoser: I think dpkg-vendor is preferred.
<ScottK> That avoid a need for an lsb depends.
<smoser> ScottK, well that comes from dpkg-dev which is 'optional' in debian
<maco> smoser: but build-depends pulls it in
<maco> erm i mean
<maco> build-essential
<smoser> yeah, in ubuntu its probably goign to be there. but my interest was in getting something into 'jigit' to take a different path if "this is ubuntu"
<slangasek> build-essential isn't going to be pulled in on the runtime
<slangasek> lsb_release is preferred for that - you don't even need to depend on it really, if the command is missing you can just assume Debian
<slangasek> (since it's part of ubuntu-minimal)
<slangasek> barry: --package-merge> duuuude
<slangasek> when'd that get there?
<sladen> doko_: dong
<barry> slangasek: dunno, but i just found out about it yesterday!
<janimo> james_w, thanks for fixing up my BPs whiteboard ! I completely forgot LP ID is to be used
<james_w> np
<petar> why is update-initramfs executing scripts i put into /etc/initramfs-tools/scripts/* ?  i thought thats what hooks/* is for?
<petar> (thats on 11.04)
<slangasek> petar: you're correct, that is the difference between hooks and scripts; I haven't heard of this issue you describe
<petar> slangasek: i have one script in scripts/init-bottom and after every update-initramfs it gets executed..  and it doesn't get executed during a subsequent boot.. i remember that feature working pretty well on 9.10
<slangasek> a brief scan of 11.04's initramfs-tools code doesn't show me anything that explains why this would be
<slangasek> can you trace it?
<petar> to be honest i cant even see where this scripts stuff comes into it when reading update-initramfs
 * slangasek nods
<petar> there is not much sourcing either..
<petar> i need to eat something.. will try again, when i'm back
<NCommander> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<NCommander> oops
<petar> slangasek, its called cache_run_scripts and i have no idea why mkinitramfs uses that to run my scripts on update-initramfs -u
<petar> it seems that i could set NOEXEC but how can i set something that i dont understand in order to solve something that i dont understand either? ;)
<slangasek> petar: oh, yes, because it's trying to query the scripts to find out what their dependencies are
<slangasek> petar: does your script not handle the 'prereqs' option?
<petar> hmm, no, i thought i have no prereqs so...
<slangasek> right; but initramfs-tools still needs to call it with prereqs to find that out, so the script has to behave sensibly when this is done
<petar> aaaa.. i see now.
<slangasek> the only new behavior here is that we do this at update-initramfs time, to cache the order once instead of having an expensive query on every boot
<petar> ok, i'll add that.. makes sense.
<petar> thanks for your help!
<slangasek> sure :
<slangasek> )
<petar> very good, seems to work now
<slangasek> bdmurray: looking at bug #781874 still; is your thought that this should supersede the SRU currently in -proposed, or that that one should be published to -updates and the new one uploaded?
<ubottu> Launchpad bug 781874 in aptdaemon (Ubuntu Natty) "<type 'exceptions.TypeError'>: __init__() takes exactly 2 arguments (1 given)" [High,In progress] https://launchpad.net/bugs/781874
<bdmurray> slangasek: is the order important?
<slangasek> bdmurray: it impacts what -v option needs to be passed when uploading; I don't have a preference per se
<bdmurray> slangasek: well the one in proposed has been there for quite some time now
<slangasek> yep, apparently without verification
<bdmurray> and without testcases
<broder> ScottK: do you have thoughts on bug #787383? since u-d-t 0.124 introduces a versioned dependency on a current version of devscripts, dholbach's suggestion to just backport the bitsize bugfixes makes sense to me, but i'd like a second opinion
<ubottu> Launchpad bug 787383 in natty-backports "Include bitesize script in ubuntu-dev-tools" [Undecided,New] https://launchpad.net/bugs/787383
<bdmurray> I wrote a bug pattern for 781874 already so either way is fine with me.  I just didn't want the fix not making it into Natty.
<slangasek> well, let me prod the bugs to see if we can get a test case
<slangasek> no sense in uploading the next SRU either way if it's going to stay wedged forever on verification of the current SRU bugs
<slangasek> stgraber: do you happen to have a reproducible test case for bug #742935?
<ubottu> Launchpad bug 742935 in aptdaemon (Ubuntu Oneiric) "aptd crashed with OSError in release(): [Errno 9] Bad file descriptor" [High,New] https://launchpad.net/bugs/742935
<psusi> is there someone I need to poke to activate my universe-contributors membership?
<ScottK> broder: I think just backporting bitesize makes sense.
<bdrung_> psusi: normally the chair of the meeting
<bdrung_> psusi: feel free to poke him
<psusi> hrm.. seems the minutes haven't been posted yet
<psusi> and the irclogs for ubuntu-meeting are empty...
<psusi> err, oops, that was lp-meeting
<psusi> cjwatson, bug #770600 has been waiting for a while now for a sponsor, could you handle it?  it's a release regression in dmraid from the 64bit pdc patch that I added... branch proposed to simply disable the patch.
<ubottu> Launchpad bug 770600 in dmraid (Ubuntu) "22_add_pdc_64bit_addressing.patch: breaks some pdc raid sets" [High,In progress] https://launchpad.net/bugs/770600
<psusi> ppa tested and fix verified by multiple users
<stgraber> slangasek: nope
<cjwatson> psusi: it's end of week for me now, but my patch pilot day is coming up so I'll handle it then if not before
<cjwatson> (it's 23:38 here)
<psusi> cjwatson, cool
<slangasek> stgraber: k; was worth a shot
<cjwatson> I'm only still here because I was finishing up debugging bug 728088 in order to release a kind user's test machine
<ubottu> Launchpad bug 728088 in open-iscsi (Ubuntu Natty) "iscsi root with or without auth fails to boot" [High,In progress] https://launchpad.net/bugs/728088
<psusi> cjwatson, it used to be recommended to create a raid1 partition for /boot and install grub to those disks, then raid5 for / ( assuming you want a raid5 )... with grub2 you can now just make a single raid5 for /, and install grub to all of the disks, so should that now be the recommended method?
<cjwatson> psusi: probably, if it's working well
<cjwatson> separate /boot isn't harmful of course, it's just extra work
<psusi> right, and so if it isn't necessary, best to avoid it...
<cjwatson> it is more complexity in the boot loader, of course, and some people like to avoid *that*
<cjwatson> depends on your point of view really
#ubuntu-devel 2011-05-28
<psusi> ohh poo... partman doesn't ask you if you want to use msdos or gpt when creating a new partition table...
<bluefoxicy> http://www.amazon.com/Installing-Linux-Dead-Badger-Snyder/dp/1894953479/  Can we roll this into the Ubuntu guide?
<penguin42> bluefoxicy: 'OK, are you sure your badger is dead?'
<bluefoxicy> hehe
<broder> anyone on ~ubuntu-branches around to mark https://code.launchpad.net/~showard314/ubuntu/natty/sandboxgamemaker/incomplete_download/+merge/62524 as merged?
#ubuntu-devel 2011-05-29
<slangasek> pitti: it seems your python-gtk2 upload drops the ${python:Provides}, which makes python-gnome2 uninstallable
<sevis__> Hi
<sevis__> who could help me with preseeding? I need to automate the install of Baltix Linux. I have already automated preseed file for an earlier version (9.10 or 3.8) configuration, and some steps does not fit to latest version (10.04.2), it still prompts.
<sevis__> so could someone help me with preseeding? i asked for help on ubuntu channel, bet retrieved no help..
<petar> i just ran a flash-video on 11.04 on an pretty old banias i855gm gpu laptop at fullscreen and it was not laggy at all.. does the i915 driver support some sort of libvdpau or any other of these frameworks?  or is it something completely different?
<ElementCracker> guys how can i change the menu font color in GRUB2 in naatty
<ElementCracker> ?
<petar> ElementCracker: info grub (or /etc/defaults/grub).. whats -devel about that?
<ElementCracker> petar: there is nothing about devel sry  but was searching abt it and was not able to customize so jst posted it here
<petar> ElementCracker: info grub.. its all there.
<ElementCracker> petar: thx :)
<petar> np
<sacton3> One of my IT guys at work and I are wanting to make a Linux distro to help replace Windows on these terrible Dell Slimlines that we have.  Most of our applications are HTML based and Java so compatibility should not be too much of a problem.  The PCs are P4's with 256m of ram.  Im think of baseing it off of either Xubuntu or Lubuntu.  Anyone have any suggestions, my main concerns are compatibility with a Windows user system and s
<sacton3> One of my IT guys at work and I are wanting to make a Linux distro to help replace Windows on these terrible Dell Slimlines that we have.  Most of our applications are HTML based and Java so compatibility should not be too much of a problem.  The PCs are P4's with 256m of ram.  Im think of baseing it off of either Xubuntu or Lubuntu.  Anyone have any suggestions, my main concerns are compatibility with a Windows user system and s
<OdyX> sacton3: you should just try Ubuntu and/or Debian. "It works"â¢
<sacton3> Lol, I thought about using just vanilla debian at first, but I was leaning towards ubuntu due to the security and a lot of it alredy being handled with that install, would this be a problem with Debian?
<blackmoon-105> hi, i've made an updated opensc (0.12.10) deb package, available on my launchpad repo. there is a way for include it in a ubuntu repostories?
<blackmoon-105> no one?
<bdrung_> maco: can you create the packaging-dev repository (or upload the current version to debian mentors so that i can create the repository)?
<LaserJock> is the plan for oneiric to use GNOME3 with Unity? or is it going to stay GNOME 2 for another release
<micahg> LaserJock: it's being ported to GTK3
<LaserJock> thanks
#ubuntu-devel 2012-05-21
<Bluefoxicy> why oh why is the 32-bit desktop/live DVD 1.5 gigs and the 64-bit 700 megs?
<stgraber> Bluefoxicy: where are you looking? I see i386 at 1.5GB and amd64 at 1.6GB here
<Bluefoxicy> cdimage.ubuntu.com/releases/precise/release
<stgraber> right, same place I'm looking at :)
<Bluefoxicy> Where is the 700MB i386 @_@
<stgraber> on releases.ubuntu.com
<Bluefoxicy> silly me
<psusi> this bug report has a script error on line 11 saying splash not found... I noticed that the double quotes around "quiet splash" appear to be slanted... what's up with that? https://launchpadlibrarian.net/105554324/EtcDefaultGrub.txt
<psusi> I didn't think there was such a thing, but they appear different than the rest of the quotes in the file, and based on the error message about splash not found, it seems like the shell is treating those funny double quotes like backticks and trying to execute the contents
<psusi> is there such a thing as slanty double quotes that the shell interprets like backticks?
<lifeless> psusi: they are unicode quotes, not ascii
<infinity> psusi: Looks like someone's edited that in a fancy editor or word processor that wanted to use the unicode quotation marks instead of just using the ascii.
<lifeless> someone has messed the file up
<lifeless> the bug therefor is arguably that there is no vigrub command to detect such issues
<StevenK> vigrub is a slippery slope
<psusi> weird... yea, looked it up, unicode U+201D, right quotes
<psusi> but I didn't know bash had special interpretation for that...
<scientes> hmm the ubuntu code of conduct page wont accept a signed debian diversity statement....
<lifeless> scientes: why would it ?
<pitti> Good morning
<ajmitch> morning pitti
<pitti> infinity: no, I didn't dump any component-specific ddebs
<pitti> infinity: ddeb-retriever doesn't care about Sources.gz, it only looks at Packages.gz; so the main/universe split source packages shouldn't matter
<pitti> hey ajmitch, how are you?
<ajmitch> pitti: good, how are you today?
<pitti> I'm quite well, thanks! we had a nice weekend, and you?
<ajmitch> a nice, uneventful weekend where I mostly got over the ubuflu (still) :)
<pitti> ajmitch: argh; mine is mostly gone, too
<angeloc> pitti: thank you for approving my fix!
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: pitti
<pitti> hey angeloc, thanks for spotting this
<pitti> angeloc: uploaded to Debian and Ubuntu now
<micahg> hi pitti, happy piloting
<pitti> thanks micahg
<angeloc> pitti, i'm porting quickly to qt4 and qtquick and i spotted a wrong dependency in the building process!
<angeloc> pitti: can I ask you help with bug 993867?
<ubottu> Launchpad bug 993867 in xoscope (Ubuntu) "Xoscope package lacks pulseaudio-esound-compat as dependency" [Undecided,New] https://launchpad.net/bugs/993867
<angeloc> pitti, i'm looking for sponshorship
<pitti> angeloc: urgh, there are still packages out there which speak esound?
<angeloc> pitti, xoscope is really an ancient package! it' uses esound compat to talk to pulseaudio
<angeloc> pitti, so in the end it uses pulseaudio
<pitti> angeloc: yes, I mean protocol wise
<pitti> angeloc: you set up an SRU description, so I'll upload to quantal and precise-proposed
<pitti> ok?
<angeloc> pitti, yes, i'm investigating rewriting the software for pulseaudio, but the code is quite difficult to understand
<pitti> angeloc: BTW, if you want to do package fixes regularly, can you please add corresponding changelog entries? (dch is a nice tool for that)
<angeloc> pitti, yes, i can really enjoin the bug will be fixed also in precise
<angeloc> pitti, i'm new in sru process, so please be patient!
<pitti> angeloc: oh, changelogs are not SRU speciifc
<pitti> angeloc: anyway, I'll add it for you
<pitti> angeloc: do you know how to forward a fix to Debian?
<angeloc> pitti, weel no, i fixed another bug in xoscope and i think that debian will benefit both
<angeloc> pitti, i'm intrested in learning the sru process, can I fix the branch myself?
<pitti> angeloc: there is nothing to fix for the SRU part
<angeloc> pitti, adding a changelog i mean
<pitti> angeloc: oh, sure
<pitti> angeloc: use "dch", document the change, and then use "debcommit" to commit that change; then push again
 * pitti reverts his local changelog and waits for your's
<angeloc> pitti, i have to use -i flag to increase version number right?
<pitti> angeloc: FYI, https://wiki.ubuntu.com/Debian/Bugs has the documentation how to forward bugs to Debian
<pitti> angeloc: ah, that could be; I have configured dch to do that automatically for ages, so I forgot about it
<angeloc> pitti, yes i read the documentation, but using debian bug tracking is really a pain
<pitti> angeloc: either way, it needs to create a new changelog record, not append to the already existing one
<angeloc> pitti, last changelog entry shows debian/patches/99-esd_pa_fixes.patch, this time i have no a patch like this, i'll have to create one?
<pitti> angeloc: if you modify the source, yes; you can't modify it directly
<pitti> angeloc: since you are working on another change, I propose I'll wait for that with the upload instead of uploading twice?
<angeloc> pitti, cannot understand, i branched quantal/xoscope and fixed debian/changelog, which step i have to do now? making a debian patch?
<angeloc> pitti, i have only one patch
<pitti> angeloc: err, wait; what are we talking about now?
<pitti> angeloc: adding the missing changelog entry for your esound-compat addition, or the other fix you said you were working on?
<pitti> angeloc: you don't want to add the changelog entry to quantal/xoscope, but to lp:~angeloc/ubuntu/quantal/xoscope/fix-for-993867
<angeloc> pitti, there is only a patch for xoscope now (esd-compat), the other patch was accepted in precise at least five moths ago
<pitti> angeloc: ah; this has nothing to do with debian/patches/ then
<pitti> angeloc: just do dch -i, describe the change, and debcommit/bzr push that to your branch
<angeloc> pitti, ok, but for the least patch i made, a patch pilot like you created debian/patches/99-esd_pa_fixes.patch, i have to creat one for this patch right now?
<pitti> angeloc: why do you need a patch? You only add the dependency, you don't change any source code
<angeloc> pitti, ok, that's right! adding changelog with dhc ...
<angeloc> pitti, done
<pitti> angeloc: uploaded to quantal and precise-proposed, thanks!
<angeloc> pitti, wow!
<pitti> angeloc: note that the -proposed upload will hang in a review queue and needs to be accepted by the SRU team first
<angeloc> pitti, yes, i know
<krinetic> found a bug: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1002152
<ubottu> Launchpad bug 1002152 in lightdm (Ubuntu) "lightdm does not set background with wallpaper change" [Undecided,New]
<dholbach> good morning
 * micahg thinks he'll wait for the morning to upload gimp in case something breaks
<dholbach> micahg, the desktop team will have a couple of hours to fix it if it does :)
<micahg> dholbach: I'm sure they have enough work to do :)
<micahg> and they don't officially support it anyways
<micahg> s/officially/actively/
<dholbach> right, I guess it is mostly updates and merges
<micahg> in fact, the -desktop branch is no longer the main branch, lp:ubuntu/gimp is
<dholbach> geser, do you already have a wiki page with your core dev application up? I'd like to add my endorsement to it :)
 * micahg misses doko...
<pitti> tseliot: good morning
<dupondje> Could somebody review https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/937522 for me? Its been open some time now :)
<ubottu> Launchpad bug 937522 in remmina (Ubuntu) "rdp clipboard sync doesn't work anymore." [Undecided,Confirmed]
<pitti> tseliot: should nvidia-current and friends depend on nvidia-common? (or soon ubuntu-drivers-common)
<pitti> dupondje: can you please forward this to upstream?
<pitti> dupondje: I can review it then
<dupondje> pitti: its commited upstream already
<pitti> oh, nice
<dupondje> Tested it some time, made a ppa version of it also to let other people test it :)
<pitti> dupondje: sponsoring now, thanks!
<dupondje> great!
<tseliot> pitti: good morning to you. Yes, it's probably a good idea to make it depend on nvidia-common
<pitti> tseliot: I'm asking because presumably the postinsts should set/update the alternatives?
<tseliot> pitti: the postinst of the nvidia drivers already do that
<pitti> also, the packages should conflict to each other, to prevent that you install multiple versions at the same time and then don't know which one actually gets used?
<tseliot> pitti: shouldn't the driver manager tell you that?
<tseliot> i.e. jockey or whatever replaces it
<pitti> tseliot: yes, but only if you actually use that
<dupondje> pitti: SRU it also or not important enough?
<vibhav> good morning
<pitti> tseliot: if you install it in software-center or via apt, there won't be anything to update them
<pitti> dupondje: your call; sounds fine to me for an SRU
<tseliot> pitti: the only way to know for sure is to call update-alternatives
<pitti> tseliot: is there any chance we could drop the alternatives? they have caused us so much trouble, with packages not working or failing to install, etc.
<pitti> we get bug reports to no end
<dupondje> pitti: SRU then :) clipboard is a good to have thing :)
<tseliot> pitti: no, I don't think so. Diversions were even worse...
 * tseliot still has nightmares about diversions...
<pitti> dupondje: done
<dupondje> thcx
<pitti> tseliot: I'd like to start on implementing the spec now, with renaming the package and adding the packagekit/aptdaemon plugins
<dupondje> now lets fix the other 100 bugs in Remmina :P
<pitti> tseliot: do you keep this in a particular Vcs, or just lp:ubuntu/nvidia-common?
<tseliot> pitti: there's a git repository. Let me check if it's updated
<infinity> pitti: Weird, then, that I can find ddebs for libc6, but not nscd, despite the build log showing nscd.ddeb being genrated.
<pitti> infinity: indeed, neither for any other version.. http://ddebs.ubuntu.com/pool/universe/e/eglibc/
<tseliot> pitti: here it is: https://github.com/tseliot/nvidia-common
<seb128> infinity, pitti: not sure but could it be that the ddeb retriever doesn't like sources with binary in both main and universe? I think I saw issue with those before
<pitti> seb128, infinity: it's not inherently built to ignore those (it doesn't consider Sources.gz), but there might very well be a bug there
<pitti> but AFAIR we soon want to switch it to fetching ddebs from launchpad instead of the http servers, so I won't bother debugging this now
<seb128> \o/
<seb128> (on fetching ddebs from launchpad)
<pitti> tseliot: can you rename projects in github, or only create a new one and delete the old?
<infinity> pitti: Yeah, remind me on Tuesday (I have Monday off) to get back to testing the current state of ddebs in LP.
 * pitti reminds infinity that it is Monday
<infinity> Only barely, for me. :P
<tseliot> pitti: it seems that I can rename it
<tseliot> pitti: shall I rename it as ubuntu-drivers-common?
<pitti> tseliot: if you don't mind
<tseliot> ok
<pitti> tseliot: grazie!
<tseliot> pitti: di niente ;)
<tseliot> pitti: https://github.com/tseliot/ubuntu-drivers-common
 * pitti forks
<tseliot> pitti: I'll have to port all of the code to python 3 (it should be trivial to do) and finally upload xkit's python 3 port (since nvidia-common depends on it)
<tseliot> pitti: if need these ASAP, just let me know and I'll focus on them
<pitti> tseliot: not that urgent; I'll make sure that the new code (jockey replacement) works with 3
<tseliot> pitti: ok
<pitti> tseliot: hm, AFAICS the "nvidia-common" script is not installed anywhere; is that a bug, or is it just obsolete?
<pitti> tseliot: the one which calls nvidia-detector and shows the "obsolete-driver" debconf note
<tseliot> pitti: the debconf interface is disabled and, from what I can see, we don't shipt that script any more. Feel free to remove it
<pitti> ok
<pitti> tseliot: I'll leave it for now with the nvidia -> ubuntu-drivers renaming, I was just wondering whether I was missing something
<tseliot> pitti: ah, ok. we can remove it later
<tkamppeter> Do we have some libusb expert around here?
<cjwatson> tseliot: did I remember to push my python3 branch of x-kit, or were you working on it independently?
<tseliot> cjwatson: I ported xkit to python 3 some time ago (and cleaned up the API) but I couldn't upload it
<cjwatson> ah, it wasn't even in bzr anywhere visible when I looked
<tseliot> cjwatson: I guess it's a good time to fix the packaging and uploading it in quantal. I guess I'll have to provide python2.x libraries for the apps that still depend on it
<tseliot> cjwatson: no, sorry, it's in a local branch of mine
<cjwatson> my branch is lp:~cjwatson/xorgparser/python3 if that's of any interest; the same code should work in both 2 and 3 so providing libraries for both would be trivial
<tseliot> cjwatson: ok, thanks, I'll have a look at it
<pitti> tseliot: btw, the renaming is already in https://github.com/martinpitt/ubuntu-drivers-common , in case that's blocking you
<tkamppeter> pitti, do you know a libusb expert at Ubuntu?
<pitti> tkamppeter: I don't, I would have told you otherwise
<tkamppeter> pitti, so all USB expertise needed to make up Ubuntu is in the upstream projects?
<pitti> for libusb, apparently so
<pitti> geser: hm, your pcsc-lite merge is uninstallable due to libccid not existing; ccid FTBFSed
<pitti> geser: did you try this with a local build?
<pitti> I opportunistically retried the ccid build now
<geser> pitti: I test-build my pcsc-lite merge, but didn't checked the dependencies. ccid should build now, as that the reason I did the pcsc-lite merge
<geser> pitti: looks like I've to file a MIR for ccid as pcscd is in main
<pitti> ah great, ccid built
<pitti> geser: danke
<xnox> Laney: updated the tracker for python3 only on cd, please pull /dima =)))) into correct branch ;-)
<xnox> is lp:ubuntu/mountall the upstream of the mountall package?
<Laney> I saw, will look soon
<Laney> xnox: is there no is_bad you can have?
<Laney> did I ask this before ... feeling a dÃ©jÃ  vu
<xnox> Laney: I wish. Most source packages are converted to generate: python2-module and python3-module. And then both is_good .depends python3 & is_bad .depends python2.
<Laney> i see
<xnox> Laney: I'm not sure if somehow it is possible to 'force' is_good to take presedence over is_bad, if both return true.
<Laney> nah, no need
<xnox> Laney: it's ~good enough (tm)
<tseliot> pitti: ok, thanks, I'll merge your changes
<Laney> pushd
<tseliot> pitti: actually, can you make a pull request from github, please?
<geser> BenC: Hi, I hope you don't mind when I merged libzen. But as I can't test if your libzen.symbols.powerpc file is now obsolete or needs an update, could you take a look at https://launchpadlibrarian.net/105579169/buildlog_ubuntu-quantal-powerpc.libzen_0.4.26-1ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> tseliot: sorry, was at lunch
<pitti> tseliot: can do; I verified that the package builds, but I haven't tested it with jockey or installing drivers yet, as I don't have a any nvidia/ati machine
<tseliot> pitti: fair enough, we don't have to upload it now
<pitti> tseliot: https://github.com/tseliot/ubuntu-drivers-common/pull/1
<tseliot> thanks
<pitti> tseliot: the rest should not be so intrusive, mainly adding files
<tseliot> pitti: pulled, thanks
<tseliot> ok
<tseliot> cjwatson: I'm applying your changes for xkit, especially the ones to the test suite. Thanks again
<cjwatson> tseliot: great, thanks
<jdstrand> barry: hi! is there some sort of tag to use for things being ported to python3?
<vibhav> jtaylor: ping
<vibhav> I have created an SRU for eggdrop at https://bugs.launchpad.net/ubuntu/+source/eggdrop/+bug/885329 , can somebody check it?
<ubottu> Launchpad bug 885329 in eggdrop (Ubuntu Oneiric) "eggdrop crash on i386" [Medium,Triaged]
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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
<vibhav> Can https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 be nominated for precise?
<ubottu> Launchpad bug 598385 in munin (Ubuntu) "munin plugin exim_mailqueue has incorrect graph configuration" [Low,Triaged]
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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
 * dholbach hugs pitti and jamespage
<vibhav> aww
<Laney> jtaylor: weren't you looking at eggdrop? ^
<seb128> Laney, vibhav: there is an eggdrop SRU in the precise queue
<seb128> http://launchpadlibrarian.net/105631901/eggdrop_1.6.19-1.2ubuntu3.1_source.changes
<Laney> is it from jtaylor?
<Laney> yeah.
<Laney> looks like it's taken care of then
<seb128> oneiric has one as well
<vibhav> ah fine
<vibhav> jamespage: Are you busy?
<jamespage> vibhav, I'm available for piloting duties!
<jamespage> want me to take a look at that munin bug?
<vibhav> yeah
<vibhav> I also attached a debdiff for quantal
<vibhav> You might want to check it too :)
<jamespage> vibhav, ack - I think I spotted another SRU candidate for munin last week - looking at your debdiff now
<vibhav> the correct debdiff is at #6
<vibhav> jamespage: How is the debdiff?
<jamespage> vibhav, looks good - just sweeping in the other change as well
<zyga> ivanka: wow, are you back?
<vibhav> jamespage: Could you link me to the revised debdiff?
<jamespage> vibhav, http://paste.ubuntu.com/999058/
<jamespage> vibhav, patch was fine - but was missing from series file...
<jbicha> cjwatson: are there useful docs for how to build live CDs from a new packageset?
<jbicha> I found this guide which works ok for getting to that point https://docs.google.com/document/d/1RPPF14h1Sw2gQjGTuZjUIlNHnGrafS8ekhFjJM9MT00/edit
<cjwatson> jbicha: almost certainly not
<cjwatson> jbicha: you could go straight to the live-build documentation though and DIY
<vibhav> jamespage: thanks!
<cjwatson> live-build's docs are fairly decent, depending on how consistent you want to be with the Ubuntu defaults; for that you need to RTFS in livecd-rootfs (live-build/auto/*)
<vibhav> jamespage: jamespage Do you want to to work on an SRU?
<vibhav> a*
<barry> jdstrand: re: tag for py3 ports... not yet
<jamespage> vibhav, ultimately yes - would you have time to pickup detailing the SRU in the bug report?
<vibhav> yeah
<jbicha> I'd like my build to be as close to Ubuntu default as possible as I'd like to eventually get an official "gnomebuntu" flavor
<vibhav> jamespage: I dont know the steps to reproduce
<vibhav> jamespage: Any specific regression potential for https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678 ?
<ubottu> Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Triaged]
<jamespage> vibhav, no - not really
<jamespage> it broken as it stands ATM
<didrocks> bdmurray: hey, can you add popey to the ubuntu bug control team? He filed quite some bugs in the past (too many of them to my taste :p) and we can use some triagin from in on the unity side ;)
<ogra_> popey is unity dev now ? wow :)
<bdmurray> didrocks: sure, I'll add him now
<didrocks> bdmurray: thanks :)
<vibhav> jamespage: ping
<vibhav> jamespage: done, https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678/comments/8
<ubottu> Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Triaged]
<dholbach> xnox, I just saw that I got a work item here https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-more-agile-sru-process - you mentioned it to me at UDS but we found a different solution afterwards
<dholbach> xnox, can I assign it back to you? (I wasn't even at the session)
<Laney> is that really the best use of their time?
<xnox> dholbach: was the 'different solution' in actual fact the first workitem - as in it should be community led sru-team that is to be revived?
<xnox> and hence that work-item got obsoleted due to post-session discussions?
 * Laney would like that more :-) (there's plenty of /patch piloting/ that can be done without upload rights)
<dholbach> no, I said I'd be happy to share the scripts I use for scheduling piloting sessions, but that I won't have time this cycle to schedule another bunch of piloting slots (and stay on top of the queue, etc etc)
<xnox> dholbach: true. there was another person asking for those scripts (apart from/in addition to) me
<xnox> was it balloons?
<dholbach> I don't know
 * vibhav sits in the corner and waits for jamespage 
<seb128> dholbach, xnox, infinity: you probably want to drop the [all] in the workitems section, ~all is an old unactivated lauchpad account it seems, probably not what you want
<dholbach> in any case I'm happy to send them over to you
<jamespage> vibhav, sorry - was just dealing with something else
<dholbach> seb128, I wasn't even in that session :)
<dholbach> seb128, but it's good to know :)
<seb128> ;-)
<vibhav> jamespage: So could you check the SRU debdiff?
<jamespage> vibhav, in the next 30 mins yes
<vibhav> thanks!
<xnox> dholbach: ok.
<dholbach> thanks xnox
<xnox> seb128: and infinity is not in today as far as I remember or something.
<dholbach> xnox, sent
<seb128> xnox, right, he will read the scrollbars I guess
<seb128> or at least look for highlights ;-)
<ogra_> (and being pinged by seb128 is always a highlight !)
 * xnox *giggles*
<zyga> hey, has anyone seen gustavo niemeyer today?
<seb128> ogra_, well, infinity said something about never trusting the frenchs again recently so I'm careful ;-)
<ogra_> haha
<ogra_> zyga, not on freenode (hint)
<zyga> ogra_: ah, thanks
<Bluefoxicy> that's hilarious.
<Bluefoxicy> you can install IcedTea Java WebStart
<Bluefoxicy> in Precise
<Bluefoxicy> pull up Software Center, punch in Java, install Java WebStart.
<Bluefoxicy> it doesn't WORK
<Bluefoxicy> ... because it really doesn't care if you don't have a JRE installed
<Bluefoxicy> No questions asked, here's javaws, go wild
 * Bluefoxicy assumes it 'suggests' or 'recommends' some kind of Java but doesn't depend on it
<Bluefoxicy> oh.  That's why this doesn't work.
<Bluefoxicy> it installes icedtea-netx-common
<Bluefoxicy> but doesn't friggin' install icedtea-netx
<Bluefoxicy> so Software Center can't install Webstart at all
<jamespage> vibhav, the changes are fine but the changelog is going to need alot more detail
<jamespage> quote 'a detailed and user-readable changelog'
<vibhav> jamespage: Like?
<Laney> Describe the bug your patch fixes in easily readble terms
<shbk> hello! I want to use linux   man for getting information about C++ functions. For example I can do  "man printf"  and I get info. For this purpose I installed    libstdc++6-4.4-doc . I try to do "man cout, man std::cout" - but notâhing.  How can I use man to get info about   "cout, new , etc" ?Thanks
<jamespage> vibhav, http://paste.ubuntu.com/999223/
<jamespage> I try to cover off - a) what is being fixed, b) how and c) the source
<Daviey> jamespage: Can you write my changelogs for me aswell please?
<jamespage> this information is obviously in the patch headers as well but it makes it easier for the SRU team to review
<jamespage> Daviey: :-)
<vibhav> heh
<vibhav> jamespage: https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678/comments/9
<ubottu> Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Triaged]
<jamespage> vibhav, OK - leave it with me - I need to review the information in the bug reports as well
<xnox> brain damage of the day: bug 1002357
<ubottu> Launchpad bug 1002357 in mdadm (Ubuntu) "sort out udev rules madness (3 editions installed into 4 files)" [Undecided,New] https://launchpad.net/bugs/1002357
<cjwatson> shbk: man will only show things that somebody's written manual pages for; I've never seen manual pages for the basic C++ runtime
<Bluefoxicy> Okay, serious question.
<shbk> I hoped that someone has written for the C++
<Bluefoxicy> Anyone on Precise, punch in 'dmesg | grep Yama' in a terminal
<Bluefoxicy> and please explain
 * Bluefoxicy is trying to make Wubi boot in VirtualBox with no success, just spotted this along the way
 * vibhav hugs jamespage 
<cjwatson> shbk: some googling suggests manpages-cpp (not packaged AFAICS) or ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/libstdc++-man.4.4.0.tar.bz2
<cjwatson> though the latter at least doesn't have a page for cout
<xnox> Bluefoxicy: http://lwn.net/Articles/393012/
<Bluefoxicy> xnox:  ah ok.  Was just amusing, and funny.  Yama is japanese for Mountain, and also king of the spirit world.
<xnox> Bluefoxicy: je ne parle pas japonais
<Bluefoxicy> xnox:  It looked like a joke :p  Yama:  Becoming mindful ... i.e. meditating buddhist god
<cjwatson> many names of free software programs started as jokes at some point
<Bluefoxicy> wubi == security blanket
<cjwatson> I think that one may be coincidence
<Bluefoxicy> So anyway has anyone else tried installing icedtea web start through Software Center in precise and found you only get icedtea-netx-common and not icedtea-netx?
<Bluefoxicy> or is this just me?
<jono> does anyone know if the PySide Qt bindings are in Precise?
<tumbleweed> should be
<jdstrand> barry: thanks. one other question. assuming I am able to get the source for a package to work with either python2 or python3, would I be able to have a single binary that could be installed with either? eg, ufw on the desktop works with python3, but ufw on the server works with python2
<jdstrand> barry: but it is the same binary (obviously installing all the /usr/lib/python*/dist-packages/ufw/* bits for both 2.7 and 3.2)
<cjwatson> why shouldn't ufw on the server be made to work with python3?
<jdstrand> cjwatson: it very well can. I didn't know if python3 would necessarily be on the server (or minimal, etc)
<cjwatson> any given binary has to have one or the other in its #! line
<cjwatson> you can preprocess it of course to use a different one, but that'd mean two packages just for the binary
<jdstrand> I would like to avoid two packages for the binary
<cjwatson> I suspect we're going to end up converting server bits as a result of converting desktop bits
<jdstrand> I am currentyly using /usr/bin/python
<jdstrand> so in that regard it should all just work. I just wanted to make sure there wasn't some packaging requirement that I must have 2 binaries if I am to support both python2 and python3 (it wasn't clear to me from the blog entries barry did)
<cjwatson> I believe our general plan is that most modules ought to support both for a period, but binaries should pick one
<cjwatson> er, programs
<jdstrand> cjwatson: it might just be an answer to this question: will python3 be on the server cd?
<cjwatson> it will be exceedingly difficult, if not downright impossible, to meet the goal of having only python3 on the desktop CD without also having python3 on the server CD
<jdstrand> (as upstream, I want to support 2.6 and higher (at least), but as the package for Ubuntu/Debian, I can choose)
<cjwatson> you might as well assume it'll be there
<jdstrand> ok
<jdstrand> if it isn't, we can revisit
<jdstrand> cjwatson: thanks
<jdstrand> barry: cjwatson fielded my question
 * Daviey doesn't expect server's largest consumer of python (openstack) to be py3 compliant this cycle.
 * jdstrand remembered something about that
<cjwatson> Then you are likely to end up with both, I'm afraid
<Daviey> i suspect for this cycle, that makes sense.
<cjwatson> There's enough stuff in the core that uses Python that it's not practical for us to permit flavours to choose entirely-python2 vs. entirely-python3
<Daviey> agreed
<dobey> i suspect we won't be able to make it to 100% py3 this cycle, though maybe close to 80-90%
<jamespage> vibhav, just uploaded you munin change to precise-proposed  - also added some extra info to the SRU information (mainly around how to freeze messages to generate the graph error)
<vibhav> thanks!
<vibhav> good night
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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> ttfn
<bdmurray> any ideas what would add independent to /etc/apt/sources.list? bug 947296
<ubottu> Launchpad bug 947296 in update-manager (Ubuntu) "Update-manager stopped updating" [Undecided,Confirmed] https://launchpad.net/bugs/947296
<slangasek> no ideas here
<stgraber> bdmurray: independent is the name used by software-center for extras.ubuntu.com, not sure if that makes that bug report any clearer though
<bdmurray> stgraber: hmm, thanks
<dupondje> https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication => Still some endorsments wanted ! :)
<Bluefoxicy> http://img818.imageshack.us/img818/2163/screenshotfrom201205211.png is this a bug?
<bdmurray> is there any launchpadlib api code for copying ppa builds to ther series?
<maxb> Yes, syncSource
<Laney> itym copyPackage
<maxb> Laney: I like my errors synchronously, thanks :-p
<bdmurray> ah, I meant a handy tool using the launchpad api not what do I need to use in the api to do it
<melodie_> gn
<robert_ancell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: robert_ancell
<xnox> How does udev order rules? If there is both 65-foo.rules and 85-foo.rules with matching actions 1) does only the first one run 2) both are run A) in ascending order B) in descending order
<slangasek> xnox: 2A)
<slangasek> (TTBOMK)
<xnox> slangasek: thank you. I'm done with Bug #1002357 and now thinking about migration paths & what to do with people who overriden alter-ego rules files.
<ubottu> Launchpad bug 1002357 in mdadm (Ubuntu) "sort out udev rules madness (3 editions installed into 4 files)" [Undecided,New] https://launchpad.net/bugs/1002357
<slangasek> xnox: are these installed in /etc/udev/rules.d, or /lib/udev/rules.d?
<xnox> slangasek: in the .deb there is /lib/udev/rules.d/[65|85]*.rules in the .udeb there is /[etc|lib]/udev/rules.d/*.rules
<slangasek> hmm, interesting
<xnox> .udeb should be ok, no migration path
<slangasek> right
<xnox> but the 65/85 becoming a better 64 might need magic to purge from /etc/udev/rules.d/, but that may end-up in droping user config
<slangasek> xnox: so I understand from kees that one of the consequences of this is that we do actually have incremental mode enabled even though Debian doesn't - right?
<xnox> true
<slangasek> well, unless there's a version of the package that shipped the rules under /etc, I don't think we need to worry about migrations there
<xnox> ok. But if users customized 65/85 will their config get dropped or still applied on top of ours?
<kees> if a rule exists in /etc it is ignored in /lib
<kees> (but have exactly the same filename)
<slangasek> correct... but if they're under different filenames, which order are they applied in?
<slangasek> are they interleaved by number?
<kees> both are merged into lexical order
 * slangasek nods
<xnox> I was thinking to rename /etc/[65|85
<xnox> ] to *.rules.dpkg-disabled
<slangasek> I wouldn't, if those files have never been owned by the package
<xnox> or something ;-)
<slangasek> are you concerned that running both our rule and the user's rule will break things?
<xnox> ok.
<kees> xnox: there shouldn't be anything in /etc
<slangasek> Frankly, I think overriding the system rules by shadowing the file in /etc is a weird thing to do
<kees> xnox: what's your plan? you're going to remove debian/mdadm.udev (85-...) and use the shipped 64-... without the "disable incremental" patch?
<slangasek> I would expect users to *add* rules under different names, not try to override the stock ones
<xnox> Ok, then the reporter of bug 968074 will have to clean up one's /etc
<ubottu> Launchpad bug 968074 in mdadm (Ubuntu) "Partitionable raid ignored by 65-mdadm-blkid.rules" [Undecided,New] https://launchpad.net/bugs/968074
<xnox> kees: yes.
<kees> xnox: cool
<xnox> slangasek: see above bug. Users working around our broken udev rules =/
<xnox> kees: also debian switched default superblock format....
<kees> xnox: oooh, cool
<kees> xnox: to which?
<kees> 1.2?
<slangasek> xnox: so worst case is that it takes a little longer to run the rules for this device because the same commands are run twice, right?
 * xnox needs checking
<slangasek> that's not worth risking disabling other kinds of customization for
<xnox> slangasek: true.
<kees> the 2TB limit on the 0.90 version is reason enough to switch the default, IMO.
<xnox> slangasek: the only worry, if users explicitly desiabled the whole rule, to for example *not* automount raids at boot, but now we will...
<xnox> because we renamed the rule
<slangasek> heh... /me thinks we should probably get some integration tests in place before we change the default superblock format
<cjwatson> wow, I thought we'd taken a default change ages ago
<slangasek> xnox: automount, or auto-assemble?
<kees> xnox: I think that's enough of a corner-case it's not a problem
 * xnox needs checking. kees wrote up that we still have old 0.90, but debian switched to newer format, I'm still digging through the package diff. Way to many spurious changes and no udd.
<xnox> kees: ok.
<xnox> slangasek: good point. I think auto-assemble.
<xnox> but will check.
<slangasek> xnox: yeah... I guess it's possible users might do that, but I think it's too hard to get the handling right to deal with this automatically
<kees> xnox: looks like precise has the new format
<xnox> kees: can't wait for all the LTS users to upgrade
 * xnox oh, wait...
<kees> xnox: I think I checked on this in oneiric last.
<kees>        -e, --metadata=
<kees>               Declare the style of RAID metadata (superblock) to be used.  The
<kees>               default  is 1.2 for --create, and to guess for other operations.
<kees> and I verified in on an actual --create
<xnox> kees: slangasek: bug #997315
<ubottu> Error: Launchpad bug 997315 could not be found
<xnox> http://pad.lv/997315
<xnox> MDadmExamine.dev.sda5: Error: command ['/sbin/mdadm', '-E', '/dev/sda5'] failed with exit code 1: mdadm: No md superblock detected on /dev/sda5.
<kees> ew
<slangasek> winning
<slangasek> xnox: that looks like something we should target for 12.04.1?
<xnox> slangasek: yes, please.
<slangasek> done
<Bluefoxicy> ha-HA!
<Bluefoxicy> I wrote an init script that creates as many zram devices as CPUs, creates a device mapper striped RAID across them, and creates swap on that :D
<Bluefoxicy> (it's hideous)
<xnox> Bluefoxicy: as long as you did not use [64|65|85]
<xnox> -raid.rules
<xnox> name for the udev, I'm fine
<Bluefoxicy> nah
<xnox> good
<Bluefoxicy> I need to clean this up.
<Bluefoxicy> Multi-thread works like this:
<Bluefoxicy>  - Is MULTITHREAD==1?
<Bluefoxicy>   Yes:  - Do we have exactly 1 CPU?
<Bluefoxicy>   Yes:  MULTITHREAD=0
<Bluefoxicy> xnox: http://pastebin.com/RFrTunUP if you're curious :P
<Bluefoxicy> I should find the script that sets up zswap in casper and make a patch that does this.
<Bluefoxicy> well, not sure.  I'm not sure how Linux swaps or if this is the better way to do it.
<Bluefoxicy> in theory, if Linux swaps in individual pages, this is horrible (tbh, it'd be fantastic if I could make CHUNK_SIZE less than PAGE_SIZE)
<Bluefoxicy> if it swaps out in bigger chunks (say 4, 8, 16 pages at once), and device mapper writes it all in parallel, this is great.
<Bluefoxicy> The other way to do this is to load multiple swap devices with the same priority
<Bluefoxicy> in which case linux will auto-balance, though again it becomes a question of how (per-page balancing, per-swap balancing, even use, or just move from one to the next if a swap is in process on the first?)
<Bluefoxicy> THAT method would be great if it balanced via even use per-page, i.e. if it swaps 16K across 4 devices it swaps 4k and 4k and 4k and 4k all at once
<Bluefoxicy> wot a mess.  The real solution is to multi-thread zswap inherently and use lz4
<Bluefoxicy> ahh
<Bluefoxicy> it interleaves.  SO I'm dumb and this raid thing is stupid.
<xnox> ok.
#ubuntu-devel 2012-05-22
<slangasek> xnox: bug #1002277> mountall already fscks all filesystems before mounting, when it can and needs to
<ubottu> Launchpad bug 1002277 in mountall (Ubuntu) "should allow running fsck before mounting a filesystem" [Undecided,Confirmed] https://launchpad.net/bugs/1002277
<slangasek> xnox: for btrfs root, isn't the first problem going to be that fsck.btrfs isn't available in the initramfs?
<xnox> slangasek: great, close it as invalid. From quick look at the source code, I didn't work it out. Then only some testing left on my part and we can have update btrfs package with fsck.btrfs in the initramfs ;-)
<xnox> wait...
<xnox> just wil fsck.btrfs
<xnox> or is it...
<xnox> nope it's not. And by the time you can access fsck.btrfs, your btrfs root is already mounted *sigh*
<slangasek> right... but that's not a mountall issue, at least not until you have an event-based initramfs
<slangasek> first problem is to solve fsck.btrfs not being in the initramfs
<slangasek> but really, shouldn't we expect fsck.btrfs to be smarter?
<slangasek> and be usable on a ro-mounted fs?
 * xnox after skimming through neverending btrfs threads on CEPH mailing list, I wouldn't expect much
<xnox> do we want fsck.btrfs for all initramfs or only for those who have it as rootfs?
 * xnox btw current patched edition of fsck.btrfs in the WIP branch should do nothing and exit with 0 if the filesystem is mounted.
<slangasek> s/expect/demand/, then ;)
<slangasek> yeah, I think it definitely should only go in the initramfs when the rootfs is btrfs
<slangasek> (rootfs or /usr partition)
 * xnox from now own `rootfs' is a variable which stores a list of required partition(s)
<psusi> xnox, the initramfs has no fsck of any kind... the root fs has always been mounted ro, then if fsck fixes things, you reboot, if not, you fsck the other filesystems and mount them
<xnox> psusi: true, given a sensible filesystem. btrfs is special =(
<psusi> xnox, how so?  last I heard btrfsck doesn't actually do hardly anything anyhow, and it is a design goal to never need it... i.e. just mounting the fs should recover from crashes, like ext3/4
<xnox> Latest btrfs-progs (c. 26 Mar 2012)
<xnox> btrfsck can now repair some forms of filesystem breakage
<xnox> A new data recovery tool (btrfs-restore) is available. This program doesn't attempts to repair the filesystem, it only tries to pull files from damaged filesystems and copy them to a safe location. Also, the Btrfs filesystem checker (aka fsck) can now repair extent allocation tree corruptions (more repair modes in progress).
<xnox> http://kernelnewbies.org/Linux_3.4
<xnox> https://btrfs.wiki.kernel.org/index.php/Main_Page
<slangasek> psusi: replaying the journal is not the only function of fsck for ext3/4
<psusi> slangasek, right... but if the fs is so damaged that it can't be mounted, you probably need to boot from other media anyhow, and fortunately, that kind of thing almost never happens... so I'm not sure why you would want to put fsck in the initramfs
<psusi> can't be mounted read-only anyhow
<slangasek> psusi: the point isn't to fsck a fs that couldn't otherwise be mounted, the point is that once the btrfs is mounted (ro or otherwise) it's too late to fsck
<psusi> btrfsck can't run on a ro mounted fs?
<slangasek> correct, that's what we're discussing
<psusi> ohh... that's a bug in btrfsck then...
<slangasek> feel free to fix it? ;)
<psusi> since it's still early beta, I'm sure it will get worked out ;)
<psusi> if the kernel can manage to shrink a mounted btrfs filesystem while it is mounted, I'm sure btrfsck will figure out how to fsck it while mounted ro ;)
<ritz> jasoncwarner_, ping
<doko> hi
<pitti> Good morning
<mjr> running a local ubuntu-based derivative, why would do-release-upgrade not recognize that it's running on lucid/lts and therefore offer a lucid upgrade? lsb_release -a seems fine... it does offer maverick if Prompt=normal.
<broder> mjr: lts -> lts upgrades aren't offered until the first point release of the new lts comes out (roughly 3 months after release)
<broder> lucid users aren't being prompted to upgrade yet
<broder> (though i believe they will if they pass -d to do-release-upgrade)
<mjr> Right. Thanks, that was it. Silly me. Have to do some testing of the upgrade process and verify it works with our tunings, see.
<micahg> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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, robert_ancell
<hrw> hi
<hrw> can someone take gcc-4.7-arm{el,hf}-cross out of NEW queue?
<micahg> slangasek: what's the general position on SRUing for multiarch support?
<pitti> micahg: we discussed it the other day, and deemed it ok for precise, with due care applied
<pitti> micahg: as there were a few packages where it would really help (especially for third-party apps which still need the old gnomevfs or similar)
<micahg> pitti: ok, are udebs supposed to be multiarched?
<micahg> slangasek: unpin
<pitti> micahg: I don't see how that would be useful
<micahg> ok, that's what I figured
<pitti> micahg: they might end up in /lib/<arch>/, but perhaps more as a side effect?
<pitti> i. e. when configuring the package with that libdir, then they just end up that way in debian/tmp/, and I guess the udeb makes no special effort of moving them back
<pitti> but we certainly wouldn't make a deliberate effort on multiarching them
<micahg> right, but if the lib is being multiarched for other reasons, the udeb rides along for free?
<pitti> yes, AFAICS
<pitti> otherwise you'd have to modify their *.install files to say things like "lib/*/<name>.so lib/<name>.so" which is unnecessarily error prone
<pitti> (and requires hardcoding the library name, too)
<micahg> this udeb has files in /usr/lib for some reason
<pitti> I don't know the policy enough to say whether they should be in /lib, or whether it doesn't matter
<micahg> right, I don't know either :)
<pitti> technically it seems to me that it doesn't matter, as for install environments we don't need to be concerned about a separate /usr/
<micahg> heh, so, Debian has the udeb being installed in /usr/lib
 * micahg follows Debian's lead
<dholbach> good morning
<dholbach> DMB folks: could it be that bencer is still missing in ~ubuntu-dev?
<micahg> dholbach: there's some work involved still
<dholbach> aha?
<dholbach> so you're waiting on the packageset creation?
<micahg> dholbach: but he'll get there (actions items are documented)
<micahg> yeah
<micahg> actually, he won't go in ubuntu-dev, but into a team which is a member of it
<dholbach> ok - I was just wondering
<micahg> I'll get it sorted this week
<dholbach> great
<micahg> pitti: do you know if static libs count as a shared library for use of ${misc:Pre-Depends}?
<pitti> micahg: for Pre-Depends: multiarch-support ?
<micahg> yeah
<pitti> micahg: my gut feeling is "no", as these are only searched at build time
<pitti> I'm not entirely sure whether gcc uses ld.so's lookup paths; if so, we need it, if not, we don't
<pitti> that whole pre-depends thing is pretty much obsolete now post-precise anyway
 * micahg saw that Debian didn't include it in libxkbfile
<pitti> but we will still have some for Debian, as they didn't yet do a release with multiarch
<micahg> this one is an SRU for precise (although I'm looking at another one for quantal ATM)
 * micahg guesses he can hold onto these until morning
<vibhav> Could https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 and https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678 be nominated for oneiric?
<ubottu> Launchpad bug 598385 in munin (Ubuntu Precise) "[SRU] munin plugin exim_mailqueue has incorrect graph configuration" [Medium,Fix committed]
<ubottu> Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Triaged]
<micahg> vibhav: looking
<dupondje> pitti: dunno if you could add your recommendations on https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication ? :)
<pitti> dupondje: sure! do you happen to have a list of packages that I sponsored for you?
<micahg> vibhav: oneiric has a different version, are you sure it's affected?
<dupondje> pitti: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*&sponsor_search=name&sponsoree=Jean-Louis+Dupond&sponsoree_search=name
<vibhav> micahg: I cant see the fixed code in oneiric
<micahg> vibhav: done
<vibhav> micahg: thanks!
<vibhav> jamespage: ping
<micahg> vibhav: can I help you with something (currently piloting)
<vibhav> micahg: Since the problem involves munin, munin-node and exim4 , shouldnt they be be affected too
<vibhav> Im talking about LP: #598385
<micahg> vibhav: not unless there's something to fix there
<vibhav> ah
<doko> siretart, ping
<siretart> doko: hi
<micahg> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: robert_ancell
<pitti> tseliot: good morning
<tseliot> pitti: good morning to you
<pitti> tseliot: it's working quite nicely now :) http://paste.ubuntu.com/1000413/
<pitti> tseliot: i. e. driver lookup behind a nice upstream compatible API
<tseliot> pitti: very nice :)
<pitti> I also wrote a performance test case
<pitti> performance of 1000 lookups in a single query ... [24 msec] ok
<tseliot> pitti: wow, do you have a pull request too?
<pitti> tseliot: that should be quite a bit faster than the 30 seconds or so current jockey takes to detect drivers
 * tseliot nods
<tseliot> :)
<tseliot> excellent work!
<pitti> tseliot: not yet, still test-building in a PPA, and I needed that aptdaemon upload to make the tests succeed
<pitti> tseliot: but it's of course still far from a jockey replacement
<pitti> just starting with the lower-level functionality
<tseliot> pitti: yes, of course. It's still good progress though
<c10ud> hello there, not sure if this is the proper channel (if not please tell me which is). I have an issue with pygi (i think) --ubuntu specific they tell me-- which leads the app to segfault. i send the report with apport but i don't know where it's stored. any help?
<c10ud> pitti, sorry to ping you directly, please see above ^ (i think youre the mantainer?)
<pitti> c10ud: I need some more details, I'm afraid -- which pacakge crashed?
<c10ud> pitti it's not in the archives, we're porting our app (emesene) to gtk3
<pitti> c10ud: they go to https://errors.ubuntu.com/ FYI
<pitti> c10ud: ah, then it probably shouldn't have sent the report in the first place -- I guess it assigned it to "python2.7" then
<c10ud> oh, i thought it opened a bug so we could see and comment out
<pitti> c10ud: that's what happens during development releases, but not for stables any more
<c10ud> anyway, Jose Rostagno (he sent you some pygicompat patches) says it works good in arch (he's the guy behind the porting) hence my "ubuntu-specific" thought
<pitti> c10ud: what you can do is to install the apport-retrace package, then reproduce the crash, and when apport pops up, click on "Examine locally"
<pitti> c10ud: this will throw you into a gdb session with all debug symbols available, so a "bt full" there would help quite a bit
<c10ud> ok
<pitti> c10ud: are you using python2 or 3?
<c10ud> python2
<c10ud> cool thing is, issue is random
<pitti> c10ud: so, at this point it would be best if you could open a Launchpad bug against pygobject and attach a test case
<c10ud> sometimes it crashes, sometimes it does not
<pitti> sounds like garbage collection/ref count/transfer annotation issue
<c10ud> this also appears: Gtk:ERROR:/build/buildd/gtk+3.0-3.4.2/./gtk/gtkstylecontext.c:739:timeline_finished_cb: assertion failed: (info != NULL)
<c10ud> anyway i'll try the apport trick now
<pitti> ah, please include that in the bug report
<pitti> probably the ref count sometimes goes to zero and info gets freed (whatever info that is)
<popey> bdmurray / didrocks I don't appear to be able to nominate bugs (like bug 1000577) for series precise..?
<ubottu> Launchpad bug 1000577 in BAMF "Unity crashed in bamf_application_on_window_removed" [Critical,In progress] https://launchpad.net/bugs/1000577
<didrocks> doing
<didrocks> popey: are you on the downstream task?
<popey> also bug the "nominate for series" button disappears when I login to lp
<popey> s/button/link/
<didrocks> popey: first, the downstream task is unity, it should be bamf
<didrocks> can you change that?
<popey> can we hangout? :D
<didrocks> sure
<popey> invited..
<c10ud> downloading LOTS of dbg packages, thank god i have a new hdd
<pitti> c10ud: note, if you do this more regularly, have a look at "man apport-retrace" and its --cache argument
<pitti> c10ud: oh, nevermind; the "Examine locally.." button uses ~/.cache/apport/retrace by default
<c10ud> i hope it's the only one time :p
<pitti> so it should be much quicker in subsequent times
<c10ud> that's what python's for, right? leaving the dirty job to someone else ;)
<pitti> hehe
<c10ud> pitti, https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/1002792
<ubottu> Launchpad bug 1002792 in pygobject (Ubuntu) "emesene crashes with assertion failed in gtkstylecontext.c" [Undecided,New]
<pitti> c10ud: ah, so it's not a segfault, and really "just" the assertion; this makes it a bit easier
<c10ud> ah i said segfault, whoops
<pitti> c10ud: is that code public somewhere, or do you have another reproducer?
<c10ud> unfortunately it's quite a big codebase, i'm not really sure on what's the culprit, i suspect the gif animation..
<c10ud> anyway you can checkout git master and launch the app with USE_GI=1 set
<c10ud> a sec
<c10ud>  wget https://github.com/emesene/emesene/zipball/master
<c10ud> extract
<c10ud> USE_GI=1 ./emesene
<c10ud> then select "dummy" session, put some random acc/pwd and connect
<c10ud> since it doesn't happen everytime you can check autologin and ctrl+c from terminal when you see the fake contact list
<xnox> Please accept/nominate bug 957494 for Quantal & 12.04.1
<ubottu> Launchpad bug 957494 in mdadm (Ubuntu) "Missing added utility 'mdmon'" [Medium,Fix committed] https://launchpad.net/bugs/957494
<ogra_> xnox, done
<xnox> ogra_: thanks ;-)
<dupondje> slangasek: question about cryptsetup. You think its clean to include upstart scripts and add some if dist == ubuntu in debian/rules? Or just keep merging it?
<ogra_> shouldnt dh_installinit DTRT actually  ?
<ogra_> without having to special case dist in a maintainer script
<ogra_> (or in rules)
<dupondje> well in Ubuntu we need a init script (for stopping) and an upstart script for starting
<dupondje> so other initlevels also
<ogra_> why do youu need the init script for stopping ?
<dupondje> to cleanly stop the crypt mapper
<ogra_> the upstart job should be capable of doing so, no  ?
<dupondje> upstart doesn't handle stopping afaik?
 * xnox is interesting in cryptsetup. What bit of code are you discussing ? =))))
<dupondje> xnox: init/upstart scripts :)
<ogra_> what do you think the "stop on" directive is for then ? :)
<dupondje> tought this was discussed before, and the conclusion was upstart could not handle it (yet).
<dupondje> mmmm :)
<ogra_> "stop on" and a script should be ablee to deal with most cases ... you can even define when exactly the script should run (pre-start, post-start, pre-stop etc)
<dupondje> upstart doesn't send a signal on umount? Cause cryptsetup needs to stop between umount & for example lvm stop
<xnox> dupondje: don't you want to listen on udev event in the upstart job in that case?
<dupondje> for shutdown?
<hallyn> is there a way in ubuntu's live-build to use packages from a ppa?  not seeing it in manpages anywhere
<vibhav> Anybody from the ubuntu-sru tea,?
<ogra_> hallyn, i think #linaro uses it all the time that way
<hallyn> thanks, theni should ask there :)
<xnox> robert_ancell: ?!
 * xnox patch pilot dropped out from #ubuntu-devel =)
<ogra_> he didnt use his belt !
<superm1> hallyn: ubuntu-defaults-builder has an option
<hallyn> superm1: interesting package
<xnox> Can somebody please set https://code.launchpad.net/~dmitrij.ledkov/ubuntu/quantal/bogl/merge/+merge/104578 as rejected or something.
<xnox> it is superseeded
<xnox> by a new merge proposal
<pitti> xnox: done
<xnox> Pici: thanks.
<xnox> pitti: thanks
 * xnox damn autocomplete
<vibhav> Could somebody check my SRU for oneiric at https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385/comments/10
<ubottu> Launchpad bug 598385 in munin (Ubuntu Oneiric) "[SRU] munin plugin exim_mailqueue has incorrect graph configuration" [Undecided,In progress]
<seb128> xnox, if you pilot you can @pilot in
<xnox> seb128: =) i'm not piloting, I'm adding my own items to the sponsorship queue ;-)
<cjwatson> merges.ubuntu.com is back up
 * xnox \0/
<seb128> xnox, ok ;-)
<geser> \o/ MoM is back
<pitti> in the meantime, thanks to http://people.ubuntuwire.com/~lucas/merges.html for sustaining us so far
<cjwatson> Let me know if you see any weirdness; the variables include new hardware, now running on precise, python2.5 -> python2.7, various code changes that were effectively undeployed for a while, and I had to roll out my change to make it set DEB_VENDOR while unpacking in order to get it to complete successfully
<geser> cjwatson: in that case, can you take the note from the MoM start page out again?
<cjwatson> Oh, yeah, I forgot about the index
<cjwatson> done
<cjwatson> I'll do a timing run shortly, but I think it should manage to complete more frequently now as well
<vibhav> doesnt MoM stand for Merge-o-Matic?
<cjwatson> Yes
<vibhav> ok
<dupondje> cjwatson: GREAT! :)
<pitti> apw: is linux-firmware-nonfree in some git repo, or can I hack on it?
<pitti> apw: I'd like to add a script to debian/rules that iterates over all modules, picks out their firmware:, and add the module's modaliases to the package's Modaliases: package header
<pitti> apw: (for the firmware files shipped in l-f-nonfree)
<pitti> apw: that fits into our current way of driver installation and gets rid of special-casing it
<dupondje> pitti: don't forget my endorsment please :) Want to drop alot of merges in the pipeline soon :)
<pitti> dupondje: it's on my list
<dupondje> ok thx
<apw> pitti, blimey ... erm ... i don't recall ever seeing a repo for it no, it would be tgardner who would know for sure, but as there isn't one on zinc i'd say its 95% likely not
<pitti> apw: ok, then I'll just use the normal UDD branch
<apw> pitti, if there is someone will have to figure it out :) and clean up after you, and i'll blame tim :)
<vibhav> the patch pilot is not online :(
<pitti> dupondje: sent now
<pitti> vibhav: yes, Robert is in Australia and apparently forgot to sign off here before going to bed
<vibhav> :(
<dupondje> thanks!
<robert_ancell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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:
<seb128> confusion cleared ;-)
<pitti> lol
<pitti> seb128: nice trick :)
<vibhav> wut?
 * vibhav waits for another patch pilot to sign in
<seb128> vibhav, the bot doesn't do any smart authentification, you can change nick to change the topic
<Laney> can't you just edit the topic?
<Laney> @pilot in
<vibhav> oh
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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
<seb128> vibhav, the calendar says you want barry
* Laney changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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> :P
<pitti> cjwatson: out of interest, why do we need the less delta still? (gz data compression)
<pitti> Laney: what was that about?
<seb128> Laney, oh ok, I though the topic was locked down
<Laney> just testing the bot, sorry for spam
<seb128> i.e it used that you needed to be op or registered to be able to change it
<xnox> Laney: is that you done with piloting for today? =)
<Laney> ah, no
<Laney> xnox: I'll send my report now!
 * vibhav sits in the corner
<pitti> Laney: you know it says "4 hours", not "4 seconds", right? :-)
<cjwatson> pitti: breaks debootstrap
<pitti> cjwatson: ah, our debootstrap covers less? curious, it's important/not-essential
<cjwatson> pitti: debootstrap installs prio required/important by default
<cjwatson> --variant minbase is prio required + apt
<ogra_> +apt ?
<ogra_> i thought it was -apt
<pitti> cjwatson: thanks
<cjwatson> ogra_: it's +apt
<ogra_> i thought adam had to hack that in for -core ... but apparently i misunderstood
<xnox> is acceptable to request sponsorship reviews from ubuntu-foundations-team for some of my sponsorship requests? e.g. sudo, btrfs-tools, mdadm
<vibhav> When the Debian Import Freeze Happen?
<ogra_> look at the release schedule ?
<geser> vibhav: around June 21st
<chrisccoulson> can we exterminate powerpc yet? :-D
<vibhav> jamespage: ping
<cjwatson> Eek, I'm TIL on sendmail, that was careless of me
<directhex> why is sendmail still shipped? i can't imagine anyone would *want* to maintain it, and the kind of person who wants to maintain sendmail should really be sectioned
<cjwatson> the Debian maintainer apparently wants to maintain it
<ScottK> We'd need libmilter in any case for postfix.
<ScottK> So you can't kill it all off regardless.
<cjwatson> Anyway as a general rule I find thinking about removals inordinately stressful compared to just fixing things ...
<vibhav> Can https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/644578 be nominated for oneiric?
<ubottu> Launchpad bug 644578 in update-notifier (Debian) "gettext required by package scripts, but not a dependency " [Unknown,New]
<vibhav> I mean the Ubuntu bug
<vibhav> bdmurray: ^^^
<vibhav> This was apparaently fixed in precise
<dupondje> cjwatson: on the MoM, check samba4. Package is in sync for 3 weeks with debian, but still it shows the Precise version in teh MoM page.
<cjwatson> In fact it's showing the oneiric version.
<cjwatson> I'll have a look, thanks.
<dupondje> hmz indeed :) thanks for looking
<vibhav> :(
<didrocks> barry: hey
<didrocks> barry: do you know if we have any package in main that can convert some pyrex syntax to C? (there is cython that we used but it's in universe and the build-dep should be in main for my specific case)
<barry> didrocks: off hand, no unfortunately.  i wonder if you can convert it and commit the converted code to the package?
<didrocks> barry: there is this pyrexc command line, isn't it? from the man, I don't see the difference with cython?
<barry> didrocks: the cython faq has some answers: http://wiki.cython.org/FAQ
<hrw> can someone take gcc-4.7-arm{el,hf}-cross out of NEW queue?
<tmus> during boot, what operation should cause pam_start session to be called? - i've added pam_limits.so to /etc/pam.d/common-session, but limits does not appear to be applied for services started automatically during boot AND running as root... Am I miserably wrong here?
<tmus> tested on lucic btw
<tmus> lucid even
<didrocks> barry: ok, so fortunately, the binding only use the pyrexc syntax and we can switch to it
<barry> didrocks: cool
<didrocks> I'm quite confident, the upstream compiz source used to use pyrexc and it seems to have switch for no other reason than you can "import cython" in setup.py
<barry> didrocks: what are they using from the cython module?
<didrocks> barry: if I grep -ri cython *:
<didrocks> setup.py:    from Cython.Distutils import build_ext
<didrocks> setup.py:            from Cython.Compiler.Main import compile as cython_compile
<didrocks> setup.py:            cython_compile ("src/compizconfig.pyx")
<didrocks> and that's it
<didrocks> so I think they are in fact just using pyrex
<barry> ah
<jamespage> vibhav, pong
<slangasek> dupondje: please just keep merging it for now.  Upstart support should go upstream to Debian in the next month or so
<dupondje> slangasek: debian goes upstart also ?
<slangasek> Debian will have upstart support
<hrw> dupondje: debian also has upstart package ;)
<ogra_> depends on the package maintainer i would say :)
<ogra_> if he listens to people filing bugs about missing upstart support :)
<cjwatson> dupondje: ah, it's because it gets a bit confused by what it perceives as removals, because samba4 isn't in testing
<hrw> ~curse bluez for failing installation when it can not start
<cjwatson> dupondje: the sanest fix/workaround is probably to just switch MoM back over to unstable, so I'll do that
<dupondje> ok :)
<dupondje> slangasek: but after that we can just include upstart script in debian? What about the init script that is used now to stop?
<slangasek> dupondje: some tuning may be required
<dupondje> but i'm right we can't use upstart atm to stop cryptsetup?
<slangasek> dupondje: I believe that's correct, we currently don't... why do we care about stopping it, though?
<dupondje> to correctly close the handle, so lvm etc can also be stopped.
<ogra_> hmm, does upstart prse "emits" from sysvinit scripts ? would be a one line change to add something to emit that info to umountroot
<ogra_> *parse
<slangasek> we don't stop lvm either :)
<slangasek> we unmount filesystems, which TTBOMK is the only part we have to tear down before reboot in order to protect data
<dupondje> So it should be safe to just remove the init script (which only is there for stopping atm in ubuntu)
<slangasek> dupondje: which init script do you mean?
<mvo> slangasek: just fyi, the quantal apt merge is prepared in the apt bzr ubuntu branch (just mentioning it to avoid duplication of effort)
<dupondje> slangasek: now we have: cryptdisks-early & cryptdisks (init scripts) and cryptdisks-enable & cryptdisks-udev (upstart)
<vibhav> jamespage: Ive created a SRU for oneiric, would you like to see it?
<jamespage> vibhav, for munin?
<vibhav> jamespage: yeah
<mterry> Is anyone familiar with FTBFS errors like "error: inlining failed in call to always_inline 'vsyslog': function not inlinable" with quantal's compiler?
<bdmurray> could some lptools hacker merge my branch? https://code.launchpad.net/~brian-murray/lptools/grab-descriptions/+merge/106469
<slangasek> mvo: apt> great, thanks :)  and good to see apt is updated in unstable as well :)
<slangasek> dupondje: right; so it's probably safe to remove those init scripts, but also not necessary in Ubuntu... and as we wouldn't be removing them in Debian that would probably be introducing more delta than we need to
<mvo> slangasek: yeah we are pretty close to upstream again, if I don't see any regression on my box I will upload tomorrow or the day after tomorrow
<jono> hey folks
<jono> quick question
<jono> in my app I would like to allow the user to start a process when they log in
<jono> what is the best way of doing this on Ubuntu?
<mlankhorst> jono: just follow standards :-)
<jono> mlankhorst, what are the standards?
<jono> :-)
<jono> I have no idea how this is done
<apw> cjwatson, i need to update the grub-gfxpayload-lists, but am struggling to find the master bzr branch for it, any idea where its at ?
<cjwatson> apw: UDD - lp:ubuntu/grub-gfxpayload-lists
<cjwatson> hmm, though it's apparently out of date there
<mlankhorst> jono: xdg-ish
<Laney> jono: http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
<Laney> jono: drop a desktop file in the appropriate directory
<cjwatson> apw: ask the last uploader :)  that'd be RAOF
<jono> Laney, aha!
<apw> cjwatson, well at least i was looking in the right place ... OI RAOF wheres the lists at :)
<apw> cjwatson, if the commit is missing, is it normal to reconstruct it and continue ?
<mlankhorst> Laney: oh nice, was already looking
<apw> cjwatson, on the assumption it was not found of course
<cjwatson> apw: best to talk with RAOF first in case he can just push
<cjwatson> but that's a fallback, yes
<cjwatson> dunno why the importer didn't sort it out
<apw> yeah who owns that so i can moan
<jono> thanks Laney
<cjwatson> apw: launchpad.net/udd
<Laney> np
<cjwatson> http://package-import.ubuntu.com/status/grub-gfxpayload-lists.html
<cjwatson> which I think is the stock "if you push --overwrite, it gets upset" reason - maxb may be able to sort that out
<apw> cjwatson, thanks
 * cjwatson comments on the bug
<maxb> hmm, hello
<dupondje> slangasek: or we fix in debian package it only installs the upstart scripts on Ubuntu, then we can sync :)
<slangasek> dupondje: fix what exactly?
<dupondje> well ship the upstart files in the debian package also, but only install them on Ubuntu. No merge needed then
<slangasek> no
<dupondje> why not?
<slangasek> why would you put the upstart files in the debian package and not ship them in the package?
<ogra_> dupondje,you want to  install the upstart jobs in debian too
<ogra_>  /etc/init/ will be a no-op if upstart isnt installed ... *if* it is installed you want the jobs to be used from there though
<maxb> apw: I've overridden the importer's freak-out over someone replacing a version in the branch and initiated a new run
<apw> maxb, thanks thats most helpful
<dupondje> ogra_: well, if you install them in the debian package, there will be a depend on upstart
<dupondje> which is not always wanted
<slangasek> no, there won't
<ogra_> there shouldnt
<dupondje> so dh_installinit should be able to handle it correctly ? lets try it out
<maxb> apw: Hm, it's done the silly thing where it rolls back all of cjwatson's commits and recommits them; it's because the bzr branch contains some files (.bzrignore, debian/bzr-builddeb.conf) which are not in the archiver
<apw> maxb, hmmm that sounds like "andy don't touch it yet"
<apw> maxb, the branch looks ok within some limits, is it as good as it is going to get?
<dupondje> https://launchpad.net/ubuntu/+source/imvirt/0.9.4-2/+build/3509707 hmz :)
<maxb> apw: Ah, yeah, don't touch it yet. I'm going to roll back what the importer did and fiddle
<maxb> What fun#
<maxb> Have run some SQL at the importer db to convince it that cjwatson's revisions can be trusted, really, and kicked it off again
<apw> maxb, sounds like spagetti fun
<xnox> Someone, please accept the quantal task in bug 978012 and assign to me ( dmitrij.ledkov )
<ubottu> Launchpad bug 978012 in e2fsprogs (Ubuntu Precise) "Please merge e2fsprogs 1.42.2-2 (main) from Debian unstable (main)" [High,New] https://launchpad.net/bugs/978012
<infinity> xnox: We don't tend to nominate tasks for the development release.  An upload to the dev release will close the parent Ubuntu task.
<xnox> infinity: ok, sorry.
<xnox> (it's the sru-s only that matter, gotcha)
<barry> kenvandine: \o/  i've removed python-egenix-mxdatetime from the porting spreadsheet.  thanks for merging it away :)
<xnox> barry: =)))
<kenvandine> barry, thank you!
<kenvandine> barry, any more info on libpeas?
<barry> kenvandine: not yet.  :/
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: barry
<kenvandine> damn
<dobey> libpeas is another very difficult problem to deal with
<barry> dobey: what do you know about it?
<dobey> barry: i know that porting every plug-in in the archive for anything in gnome is going to be painful :)
<dobey> barry: i suspect making libpeas itself use python3 probably shouldn't be too hard. but porting all the plug-ins written in python for gedit/rhythmbox/whatever else, will be very tedious
 * kenvandine wants to add a new dependency to it :)
<barry> dobey: no doubt.  but if we have libpeas for both py2 and py3 (if that's even feasible), then i suppose we can at least limit it to all the plugins for a specific application
<dobey> barry: i susepect that loading both python runtimes in the same process is just asking for a punch in the face :)
<dobey> symbol conflicts all over the place
<barry> dobey: a punch in the face if you're lucky :)
<dobey> barry: so maybe it's not so bad, but you'd have to port everything in the default install at least
<dobey> barry: and probably add new API to libpeas
<barry> yeah.  sounds like fun
<dobey> barry: the python loader is actually a plug-in to libpeas itself. so having a separate for python3 does seem feasible
<dobey> but it would require new API i think, to say "enable loading of python3 plug-ins", and both loaders would have to explicitly prevent the other from loading
<mterry> doko, are you familiar with FTBFS errors like "error: inlining failed in call to always_inline 'vsyslog': function not inlinable" with quantal's compiler?
<seb128> cjwatson, ev: we have a diff in avahi over Debian to add udeb with this rational "so that we can use them for Eucalyptus integration in the installer." ... do you know if those are still needed? I guess the installer changed since we went to openstack
<seb128> cjwatson, ev: context is https://code.launchpad.net/~laney/ubuntu/quantal/avahi/merge-0.6.31-1/+merge/105636 if you feel like commenting there
<seb128> Laney, ^ fyi
<stgraber> seb128: sounds like server team would know best. AFAIK we don't use that anywhere else
<seb128> well, I figured that installers guys would know better, but yeah, I should have pinged you as well ;-)
<cjwatson> seb128: I don't think it's still needed, but check rdepends (you might need to grep the d-i Packages file directly) and check with Daviey
<seb128> Daviey, ^
<seb128> cjwatson, thanks
<Daviey> hmm, yeah.. it's still used. sorry. :(
<cjwatson> ah, yes, maas-enlist-udeb
<cjwatson> so the use of it just moved to the new cloudy hotness
<Daviey> hawt
<highvoltage> hot clouds make for stormy weather.
<tgardner> bryceh, I've uploaded Quantal kernel and meta package backports to https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<seb128> Daviey, no worry, I figured I would check, any chance to lower delta over Debian ;-)
<Daviey> seb128: i don't think the DM was ever asked to introduce a udeb fwiw.
<seb128> cjwatson, I blame you a bit for not sending that change to Debian though, not sure if they would taken it but stil it would have increased chances to lower the delta between the distro
<seb128> Daviey, seems not, I've checked the BTS, or the bug timed out or something
<cjwatson> sure
<Daviey> seb128: Well, based on situations such as, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673618 .. i'm not sure it'll gave taken grasp.
<ubottu> Debian bug 673618 in prettytable "prettytable: Please consider converting to dh_python2" [Normal,Open]
<cjwatson> Daviey: oh please, not all Debian maintainers are the same faceless borganism
<seb128> Daviey, that happens, but at least you knwo why you carry the diff ;-)
<seb128> in the avahi case it seems that the request,patch was just never sent to Debian
<Daviey> cjwatson: i know, using any opportunity i can to moan.
<cjwatson> seb128: yes, my bad
<seb128> Laney, maybe you could try to send it the avahi udeb patch to Debian since you are doing the merge?
<cjwatson> I can't do it now, I can deal with it tomorrow if you like
<seb128> cjwatson, no worry, it happens to all of us
<seb128> cjwatson, no hurry but I would appreciate if Laney (who is doing the merge) or you would send it to the BTS
<seb128> cjwatson, thanks
<maxb> apw: I got called away from the computer, but it looks like the importer has done something sane this time
<bryceh> tgardner, thanks
<maxb> you'll see it has removed a couple of files in its commit - because they are not uploaded in the archive source
<mlankhorst> bryceh: we should discuss with raof :-)
<maxb> I'm not sure what we should be doing about that.
<bryceh> mlankhorst, yeah we need to put our heads together on the packaging snafu's you ran into
<apw> maxb, thanks ...
<mlankhorst> bryceh: what time do you want to do it?
<bryceh> mlankhorst, I've got a morning meeting with Intel (8am my time) so should be around early if you want to do it then
<mlankhorst> utc please :P
<bryceh> however raof won't be on until later (he usually comes on 1-2 hrs from now)
<mlankhorst> yeah was thinking of just s taying awake a bit longer
<mlankhorst> just ping me, off to do other stuff :-)
<bryceh> yeah I'm going to be in and out the rest of the day.  Plan tomorrow ~2100-2200
<bryceh> RAOF, ^^
<mlankhorst> bryceh: ugh utc please XD
<bryceh> mlankhorst, :-P that is utc
<mlankhorst> oh sure
<mlankhorst> ok with me, but keep in mind 22 utc is midnight for me :-)
<bryceh> mlankhorst, well if you'd prefer, just meet with each of us separately
<mlankhorst> bryceh: nah its fine, i just wont be as awake
<slangasek> cjwatson: bug #1003100 makes me sad; I figured out how to use po2debconf for merging multi-paragraph description fields, and am rewarded by the appearance of mis-translations of variable names.  I don't suppose you have any ideas how to suppress this being offered as a source string in the .pot?
<ubottu> Launchpad bug 1003100 in update-notifier (Ubuntu) "package-data-downloader: KeyError: 'paquetes'" [High,Triaged] https://launchpad.net/bugs/1003100
<dupondje> barry: just a small thing about the canto package. I noticed indeed debian still had python-support build-dep. Just tought it wasn't a reason to keep the diff. As this change nothing to the functionality
<barry> dupondje: we're more aggressive in switching to dhpy2 than debian is.  jwilk followed up on the debian bug about why that bd is there.  i'll switch it to dhpy2 for debian and file a separate bug.
<dupondje> well the build-depend was just forgotten it seems, as they adjusted debian/rules in the last commits
<barry> dupondje: do you mean a later commit switched to dh_py2?
<dupondje> http://anonscm.debian.org/viewvc/python-apps/packages/canto/trunk/debian/rules?r1=7597&r2=7623 they switched here to default version
<dupondje> not yet to dh_py2
<cjwatson> slangasek: that's creative abuse of po-debconf, given that these aren't actually templates files :-)
<slangasek> I know... ;)
<slangasek> but it's the only thing I found that would do multi-paragraph translations correctly
<slangasek> but #flag:translate! doesn't work here for whatever reason, boo
<cjwatson> because you aren't using po-debconf to create the .pot file, but rather intltool-extract
<slangasek> ah, hmm
<cjwatson> this may be possible with i-e; let me cogitate a bit
<slangasek> cool, thanks
<slangasek> in the meantime I'm just going to slam a correct null translation in so we can get on with the SRU
<cjwatson> slangasek: you might consider carrying the abuse all the way and using debconf-updatepo to generate a POT file for those files, which you then merge into the overall one
<cjwatson> the Makefile integration would be exciting
<slangasek> right
<slangasek> I have considered that
<slangasek> I just found it unspeakable so did not mention it ;)
<cjwatson> but that way, I think #flag:translate! would actually work
<slangasek> but yeah, it may ultimately be the correct thing to do here
<cjwatson> the only other approach I can think of is a hacked intltool-extract wrapper that postprocesses the generated .h wrapper
<cjwatson> I think that's probably even more foul
<cjwatson> s/ wrapper$//
<slangasek> heh
<cjwatson> slangasek: it's possible it would be easier to have two separate sets of .pot/.po files
<slangasek> hmm, point
<slangasek> I think that's probably the winner
<slangasek> will take me a bit to work through though, blah
<cjwatson> might require a bit of rosetta bodging
<slangasek> oh, really?
<slangasek> might be simpler to just merge .pot then
<cjwatson> only a tiny bit
<cjwatson> somebody'd have to approve the new paths, basically, iirc
<cjwatson> I think that's a good tradeoff for reduced build system insanity
<slangasek> well, but then you also have the ongoing requirement to re-import two sets of .po files into the source
<slangasek> so a little bit of build-time insanity we never have to look at again until the next time may be simpler overall
<cjwatson> one set of .po files in Debian and the other not?
<cjwatson> the flip side of *that* is that you might get to not have to merge one of those sets of .po files
<slangasek> oh, well, I was planning on upstreaming this interface to Debian once it had settled out :)
<cjwatson> dupondje: I've verified that samba4 is sorted, btw
<cjwatson> (on merges)
<dupondje> I saw already, thanks for fixing it :)
<dupondje> 435 merges todo in Universe, alot
<ScottK> broder: I gather you decided on changes in backports versioning at UDS.  I think this would be a nice topic for a mail to u-d-a (in addition to documentation updates).
<broder> ScottK: this was a recommendation from cjwatson which seemed quite reasonable to me. but fair enough
<ScottK> broder: I think it's a reasonable change, but it needs to be communicated.
 * broder nods
 * broder adds it to the ever-growing todo list :)
<barry> zul: ping
 * micahg would have liked an e-mail to ubuntu-backports@l.u.c
<broder> yeah, that's reasonable; there probably should have been one
<broder> i guess i was sort of waiting until we got the issues with backporter-executed backports sorted out
<broder> and then i flaked on doing that
<zul> barry: pong
<barry> zul: hi.  i have a quick question about python-tz.  in 2011k-0ubuntu4 the test suite was enabled, but then it was disabled almost immediately in 0ubuntu5.  do you remember why it was re-disabled?
<zul> barry: because it didnt actually testsuite didnt actually test python-tz
<barry> zul: oh, that's unfortunate.  what was it testing? ;)
<zul> barry: afaik timeones but i dont remember
<barry> zul: cool, thanks
<zul> np
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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-05-23
<bkerensa> barry: do you know what the bug id you open for landscape-client?
<bkerensa> in regards to the name tweak?
<bkerensa> disregard I found it >.<
<apachelogger> skaet: no status page for kubuntu quantal yet?
<skaet> apachelogger,  give me a list of blueprints you want linked, and I'll set it up.  :)
<apachelogger> skaet: groovy... https://blueprints.launchpad.net/sprints/uds-q?searchtext=kubuntu all starting with kubuntu- please :)
<skaet> apachelogger, https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-kubuntu has been setup.   for the work items to show up,  the kubuntu-q-* blueprints will need to have priority set, and have their definition approved.
<apachelogger> skaet: thank you
<apachelogger> ScottK: ^
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: TheMuso
<RAOF> Note to the KDE team: launchpad will hate you should you try to do things like https://bugs.launchpad.net/ubuntu/+source/meta-kde/+bug/1002336 - it's not possible to accept the nominations for Precise because LP times out.
<ubottu> Launchpad bug 1002336 in smokeqt (Ubuntu) "SRU tracking bug for KDE SC 4.8.3" [Undecided,Fix released]
<pitti> Good morning
<pitti> apw: apt-cache show linux-firmware-nonfree has the modaliases now :)
<pitti> apw: btw, the script spits out firwmare files which are not referenced by any module; it seems that l-f-nonfree ships an older version of the DVB-USB firmware, while linux-firmware ships the current and actually working versions
<pitti> apw: I hope that's not an accident (i. e. the firwmare is actually free)
<pitti> apw: so I guess we should remove the old one from -nonfree?
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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:
<dholbach> good morning
<apw> pitti, generally the firmware in linux-firmware comes either from the upstream firmware tree which is all redistributible or has been through legal for confirmation, if you know the filename i'll get the right people to confirm
<pitti> apw: ah, great; one example is /lib/firmware/dvb-usb-dib0700-1.20.fw
<pitti> apw: nonfree ships a -1.10 version
<pitti> apw: I don't doubt much that it's ok to have in -free now (great thing!), just saying that we can most probably ditch the old version from -nonfree?
<apw> pitti, yeah for sure, i believe the latter too, and getting rid of anything from -nonfree should be on our list for sure
<pitti> apw: not sure if you already looked at the changelog, but for now you need to run "debian/rules debian/linux-firmware-nonfree.modaliases" manually every now and then
<pitti> apw: do you see a way how this could work during build time, even on the buildds?
<pitti> apw: i. e. could we do something like build-depen on linux-generic to pull the current kernel into the buildd chroot, and iterate over that instead of /lib/modules/`uname -r`?
<pitti> apw: then the modaliases would auto-update itself during build and would always be current
<pitti> and we would also have the list of abandoned firmware files for free in every build log
<apw> pitti, hmmm i was indeed reading that changelog with dismay :)
<pitti> apw: because of the manual step, or something else?
<apw> pitti, heh yeah just the manual step, as i assume the manual step includes installing and booting the kernel from the wording
<pitti> apw: yes; IOW, you'd usually run this on your developer machine
<pitti> apw: I just don't know whether it has ever been tried to build-depend on the current kernel
<apw> pitti, which branch are you using for this, i'd like to have a look
<pitti> apw: ubuntu:linux-firmware-nonfree (the UDD branch)
<pitti> apw: I guess that would need to be something like linux-generic [i386 amd64], linux-whatever [powerpc], linux-ti-omap4 [armel, armhf], etc.?
<apw> pitti, i would expect to be able to do that indeed, build-dep on the binary kernels and do it in the build
<apw> pitti, well the issue is that its an arch: all package, so only builds on i386
<pitti> oh, right
<apw> so we'd only get the deps on that one
<pitti> so linux-generic would actually be sufficient
<pitti> apw: well, if we find out that ti-omap4 has modules that need -nonfree firmware (we don't have that ATM), we can always extend that
<apw> yeah, and probabally that'd be close enough for most use cases, if its not then we'd probabally want to do the others manually
<pitti> it's an improvement either way
<apw> yeah
<pitti> and right now (running manually) I only get linux-generic as well
<apw> pitti, i think this can be done, i'll poke it
<apw> pitti, if i want to use sed in my debian/rules do i need a builddep (and how do i work that out)
<pitti> apw: no, sed is essential
<pitti> apw: but I did forget to add a python3 build dep, for the gen-modaliases script
<pitti> apw: why do you need sed, OOI? dh_modaliases already does the substitution in the Modalises: field
<apw> pitti, this is to work out the version of the kernel that we installed by depending on linux-image-generic
<pitti> ah
<apw> it may not be sed by the time i am done, i was realising i needed to tell it about some commands, rsync for instance in the kernel package and i don't know how to know what is "essential" and therefore not necessary to mention
<pitti> apw: I guess this is a good start? dpkg-query -f'${Depends}' -W linux-image-generic
<pitti> $ dpkg-query -f'${Depends}' -W linux-image-generic | cut -f1 -d, | cut -f3- -d-
<pitti> 3.4.0-3-generic
<pitti> apw: first cut gets the first dependency, second cut chops off the linux-image- prefix
<pitti> apw: as a check I'd add a test -d /lib/modules/$version to debian/rules, so that it fails if it's not there
<apw> yep thats slightly simpler than my:
<apw> kernel_version = $(shell, apt-cache depends linux-image-generic | sed -ne 's/^  Depends: linux-image-//p')
<apw> but replies on the order ... hmmm mine is order independant
<pitti> apw: actually, using apt-cache is more clever because you don't need to build-depend on it
<apw> ok cool
<pitti> hm why does that not work here
<pitti> oh! translations
<pitti> $ LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^  Depends: linux-image-//p'
<pitti> 3.4.0-3-generic
<pitti> extra-3.4.0-3-generic
<apw> oh of course
<apw> ok
<pitti> apw: so it's still order dependent, you'd need to find the one without extra- ?
<apw> LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^  Depends: linux-image-[0-9]//p
<pitti> LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^  Depends: linux-image-[0-9]//p;'
<pitti> apw: ^ how about this?
<apw> pitti, i think thats the same :)
<pitti> ah, snap
<apw> but it loses the 3
 * pitti ch$ LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^  Depends: linux-image-\([0-9]\)/\1/p;'
<pitti> 3.4.0-3-generic
<apw> yep thats the one
<pitti> without the /me ch crap, of course
<pitti> apw: oh, hang on -- we still need to build-depend on it, as we need to iterate over the modules
<apw> right
 * apw is working on it :)
<vibhav> Is it possible for upstream to be the repository itself?
<cjwatson> apw: how do you know if it's essential> apt-cache show sed | grep ^Essential
<cjwatson> well, ^Essential:
<apw> cjwatson, awsome, thats what i wanted to know
<cjwatson> with one extra caveat: awk is "virtual Essential" by way of a Pre-Depends from base-files (i.e. the Essential facility is having one of mawk or gawk installed, although neither specific one is Essential)
<apw> pitti, subprocess.Popen communicate is barfing on a utf8 character in modinfo output, know how to fix that off the top of your head ?
<pitti> apw: oh, with python 3?
<apw> pitti, indeed using your script, was just testing my mod to take a directory for the modules, using the ones on my precise system
<apw> pitti, and there is:
<apw> author:         Bjï¿½rn Stenberg
<apw> in one of them, and it dies on it...
<pitti> hm, I already specified universal_newlines=True, so it shoudl do the decoding itself
<pitti> apw: UnicodeDecoreError, or Encode?
<apw> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 125: invalid start byte
<apw> the special 'o' there in the author: field
<pitti> oh, so it's already trying UTF-8, not ascii
<pitti> apw: try dropping universal_newlines=True
<pitti> apw: and instead
<pitti> out = modinfo.communicate()[0].decode('UTF-8', errors='ignore')
<pitti> apw: that might be fixed in quantal's kernel? It ran flawlessly on 3.4.0-2
<apw> that takes a lot longer
<apw> yeah it maybe that the modules don't have the name in the later kernel indeed
<pitti> apw: which module is that?
<apw> will find out, but i wanted to zap the bug while i was seeing it
<apw> modinfo /lib/modules/3.2.0-23-generic/kernel/drivers/usb/storage/ums-isd200.ko
<pitti> no, authors are still there
<pitti> author:         BjÃ¶rn Stenberg <bjorn@haxx.se>
<apw> but note that when you pasted it its an o"
<pitti> your special 'o' was broken here (a diamond with a question mark)
<apw> and when i pasted it it was  ... right
<apw> so i suspect its been corrected in the source to be valid
<pitti> apw: heh, funny; exactly the other way roundhere
<pitti> apw: when I do modinfo ums-isd200, I get an o with two dots on top, it looks correct
<apw> nnng
<apw> ahh no i was saying ... "right what you said" not it was "right"
<apw> and when i pasted it it was  ... "what you said"
<apw> ok ... so i think the kernel source has the name fixed or something b
<pitti> aah
<pitti> confusion FTW
<apw> but its good to catch the errors case
<pitti> right
<pitti> thanks for spotting
 * apw gets this cleaned up
<pitti> we don't really need the author or anything being UTF-8anyway
<cjwatson> apw: I expect the problem is that the output was in ISO-8859-1
<cjwatson> Yep, indeed
<apw> pitti, right ... we don't care on the encoding though i believe the kernel should be utf-8 so i am not supprised it got fixed
<apw> cjwatson, ahh that makes sense then, a common other form
<apw> pitti, and we said it needs a python3 build-dep as well yes ?  may as well fix that while i am here
<pitti> apw: when we run the script during build, yes
<apw> pitti, of course, i am running it in the build now, *slap*
<apw> pitti, it is me or are a huge number of the firmware files saying they are unreferenced
<pitti> apw: yes, here as well
<apw> ok ... then i didn't break it
<pitti> apw: I guess b43 is still a bit special, the module doesn't declare firmware:
<pitti> apw: but the various dvb bits are indeed obsolete
<apw> pitti, i shall add a WI to our config review to review it, tim can do it, he loves firmware :)
<pitti> apw: http://paste.ubuntu.com/1002650/ is what I get on quantal
<pitti> apw: we shoudl probably not print the message for b43, but the rest could be real
<dpm> hi pitti, did you have a chance to look at the example on https://bugzilla.gnome.org/show_bug.cgi?id=676543 - sorry to keep asking, it's a major blocker for shipping localized apps in our app developer process, and I'm trying to see what we can do as the next steps. Alternatively, any other pygobject/gtk people you'd suggest me to talk to, so as not to keep bothering you? thanks!
<ubottu> Gnome bug 676543 in GtkBuilder "Cannot load translations from a locale dir other than the default" [Normal,Unconfirmed]
<pitti> dpm: not yet, sorry
<dpm> pitti, no worries. Any other gtk/pygobject people I could ask?
<pitti> not sure if there is a #gtk channel on gimpnet
<seb128> dpm, pitti: #gtk+ on irc.gnome.org
<seb128> or #gnome-hackers is usually good for GNOME,GTK questions as well
<dpm> thanks seb128 :)
<apw> pitti, i notice i failed to remove the pre-built file, i've dropped that in the top if the tree
<apw> pitti, you said that b43 doesn't have aliases, but i note in the built version it actually does: Modaliases: b43(bcma:m04BFid0812rev1Dcl ...)
<pitti> apw: ah, you mean the .modalias file should be generated, and removed again after dh_modaliaes?
<pitti> apw: it does have aliases -- I said (or at least meant) that b43 does not have firmware: links
<apw> pitti, you had made one by hand and checked it in, i removed that from the bzr branch
<apw> pitti, ahh ok makes sense
<pitti> apw: right, that was necessary while it wasn't generated at build time; I guess it doesn't matter that much to keep it, but it's cleaner to remove now indeed
<apw> pitti, seems we got away with it in the builds cause it is older, but it is now gone for the next upload
<apw> pitti, i'll upload it with the cleanout of old firmwares
<pitti> thanks!
<pitti> apw: hm, in your l-f-nonfree commit, it seems you forgot to actually rm the file? or committed this after building, and forgot to rm the file in debian/rules after dh_modaliases?
<apw> pitti, ihmmm
<pitti> mvo: is there an apt config option to disable authentication checks? (for a test suite)
<apw> pitti, sorting
<geser> pitti: like APT::Get::AllowUnauthenticated?
<pitti> geser: ah, thanks; I was looking in man apt.conf, and it's not there
<pitti> ah, it's in man apt-get
<pitti> mvo: unping, sorry
<geser> pitti: /usr/share/doc/apt/examples/configure-index.gz has all the available options listed
<Daviey> pitti: if using d-i (guess you are not?), d-i debian-installer/allow_unauthenticated boolean true
<pitti> nope, regular apt
<pitti> geser, Daviey: working fine, thanks!
<pitti> tseliot: do you see a reason why ubuntu-drivers-common should not be arch:all ?
<tseliot> pitti: there's a C program for hybrid graphics which shouldn't run on archs other than i386 and amd64
<pitti> tseliot: (sorry, was at lunch) ah, I see; but the package is already built on arm{el,hf}, too?}
<ogra_> is jockey supposed to use that in the future ?
<ogra_> (do i need to make any adjustments for armhf drivers ?)
<pitti> ogra_: no, jockey is going to _be_ that in the future :)
<ogra_> ah
<pitti> ogra_: in other words, we plan to drop jockey and replace it with something much simpler
<ogra_> well, ping me if arm changes are needed
<ogra_> :)
<pitti> it was built for a lot more and different use cases that we are actually using it for
<pitti> ogra_: I have a work item to see what to do with that pvr-omap4 handler that we currently have
<pitti> ogra_: could you please check if "modinfo omapdrm_pvr" shows any modaliases?
<pitti> ogra_: i. e. is that module loaded automatically, or do you need some special magic for it?
<ogra_> will do, i have no panda running atm, gimme a few
<pitti> ogra_: no worries, not urgent
<ogra_> you dont look for the architecture ?
 * ogra_ would have thought just using archdetect would be easier 
<pitti> I'm still working on the infrastructure bits, the special cases and migration come later
<pitti> ogra_: just looking for the arch is not enough for e. g. the nvidia or the bcmwl driver
<ogra_> on arm you usually only have one driver for one SoC, its a bit easier than all these PCI and AGP cards on x86
<pitti> we need to check the system's modaliases against the patterns that the kmods specify
<ogra_> k
<pitti> ogra_: so _if_ it has modaliases which match, it will just work if we fix the package to actually declare them
<pitti> if not, we'll need a special case
<pitti> but that shouldn't be hard to do
<vibhav> Can somebody nominate https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 for Lucid?
<ubottu> Launchpad bug 598385 in munin (Ubuntu Oneiric) "[SRU] munin plugin exim_mailqueue has incorrect graph configuration" [Undecided,In progress]
<ogra_> tegra will be problematic here, it doesnt use any kernel modules
<pitti> vibhav: done
<vibhav> pitti: thanks!
<pitti> ogra_: I'll make sure we'll have replacements for all the existing handlers before we switch over
<ogra_> yeah, no hurry :)
<ogra_> tegra users are used to having to jump through hoops ... i'm happy with every release that makes it a bit easier but people usually can cope :)
<vibhav> what version of perl does oneiric and lucid use?
<pitti> $ rmadison -s lucid,oneiric perl
<pitti>       perl | 5.10.1-8ubuntu2 |         lucid | source, amd64, armel, i386, ia64, powerpc, sparc
<pitti>       perl |   5.12.4-4 |       oneiric | source, amd64, armel, i386, powerpc
<vibhav> thanks pitti !
<pitti> vibhav: rmadison is in devscripts, FYI
<vibhav> I did not know that, thanks (again)
<vibhav> https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385/comments/12 says that he is too affected by the bug, But I noticed the bug only affected perl 5.14 , any ideas?
<ubottu> Launchpad bug 598385 in munin (Ubuntu Oneiric) "[SRU] munin plugin exim_mailqueue has incorrect graph configuration" [Undecided,In progress]
<vibhav> jamespage: ^^
<tseliot> pitti: err.. is it?
<ogra_> tseliot, well, if it replaces jockey it surely should :)
<pitti> tseliot: yes, because there is a pvr-omap4 handler
<tseliot> oh
<pitti> tseliot: which needs the alternatives handling, I guess
<tseliot> right
<pitti> tseliot: I didn't write that myself
<pitti> so I can't tell much about it
<ogra_> there also will be a tegra handler soon
<tseliot> yes, I remember now
<pitti> ogra_: please don't write a new one, though; the new system shoudl be ready by next week hopefully
<ogra_> and probably an omap3 one if we ever get armhf drivers from TI
<tseliot> pitti: let's just make sure that C app is not built and installed on anything other than amd64 and i386 then
<pitti> but as long as installing a package will set up everything, we can integrate it
<ogra_> pitti, no worries, but i want all drivers supported by release
<ogra_> (all we have packages for in the archive)
<pitti> ogra_: you can certainly start packaging those, but the logic needs to be/go into the postinsts, not external
<pitti> tseliot: that can certainly be arranged
<tseliot> good
<ogra_> pitti, they are packaged since precise :)
<pitti> tseliot: and then arch:any, I guess
<pitti> ogra_: I mean, the jockey handler has an awful lot of extra code to juggle around alternatives symlinks, etc.
<tseliot> yep
<pitti> this needs to go into the postinst (if it isn't already)
<ogra_> pitti, oh, indeed, i didnt plkan to touch that right now
<vibhav> What should be the ubuntu delta for an SRU which has a previous version from debian?
<vibhav> 5.0.15-2 in unstable; should it be 5.0.15-2ubuntu0.1 for an SRU?
<pitti> yes, that will work fine
<cjwatson> It must be less than the version in the development release
<vibhav> thanks
<cjwatson> 5.0.15-2ubuntu0.1 in precise-proposed would be inappropriate if the same fix is in 5.0.15-2 in quantal
<vibhav> cjwatson: What it should be then?
<pitti> vibhav: oh, I assumed when you said "unstable" you meant "that version was synced from Debian into whichever Ubuntu release you want to SRU TO"
<cjwatson> vibhav: There is fairly comprehensive advice in https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<vibhav> pitti: Your right,I assumed that
<cjwatson> You can follow the same convention for SRUs
<cjwatson> (This is linked from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure)
<vibhav> thanks
<ScottK> RAOF: For the KDE SRU tracking bug - we've done a single bug up to now in the previous updates.
<vibhav> openerp-server is removed from precise and quantal, would it be considered sane to fix bugs for openerp-server in oneiric and other supported releases?
<ScottK> If they are serious enough to meet the SRU criteria, although I'd suspect there'd be relatively few users of a package like that on non-LTS releases so it may not be the highest priority thing to tackle.
<xnox> vibhav: please, no.
 * xnox is OpenERP developer in previous live.
<xnox> me and a few other people are in process of repackaging 6.1, 6.0 & 5.0 together with migration scripts.
<xnox> anyone running 5.0 is doomed, and they know it =)))
<diwic> seb128, I was thinking of writing a patch for sound-nua, but cjcurran has so many assorted branches of that, do you have any idea of what branch one should start with?
<vibhav> xnox: thanks!
<xnox> vibhav: I would check if CVE affect it, e.g. the recent feedparser.
<seb128> diwic, is that a patch for precise?
<diwic> seb128, probably
<seb128> diwic, https://code.launchpad.net/~cjcurran/+junk/soundnua-gtk-warnings
<seb128> diwic, don't ask about the name, he just kept working on that vcs
<diwic> seb128, all right, thanks
<seb128> diwic, that what we currently have in precise
<seb128> diwic, well rather we have that and r31 from lp:~diwic/+junk/soundnua-lp984637
<seb128> diwic, so just stack it on top of that branch of yours
<diwic> seb128, okay, thanks
<seb128> diwic, yw!
<pitti> tseliot: ok, hybrid-detect now only gets built on x86 in my latest branch
<pitti> tseliot: I'm quite satisfied for a first run with what's in the branch now
<pitti> tseliot: but I'd like to see it tested at bit on an nvidia or fglrx machine before uploading; do you have some minutes for that?
<tseliot> pitti: I have an nvidia machine here with hybrid graphics
<pitti> tseliot: it doesn't handle the hybrid special case yet (I have a WI for this)
<pitti> tseliot: I'm mainly interested whether "ubuntu-driver list" shows the nvidia cards
<pitti> tseliot: and it now assumes that merely installing nvidia-current sets up all the alternatives, etc.
<pitti> tseliot: i. e. no extra code any more that the handlers used to do
<tseliot> pitti: I thought you wanted to test hybrid-detect
<pitti> tseliot: I didn't touch the source
<pitti> tseliot: just setup.py to only build/install it on 86; I already tested taht
<tseliot> pitti: ok, feel free to send me whatever script you'd like me to test
<pitti> tseliot: the main thing that I haven't tested yet is that jockey still detects and installs the nvidia drivers with all the nvidia-common -> u-d-common renaming and changed file paths
<pitti> tseliot: i. e. check out https://github.com/martinpitt/ubuntu-drivers-common, build/install it, and test in jockey; plus ensure that "ubuntu-drivers list" shows the nvidia bits
<tseliot> pitti: which jockey shall I test it with? The one in precise?
<pitti> tseliot: that's fine, yes
<Daviey> Hmm, why is that on github and not launchpad?
<tseliot> pitti: ok, I'll test both cases
<pitti> tseliot: note that if you run precise, then the test suite will fail, it needs some fixes in aptdaemon's test module
<tseliot> Daviey: do we have git hosting on launchpad?
<Daviey> tseliot: i think you know the answer to that.
<pitti> Daviey: I branched from tseliot's nvidia-common git, which is there
<tseliot> Daviey: and that's your answer ;)
<tseliot> pitti: ok, I can probably use a quantal chroot and see if it works
<Daviey> tseliot: this is a ubuntu native codebase, right?  Not forked from a project that uses git upstream?
<tseliot> Daviey: yes
<tseliot> it's a matter of taste
<vibhav> Could anybody nominate https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/924002 for oneiric??
<ubottu> Launchpad bug 924002 in autofs5 (Ubuntu) "build system strips binaries, so no debug symbol packages available" [Medium,Fix released]
<pitti> tseliot: back in 45 mins or so, have to run for some errands
<tseliot> ok
<hallyn> sorry, I know this has been mentioned before, but is there something I can do on quantal to fix the following:
<hallyn> /gnulib/tests/test-stdalign.c:72:1: error: static assertion failed: "verify (alignof (int64_t) == offsetof (int64_t_helper, slot2))"
<hallyn> (from a libvirt build failure in buildds)
<hallyn> I thought there was a fix going in...
<pitti> tseliot: re
<vibhav> pitti: ping
<pitti> vibhav: pong
<vibhav> pitti: Could you check if  https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/924002 can be nominated for oneiric?
<ubottu> Launchpad bug 924002 in autofs5 (Ubuntu) "build system strips binaries, so no debug symbol packages available" [Medium,Fix released]
<pitti> vibhav: done
<vibhav> pitti: Could you also check the debdiff I attached?
<pitti> not right now, sorry; can you please just subscribe sponsors?
<vibhav> They are already suscribed
<vibhav> Since the bug was fixed in precise
<wookey_> anyone know if a rebuild of libc for armhf is planned? /win 29
<wookey_> it failed to build 3 weeks ago so nothing is multi-arch co-installable: https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu11/+build/3458753
<dupondje> SpamapS: you read the comments on the remmina bug? :)
<cjwatson> wookey_: Isn't it awaiting a compiler fix (infinity was working on that, I think), not simply another build attempt?
<cjwatson> wookey_: Unless you've just checked that a rebuild attempt would succeed, that is :)
<wookey_> cjwatson: looking at the log - it does look like something actually needs fixing, yes
<wookey_> does x86 libc migrate even if armhf didn't build?
<SpamapS> dupondje: not yet, just woke up
<cjwatson> wookey_: We have no migration as yet
<cjwatson> wookey_: So, er, yes and no? :-)
<wookey_> right.
<wookey_> I guess this is what happens in 'latest'.
<dupondje> SpamapS: np, first grab your breakfast :)
<cjwatson> wookey_: I'm hoping we'll get a roughly sort of testing-like migration thing in place soonish
<wookey_> I guess armel built, so I'll go back to crossing that for now, so as to get some useful output
<cjwatson> Makes sense
<cjwatson> I see the apt [] resolution bug got fixed in Debian
<slangasek> infinity: ^^ how goes it with giving us back libc on armhf?  Was the plan still to disable the biarch from that side?
<slangasek> cjwatson: it did? sweet
<wookey_> yep - on monday
<wookey_> I got some cross-build stats on unstable yesterday - 'not great' :-)
<wookey_> http://people.linaro.org/~wookey/buildd/unstable/sbuild-ma/status.html
<wookey_> needs either a lot of M-A: foreign fixes or the apt fix to make it default that way for arch:all
<cjwatson> wookey_: Do you know what's happening with :any support on Debian buildds?
<wookey_> in a word, no
<cjwatson> wookey_: We've tried to push some gettext:any patches to Debian, but they've bounced because Debian's buildd configuration means that fails to build everywhere
<slangasek> cjwatson: :any == I took an action to follow up on that
<cjwatson> Significant progress in unstable is going to be contingent on getting that fixed
<cjwatson> slangasek: right
<slangasek> of course then my irc server rebooted and I lost the record of what I'd agreed to because I don't log that client
<slangasek> but I have a general idea still :P
<infinity> slangasek: The plan for right now is just to flip libc-armel (on armhf) back to v7.
<luk_work> cjwatson, slangasek: can you poke someone to import the new cifs-utils as the currently imported one does not work at all
<luk_work> from Debian that is
<cjwatson> luk_work: A package sync you mean?
<luk_work> right
<cjwatson> luk_work: looking
<cnd> slangasek, a utouch-geis sru was uploaded after the archive branch but before quantal was open, it needs to be copied over to quantal
<slangasek> (i.e., :any support needs backported for DSA)
<cnd> how do I make that happen?
<infinity> wookey_: Sorry about that, I didn't think that it would be an issue for your M-A work, I'll upload a fix today.
<slangasek> cjwatson: <grunt> apparently it's a merge
<cjwatson> Yeah, was just looking at that
<wookey_> any opinoin on whether I should file a lot of M-A: foreign fixes or try and get the apt behaviour change in?
<slangasek> Daviey: ^^ you merged the critically-broken version of cifs-utils, can you merge the fixed one? ;)
<luk_work> would solve #903888 and #1001680
<wookey_> #666772
<cjwatson> wookey_: ultimately both, but we should get the apt behaviour change done I think since it makes things a lot more practical ...
<bdmurray> dobey: could you review https://code.launchpad.net/~brian-murray/lptools/grab-descriptions/+merge/106469
<Daviey> slangasek: why is it we have a +1 team again? :)
<slangasek> Daviey: not to clean up after the server team :P
<cjwatson> Daviey: the +1 team doesn't have a charter to do all the work themselves
<Daviey> cjwatson / slangasek: right, but it's a QRF to solve issues like this? no?
<Daviey> Anyway, yes.. i'll take it.. but i can't do it /right now/.
<infinity> Daviey: The +1 team's biggest job is to annoy other people to fix their bugs.
 * Daviey pretends he is annoyed.
<tseliot> pitti: yes?
<pitti> tseliot: just said "I'm back" back then, in case you wanted to discuss some stuff
<slangasek> Daviey: the +1 team's main charter is to give us a consistent archive.  cifs-utils doesn't break the archive, just itself
<tseliot> pitti: ah, ok, sorry too many pings at the same time ;)
<pitti> actually, http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html had beer for most of the day :)
<Daviey> slangasek: don't try and use logic to combat my slippery shoulders.
<slangasek> :)
<pitti> the ti-omap4 breakage is very very recent
<Daviey> slangasek / cjwatson: For the avoidance of doubt, i wasn't being serious.
<slangasek> :)
<infinity> pitti: Yeah, the kernel team likes to drop building tools every second release. :P
 * pitti waves good night, time for sport
<tremolux> slangasek: hey! we (the Software Center team) have an SRU 5.2.2 that's in process, as you know, but we have unfortunately discovered a regression in one of the fixes (bug #1002271)
<ubottu> Launchpad bug 1002271 in software-center (Ubuntu) "REGRESSION: crash in cell renderer" [Medium,In progress] https://launchpad.net/bugs/1002271
<tremolux> slangasek: and another of the fixes was inadvertently disabled in the release, so three bugs can't be strictly verified
<tremolux> slangasek: so we are wondering if the best approach is to release 5.2.3 now, which we have in the queue and is ready to go, or should we cherry pick the specific fixes for a 5.2.2.1 release? to me, it seems the former is best as either case will reset the clock, no?
<slangasek> tremolux: I think the latter is far preferable... otherwise we can be on that verification treadmill indefinitely
<tremolux> slangasek: but, doesn't the clock reset in either case? the former will just add a few more to the already large number that we have to deal with anyway ;)
<tremolux> slangasek: unless a cherry-pick can shorten the 1-week hold time, I don't see it buying us too much, but maybe I don't know all the gritty details
<slangasek> is everything in 5.2.3 an SRU-worthy bugfix?
<slangasek> from my POV, the number of bugs in the previous upload is already on the far end of what the SRU process can effectively handle
<tremolux> slangasek: yes, I think we are fixing all worthy bugs, many or from errors.ubuntu.com
<tremolux> slangasek: is the issue the sheer number of bugs for each release?
<slangasek> tremolux: yes
<tremolux> slangasek: we are trying, as a team, to take a policy of releasing all bug fixes that don't break UI/strings/etc. back to Precise
<slangasek> right - but we need to have discrete points where we can validate one batch and push it through to -updates
<tremolux> slangasek: and we want to continue this for the next couple of weeks
<slangasek> and a backport against the current SRU would help that process along
<tremolux> slangasek: I'm sorry, I'm not sure what you mean by a "backport against the current SRU", you mean just fix the regressions?
<slangasek> yes
<slangasek> so we can finish this one, push it through, and then do the next SRU
<slangasek> instead of getting wedged in -proposed
<tremolux> slangasek: ok, so then it won't reset the clock on the SRU?
<slangasek> tremolux: it resets the clock on the report... but we can override
<tremolux> slangasek: that's what my concern was, if we are resetting the clock again, might as well just take the next set of fixes too, but I see your point of course
<tremolux> slangasek: ok, then we will do a 5.2.2.1, thanks for your help/advice!
<slangasek> tremolux: great, thank you :)
<vibhav> foobar6.1 waits for verification in oneiric-proposed , can I upload fixes into oneiric-proposed using version foobar6.2 ?
<micahg> vibhav: you should wait until the previous SRU completes unless this fixes a regression in that SRU (you can also help the process along by verifying the fix)
<vibhav> fine
<geser> does somebody have an idea why apt tries to download the uncompressed Packages file? as that file doesn't exist it results in a 404. I've seen two users with this problem in the recent days. Or is it an mirror issue as both used the same mirror?
<vibhav> geser: Which mirror?
<geser> de.archive.u.c
<vibhav> micahg: Did you check the application I sent to the bug control?
<micahg> vibhav: #ubuntu-bugs would be better to discuss
<ScottK> wgrant: Do we still have the Ubuntuwire FTBFS pages for previous releases?  If so, what would be the link for precise?
<geser> ScottK: http://qa.ubuntuwire.com/ftbfs/precise.html
<ScottK> geser: Thanks.
<ScottK> I guess that doesn't include -proposed?
<geser> it probably would if the precise page would still get updated, but the last update was 2012-04-27
<ScottK> Ah.
<ScottK> wgrant: ^^^ can it be updated?
<infinity> ScottK: pending-sru has a nice view of FTBFS in proposed.
<ScottK> infinity: Thanks.
<infinity> ScottK: http://people.canonical.com/~ubuntu-archive/pending-sru.html <-- Search for ia64, for instance.
<infinity> Well, I'm not sure that view is "nice", per se.  But it's there. :P
<ScottK> That does what I need.
<ScottK> Trying to make sure I retried everything from the stack of KDE packages that fail due to build-dep installablity.
<ScottK> Speaking of which ...
<ScottK> infinity: How does the plan to implement a rough equivalent of BD-Uninstallable for Soyuz?
<infinity> It's somewhere in my TODO.  Nothing specifically planned to happen.
<infinity> I might get fed up and JFDI on a plane or something.  Dunno.
<ScottK> Please.
<geser> so we just need to buy a plane ticket for infinity once around the world?
<dobey> can someone with perms to upload cython do this please? "syncpackage --force -d unstable -r quantal cython"
<dobey> the patch that created the ubuntu diversion is included in debian now
<geser> dobey: syncpackage: Request succeeded; you should get an e-mail once it is processed.
<dobey> cool, thanks geser
<PaoloRotolo> Hi all!
<mlankhorst> heya
<mhall119> how can I get quilt to apply a patch to a soure that is in a .orig.tar.gz?
<mhall119> do I have to manually extract it?
<Daviey> mhall119: depends what you want as an outcome.. Normally the patch would be in debian/, *not* in the orig tarball
<mhall119> Daviey: my patch is in debian/patches
<Daviey> if you are putting it in the orig tarball, you are repacking it.. which is not normally what we'd do
<mhall119> but it's removing a file in the source package
<Daviey> mhall119: for legal reasons?
<mhall119> for build reasons
<slangasek> that smells odd to me
<mhall119> python-django-openid-auth has a Makefile for running tests, but it causes bzr builddeb to not include any of the actual code into the binary deb
<slangasek> why patch out the file for build reasons, instead of patching the build system to DTRT?
<Daviey> sounds like a bad import of upstream into bzr
<Daviey> or bad 'make'
<mhall119> it *is* a bad make
<mhall119> the Makefile isn't used to build the source
<slangasek> so is the problem that you're using dh, dh_auto_build is invoking make when it shouldn't?
<Daviey> mhall119: can you post a bzr branch?
<mhall119> but when it's there, the setup.py seems to be ignored
<slangasek> right
<slangasek> so you need to edit debian/rules to tell it the right way to build the package
<slangasek> rather than patching the upstream source
<mhall119> Daviey: lp:django-openid-auth
<mhall119> slangasek: okay, I currently have for debian/rules:
<mhall119> #!/usr/bin/make -f
<mhall119> %: dh $@ --with python2
<mhall119> with proper formatting, of course
<mhall119> which works fine when the Makefile isn't there
<mhall119> http://paste.ubuntu.com/1003370/ is the contents of Makefile
<slangasek> mhall119: dh $@ --with python2 --buildsystem=python_distutils
<slangasek> mhall119: should give preference to setup.py over the Makefile
<slangasek> mhall119: contents should be ignorable, with the above debian/rules tweak :)
<mhall119> yup, that did it, thanks for the help slangasek and Daviey
<dasKreech> Hello can I get some help with a USB ethernet adapter?
<dasKreech> I've loaded the driver for it (I think) but it resets everytime I get an IP address which also happens to be a recent NM bug
<dasKreech>  how can I debug if it's the driver causing the issue?
<dobey> dasKreech: you want #ubuntu for help
<dasKreech> I was told to ask here but ok
<hallyn> hm, someone re-pushed the libvirt, and it built?  I assume.... but i didn't re-push
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: bdmurray
<hyperair> dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libc.so.6 (used by debian/libtinyxml2-0.0.0/usr/lib/x86_64-linux-gnu/libtinyxml2.so.0.0.0).
<hyperair> weird, what's up wit hthat error?
<slangasek> hyperair: implies you're missing /var/lib/dpkg/info/libc6:amd64.{shlibs,symbols}
<hyperair> slangasek: yeah, i thought so too, but they exist.
<slangasek> hmm
<hyperair> i'm checking to see if dpkg-shlibdeps is looking for the non-multiarch path
<stgraber> smoser: can you have a look at bug 1003595?
<ubottu> Launchpad bug 1003595 in resolvconf (Ubuntu) "resolvconf 1.63ubuntu14 upgrade error: /etc/resolv.conf isn't a symlink, not doing anything" [Undecided,New] https://launchpad.net/bugs/1003595
<stgraber> (not really a bug)
<slangasek> if it's not really a bug, why looking at it? :)
<smoser> utlemming, ^
<smoser> utlemming did some things to deal with that symlink i think when it first started causing build issues.
<stgraber> slangasek: because it's not a resolvconf bug but the cloud stuff is apparently removing the /etc/resolv.conf symlink and replacing it by a static file
<smoser> (when you added resolvconf, stgraber )
<stgraber> slangasek: which is "allowed" but shouldn't be the recommended way of doing it, even less so on an official ubuntu image
<smoser> but i dont remember exactly, only that we did have build failures, as a result of it.
<stgraber> smoser: yeah, it took a few weeks to get all the possible build scripts to deal with it properly
<stgraber> smoser: though most of them now use a static resolv.conf at build time, then move the symlink back to place before finishing the build. It looks like the one for the cloud stuff doesn't
<stgraber> which effectively disables resolvconf completely...
<slangasek> stgraber: right - so it's a bug, just not a resolvconf bug, gotcha
<smoser> we need to fix that in the images for sure.
<stgraber> smoser: what package should I assign that bug to?
<smoser> stgraber, its just "ubuntu"
<hyperair> slangasek: aha, i had some garbage at the bottom of /var/lib/dpkg/info/shotwell.list for some reason.
<stgraber> smoser: ok, anyone in particular to assign it to? utlemming?
<smoser> stgraber, yeah.
<geser> cjwatson: as you did the last proper merge of fuse (before I became TIL for it with a FTBFS fix), do you have time to review/sponsor the current merge? bug #1003613
<ubottu> Launchpad bug 1003613 in fuse (Ubuntu) "Merge fuse 2.9.0-1" [Undecided,New] https://launchpad.net/bugs/1003613
<bdmurray> bryceh: you modified the description in bug 887806 - is that manual or automatic?  do they end up getting filled out?
<ubottu> Launchpad bug 887806 in wxmaxima (Ubuntu Precise) "wxmaxima is not in the 'open with' nautilus menu" [Undecided,Confirmed] https://launchpad.net/bugs/887806
<bryceh> bdmurray, manual
<bdmurray> and is the intent for the debdiff adder to modify the description with test case etc?
<bdmurray> cnd: in theory ginn will be updated in quantal making the patch in bug 769959 unnecessary right?
<ubottu> Launchpad bug 769959 in ginn (Ubuntu) "accumulate property is undocumented" [Wishlist,Triaged] https://launchpad.net/bugs/769959
<SpamapS> [578849.820024] [Hardware Error]: Machine check events logged
<SpamapS> run roh
<cnd> bdmurray, ginn is going to be removed from main
<cnd> and we aren't going to support it any more
<cnd> if you want to help develop it and fix issues, please feel free to contribute, but it's essentially a community project now
<barry> xnox: are you sure the transition tracker is getting updated correctly?  i removed egenix-mx-* from the spreadsheet but it's still showing up as a level 1 dependency
<Laney> that is the problem with manual lists
<barry> yeah, but i thought he had it set up to pull automatically from the googledoc
<barry> maybe not tho
<Laney> nope
<Laney> i'm not sure the transition tracker is suitable for this if you need it to be dynamic
<slangasek> barry, Laney: maybe it would be a good idea to sunset the spreadsheet (which has to have manual status updates) in favor of the transition tracker?
<slangasek> or is the transition tracker itself configured awkwardly right now?
<cjwatson> geser: OK
<cjwatson> (modulo kind of falling asleep now)
<Laney> slangasek: no, not really. Whoever just needs to be added to the ~ubuntu-transition-trackers team.
<Laney> as long as the spreadsheet isn't tracking anything more than the transition tracker does
<Laney> like notes.
<cjwatson> Which it kind of is right now, isn't it
<cjwatson> ?
<Laney> not seen it
<barry> yeah, the spreadsheet does have useful notes
<Laney> we could just put barry in the team so that he can update the .ben file
<Laney> cjwatson: ^ ?
<barry> we could always move the useful notes (i.e. not the "unknown" bits ;) to the blueprint
<cjwatson> sure
<cjwatson> Done
<barry> let see if i can push an update
<geser> cjwatson: no hurry, it would be probably better when you are more awake when reviewing this as I hope I got the postinst merged sanely and as fuse changed from an init script (which we drop) to udev rules (which I assume we should drop too), it might be good if someone double-checks that dropping it is correct.
<bdmurray> I'm looking at bug 965772 and the upstream mutt bug has a 2nd patch which fixes the issue.  However, the first incorrect patch was included in debian.  So what is the right way to add the good patch to the package or should I just let debian handle it?
<ubottu> Launchpad bug 965772 in mutt (Ubuntu) "mutt-org crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/965772
<cjwatson> geser: oh ow right
<geser> bdmurray: both, for a SRU we should replace the wrong patch with the good one and for quantal wait on Debian (or go ahead now and merge later as we already have Ubuntu delta)
<bdmurray> geser: but replacing the contents of the patch is correct?
<geser> bdmurray: yes, but you can also drop the old patch and include the new one with a different name (makes probably the review easier as reading a diff of a diff isn't fun)
<bdmurray> geser: great, thanks1
<barry> Laney, cjwatson update pushed
<LinuxAdmin> hello guys
<LinuxAdmin> I'm an experienced c# developer
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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:
<LinuxAdmin> I hold love to start developing for ubuntu and debian
<LinuxAdmin> I hold, I mean
<LinuxAdmin> oh my god, I don't know what's happening with my keyboard
<LinuxAdmin> I want to experience to contribute with bug correction
<LinuxAdmin> can I get some help in this channel if I have some questions?
<slangasek> LinuxAdmin: welcome!  if you mean fixing bugs in Ubuntu, definitely - that's what the channel's here for
<LinuxAdmin> I have a lot to read, I don't make development in C for a long time, although I'm an experienced developer
<LinuxAdmin> but that was my favorite language at the high school time
<LinuxAdmin> I know motu is passing for a lot of changes and it seems easier to contribute
<LinuxAdmin> i would love to start contributing for ubuntu and get deeper again in C language
<SpamapS> LinuxAdmin: There are some C# programs still around in Ubuntu, so you can use your knowledge there too. :)
<LinuxAdmin> SpamapS, your talking about mono project, right?
<SpamapS> LinuxAdmin: yes, 'apt-cache rdepends mono-runtime' shows quite a few packages
<SpamapS> f-spot .. banshee..
<LinuxAdmin> I've read a few months ago that mono project was end of line
<LinuxAdmin> is it still under development?
<ajmitch> yes, mono is still being developed
<LinuxAdmin> maybe it's a good way to go, in my case
<LinuxAdmin> but I think I'm more interested about C language on Linux environment
<LinuxAdmin> I'm going to read developer help pages on ubuntu website
<LinuxAdmin> thank you for answer
#ubuntu-devel 2012-05-24
<cjwatson> cjohnston: Any idea why http://status.ubuntu.com/ubuntu-quantal/canonical-foundations.html hasn't updated in over a day?
<pitti> Good morning
<ajmitch> morning pitti
<geser> good morning
<dholbach> good morning
<dholbach> hey pitti, so the translations in /opt problem was not a gtk problem after all?
<pitti> dholbach: I didn't hear any news about this since yesterday
<dholbach> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=676543#c4
<ubottu> Gnome bug 676543 in GtkBuilder "Cannot load translations from a locale dir other than the default" [Normal,Resolved: invalid]
<dholbach> seems we need to document it properly, so apps authors know how to special-case shipping in /opt :-/
<pitti> ah :)
<pitti> what a bad trap to fall into
<pitti> I thought gettext.bindtextdomain() would actually set it in glibc
<dholbach> yeah, it's a bit unpleasant
<alexbligh1> When building a package, what is the approved dh_ method of installing files with an owner other than root?
<alexbligh1> (specifically in this case into /etc)
<pitti> alexbligh1: call dh_fixperms with some -X options to ignore these files
<alexbligh1> pitti, thanks
<pitti> alexbligh1: haven't (recently) tested that myself, but it ought to work
<pitti> alexbligh1: HOWEVER
<pitti> alexbligh1: this is only valid if the files you ship are owned by a static system user, i. e. uid < 100
<alexbligh1> pitti, but how do I get them owned by non-root in the first place?
<pitti> alexbligh1: for a dynamic system user (created with add_user), you need a postinst which calls chown for you
<alexbligh1> (it's www-data)
<pitti> ok, www-data is a static one, that works
<alexbligh1> Currently I am doing a chown -R in my postinst, but I worry that when I next install the package, it will think the user has changed the perms, and not update the file.
<pitti> alexbligh1: chown?
<alexbligh1> owner
<alexbligh1> yes
<alexbligh1> pitti, ah, dh_fixperms is permissions. I need *owner*
<pitti> alexbligh1: yes, what I said; your "make install" or whatever chowns them to www-data, and then you tell dh_fixperms to not change it back to root
<pitti> alexbligh1: dh_fixperms sets files to root:root by default
<alexbligh1> is the chown in postinst safe? Or might it have problems as set out above in upgrading? chown seems far easier
<pitti> alexbligh1: you should check dpkg-statoverride if you reapply them on upgrade
<pitti> alexbligh1: but you can just call chown if [ -z "$2" ], i. e. on first install
<alexbligh1> pitti, thanks
<apw> pitti, hey ... have we manually overridden the ddeb remover?  it seems that the natty release kernel ddebs are gone?
<pitti> apw: yes; we again ran out of space :/
<pitti> and since the RT to add more is still pending, I needed some drastic measures :(
<pitti> otherwise we would have lost quantal
<pitti> so we now have lucid, oneiric, precise, and quantal
<Daviey> pitti: does the RT have suitable levels of priority attached to it?
<apw> pitti, should we need them does IS have them on backup somewhere ?
<smb> Like lava-hot-burning-ass ?
<pitti> https://rt.admin.canonical.com/Ticket/Display.html?id=52633
<pitti> PrioritÃ¤t: 0/
<pitti> I guess not
<diwic> apw / pitti, can't we just rebuild the package with pkg-create-dbgsym installed?
<diwic> If there's a particular package we desperately need it for.
<apw> diwic, perhaps, am trying it now, but th
<apw> the old 3.x/2.6.x issue is biting me as the kernel is sooooo old
<apw> infinity, when we did --uname-2.6 stuff did schroot gain a personality type for it too ?
<cjwatson> apw: setarch x86_64 --uname-2.6 schroot ... #  ?
<cjwatson> I guess that's less convenient than schroot knowing for itself
<apw> cjwatson, yeah, the chroot kind knows for 32bit so it seems orthoganal to have it inside but yes linux64 --uname-2.6 seems to work ok for me
<cjwatson> I don't see support for any of the personality options in schroot, anyway
<jamespage> vibhav: (late response) I don't think that bug is effected by the perl version - just the memory monitor one we did for precise
<Caribou> apw: pitti: what's the best way / less disruptive way to mirror an archive ?
<Caribou> the kernel ddebs are only 120Gb, I'll make a copy somewhere
<pitti> Caribou: debmirror is reasonably easy to use and quite robust, AFAIK
<pitti> I had used it years ago, but not recently
<Caribou> pitti: ok, I'll try that, thanks
<pitti> :w
<pitti> err, EFOCUS
<dholbach> popey, wow - so you're going to maintain the unity/bamf/etc packages now? :)
<popey> thanks âº
<popey> (I think)
<dholbach> :-)
<cjwatson> wookey_: dunno if you noticed, but libc6-dev/armhf should be happier now, thanks to Adam
<xnox> http://www.gtk.org/ got a new layout with 'Avatar'-like tubes hanging of it, interesting.
<xnox> just noticed....
<seb128> bdmurray, is bugbot your bot?
<seb128> why did it tag https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1001249 "lucid"?
<ubottu> Launchpad bug 1001249 in xorg-server (Ubuntu) "EYE for Gnome 3.4.1 installed with Ubuntu 12.04 freeze the computer when displaying jpeg pictures from my nikon camera this is not the case with my 10.04 install having EYE 2.30 'tested with same pics'" [High,New]
<seb128> it's a precise user
<wookey_> cjwatson: I hadn't. but yes I see a -12 now. That should come through in tomorrow's build results. (which I've just noticed say 'armle' even though they are armhf. That's rebuildd being thick (and currently hacked somewhat) I think.
<dupondje> could anyone upload https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1000356 for me? Will check for SRU also
<ubottu> Launchpad bug 1000356 in freerdp (Ubuntu) "remmina/xfreerdp crashes while trying to use 'remote control'" [Undecided,In progress]
<vibhav> Who has the upload rights to main?
<sladen> vibhav: https://launchpad.net/~ubuntu-core-dev + per-package-uploads
<vibhav> thanks
<cjwatson> mvo: Does http://bugs.debian.org/674338 ring any kind of bell for you?  It seems like it's probably an apt bug ...
<ubottu> Debian bug 674338 in src:germinate "germinate: FTBFS: test failed" [Serious,Open]
<mvo> cjwatson: yes, its a recent regression with python-apt/apt in debian/unstable
<cjwatson> mvo: Do you happen to have the bug number to hand?
<cjwatson> That said the strace seems to suggest that the EBADFs are in dealing with a seed file ...
<tjaalton> is the relaxed sru policy still under review, or is there hope for bugfix release sru's for precise sometime soon?
<cjwatson> My code looks OK though, perhaps some coincidental interaction
<mvo> cjwatson: not right now, but I hope to find time to work on it today, juliank did figure out the issue already
<smoser> stgraber, around ?
<cjwatson> mvo: ok, cool, I've lobbed the bug over to python-apt as a first step
<mvo> ok
<juliank> cjwatson: It's a simple bug where apt passes a file descriptor to gzip, which closes it automatically, whereas the descriptor should not be closed automatically (unless requested so using an AutoClose flag in APT's FileFd)
<cjwatson> OK
<cjwatson> I like it when my test failures turn out not to be my fault
<mvo> :)
<xnox> stgraber: rumour has it you run ubiquity from lxc container for testing is that true?
<seb128> SpamapS, hey
<Bluefoxicy> what ever happened to deb patching anyway?
<Bluefoxicy> somebody changes 1 line of code in libreoffice and you have 6 packages to update and 300MB to download
<Bluefoxicy> Hell, somebody changes a 'recommends' to 'suggest' in LibreOffice and you have 6 packages to updated and300MB to download
<zul> mterry: ping
<mterry> zul, pong
<zul> mterry: we have a couple of MIR that are blocking us, dwarves-dfsg, python-jsonschema, and python-repoze.lru can they be looked at toute suite?
<zul> its also blocking some SRUs as well
<dobey> oi i need to do some MIRs
<mterry> zul, OK.  What's the SRU connection?
<zul> mterry:  dwarves-dfsg is libvirt and python-jsonschema, python-repoze.lru (new deps for python-routes) is glance related
<pitti> mterry: speaking about MIRs, are you aware that your openal-soft merge introduced quite a few new universe deps?
<mterry> pitti, aw darn it.  I forgot to check for that
<pitti> I created some MIRs for many other universe deps after the intial debian syncs/merges, and also dropped a few dependencies
<mterry> zul, sorry, am still confused.  Why does an SRU for precise care which component a quantal package is in
<zul> mterry: because we need to fix glance in quantal in order to start an SRU for it and its blocked on jsonschema not being in main, and python-repoze.lru being a new build deps for python-routes
<mterry> zul, OK, can start looking now
<zul> mterry: thanks
<stgraber> smoser: around now
<stgraber> xnox: yes, I run part of ubiquity in containers on my machine, though I doubt it'll work for you as I'm guessing you're working on partitioning and there isn't much we can fake from a container for that part
<xnox> =(
<xnox> ok
<xnox> thanks
<xnox> stgraber: do you get point & click interface though? =)
<stgraber> xnox: yes
<smoser> stgraber, i think i was going ot ping about bug 993794
<ubottu> Launchpad bug 993794 in network-manager (Ubuntu) "Precise can't connect to a network guarded by an authentication webserver whose address can only be looked up with one of the nameservers whose address is provided by DHCP" [Medium,Confirmed] https://launchpad.net/bugs/993794
<smoser> but i then realize its not actually a resolvconf issue, but really more network manager's issue
<stgraber> smoser: yeah, that has to do with the way dnsmasq balances the requests between the servers, I believe it mostly happens when the secondary servers answer faster than the primary one
<smoser> well, its a generic issue. not related to speed really.
<stgraber> well, in theory dnsmasq will send the request to the server with the lowest latency, so if you primary server is the fastest one, you'll get the right record back
<tseliot> pitti: I'm trying to build ubuntu-drivers-common in my quantal chroot: http://paste.ubuntu.com/1004747/
<pitti> tseliot: hmm, thanks; I tried to build an earlier version in my PPA successfully, but that was two days ago already
<pitti> tseliot: that's with latest aptdaemon, I presume? 0.43+bzr810-0ubuntu3 ?
<tseliot> pitti: let me check
<mterry> zul, for python-repoze.lru, is there a reason to not sync back up with Debian (we added delta to run tests, but added "|| true" because the tests failed on buildd) -- could we be more selective with tests that don't need network access?
<zul> we could be more selective
<zul> mterry: but im not sure how
<tseliot> pitti: the chroot used aptdaemon_0.43+bzr810-0ubuntu3
<pitti> tseliot: ok, thanks; I'll build a chroot here to replicate this
<tseliot> ok, thanks
<pitti> tseliot: so, a local dpkg-buildpackage still works fine here; I need to run out for a bit, but letting that chroot build in the meantime
<tseliot> pitti: ok, I'll try that
<slangasek> roaksoax: you appear to have dropped the dh_python2 delta in python-xattr by syncing it - this is not ok, python-support is package non grata in main.  Can you please move this back to dh_python2?
<roaksoax> slangasek: ah yes, my bad.. missed the fact that python-support was a Dep, while the package was being build with python2 from debian. :) Thanks for noticing
<slangasek> roaksoax: the components-mismatches report makes us notice ;)  thanks in advance for fixing :)
<roaksoax> slangasek: :) is this sent over the ML?
 * roaksoax needs to wake up... need more coffee
<stgraber> roaksoax: that's sent to the ubuntu-release ML
<roaksoax> stgraber: cool thanks
 * roaksoax needs to update his spam filters :)
<roaksoax> and subscribe to it
<tseliot> pitti: building it locally inside a chroot: http://paste.ubuntu.com/1004842/
<SpamapS> seb128: hey back. :) Whats up?
<seb128> SpamapS, is there any way you could review 2 SRU candidate for me today?
<seb128> SpamapS, unity and bamf in precise (unapproved), those are overdue and I would really get them out before the w.e but not on friday in case there is any issue...
<seb128> SpamapS, if you don't have time I will try with chance with slangasek or infinity next ;-)
<seb128> SpamapS, hey btw, how are you? ;-)
<bdmurray> seb128: that's bryce's bot
<seb128> bdmurray, thanks
<seb128> bryceh, hey, how is you bot deciding that a bug should be tagged "lucid"? it tagged a precise report "lucid" ;-)
<slangasek> seb128: why is friday a concern for pushing to -proposed?  (not that I don't think we shouldn't get them out ASAP)
<seb128> slangasek, "I'm there for too long", "french paranoia", "pick something that doesn't make sense to others" :p
<seb128> slangasek, basically just me being paranoid about friday uploads
<slangasek> seb128: well... it's -proposed, we don't require or warrant them to be regression-free at that point :)
<seb128> right, I still like to be around and to be able to deal with any issue if there would happen to be one
<SpamapS> seb128: I'll do as many reviews as I can today. Will start in about 1 hour.
<seb128> SpamapS, thanks
<SpamapS> seb128: lots of uploads from kde update too, so the queue is getting backed up
<seb128> SpamapS, well as said I would appreciate to get that unity one out, it's over due and fix some annoying bug in the default desktop on the lts
<seb128> SpamapS, the other desktopish ones from me have lower priority
<seb128> SpamapS, (bamf is included in the "unity update set" btw)
<slangasek> SpamapS, seb128: let me go ahead and queue-jump those two
<seb128> slangasek, thanks! ;-)
<slangasek> seb128: btw, do all of the changelog-referenced bugs have test cases in the description?  I'm going to be a hard-nose about that going forward :)
<seb128> slangasek, yes, though the format is not strict, i.e they don't all start with TESTCASE:, but they all have steps to trigger the issue and what to test in the description
<slangasek> ok, sounds good
<seb128> slangasek, didrocks has been strict on that, that's one of the reasons the SRU is coming a bit later in the week that planned ;-)
<slangasek> cool ;)
<SpamapS> slangasek: thanks :)
<pitti> tseliot: ok, I get the same errors in my pbuilder
<tseliot> pitti: I hope those errors make sense to you
<tseliot> I really don't know what's going on
<pitti> tseliot: they don't make sense to me yet, looking now
<tseliot> hehe, ok
<dupondje> could anyone upload https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1000356 for me? Should be SRU'ed also
<ubottu> Launchpad bug 1000356 in freerdp (Ubuntu) "remmina/xfreerdp crashes while trying to use 'remote control'" [Undecided,In progress]
<seb128> dupondje, try asking chrisccoulson or mterry they are patch pilot today according to the schedule
<seb128> doh, though chrisccoulson still didn't apply for upload rights I think
<chrisccoulson> i'm meant to be patch pilot today? :/
<chrisccoulson> man, i suck ;)
<dupondje> come on!
<dupondje> :D
<chrisccoulson> why do my patch pilot days always collide with firefighting?
<seb128> chrisccoulson, yes you are! didn't google calendar email you? ;-)
<micahg> remmina is in desktop
<mterry> seb128, I will patch pilot, but I'm busy doing MIRs to unblock people now.  :(
<seb128> chrisccoulson, is there any day you are not firefighting?
<mterry> dupondje, I will look at it later today if chrisccoulson doesn't first
<seb128> mterry, no hurry ;-)
<pitti> tseliot: ooh, it makes perfect sense now
<tseliot> pitti: what is it?
<pitti> -    @unittest.skipUnless(os.path.isdir('/sys'), 'no /sys dir on this system')
<pitti> +    @unittest.skipUnless(os.path.isdir('/sys/devices'), 'no /sys dir on this system')
<pitti> tseliot: pbuilders/chroots have an empty /sys
<pitti> but it tries to access /sys/devices/
<dupondje> micahg: its bug in FreeRDP lib :)
<tseliot> pitti: ok, that would explain it
<pitti> tseliot: pushed
<micahg> ah, yeah, freerdp is in core
<pitti> tseliot: I get some more errors in my pbuilder, but these two are the ones you got
<dupondje> Would like to fix some more things in Remmina/FreeRDP later on
<dupondje> cause there seems to be alot of complaints
<tseliot> pitti: can I pull the code? (in my local branch)
<dupondje> broken things :(
<pitti> tseliot: yes, I pushed to my branch on github
<pitti> tseliot: perhaps wait a bit with merging it into your official one until it's working?
<tseliot> pitti: yes, that's just for testing things locally
<pitti> tseliot: "GError: Query type 'modalias' is not supported" means that the PackageKit plugin crashed; I'll try to get a better error message out of that
<pitti> in fact, I already have some provision for that: setting APTDAEMON_LOG and APTDAEMON_DEBUG in tests/ubuntu_drivers.py
<tseliot> pitti: it builds here. Maybe add packagekit-backend-apt to the dependencies?
<pitti> oh, that's separate now?
<pitti> tseliot: hm, I'd need python-aptdaemon.pkcompat | (packagekit && packagekit-backend-apt)
<pitti> I guess that expands to pkcompat || packagekit, pkcompat || p-backend-apt
<pitti> (deMorgan, was it not?)
<pitti> ah, now I see what's wrong with the other tests
<tseliot> ok
<tseliot> pitti: shall I just test it with jockey-text?
<pitti> tseliot: shoudln't matter which jockey frontend you use
<tseliot> pitti: I don't think it can be tested in a chroot as it looks for the result of "uname -r" which doesn't match the kernel in the chroot: http://paste.ubuntu.com/1004953/
<tseliot> (which is 3.4)
<pitti> tseliot: oh, you mean jockey, not ubuntu-drivers?
<pitti> tseliot: yes, ubiquity calls it with -k <kernel>
<pitti> that overides uname -e
<tseliot> pitti: yes, which I need to test ubuntu-drivers, no?
<pitti> err, -r
<tseliot> ah
<tseliot> pitti: sudo jockey-text -l --no-dbus -k 3.4.0-3-generic doesn't seem to work
<tremolux> slangasek: just fyi, we uploaded a software-center 5.2.2.1 for precise SRU that targets just the two issues, per our discussion yesterday
<tremolux> slangasek: I did most of the verifies yesterday, I'll finish the last of them for 5.2.2.1 soon
<pitti> tseliot: ok, now fully builds for me as well; pushed a small fix again
<tseliot> pitti: good. How shall I test it now?
<pitti> tseliot: would you be ok with pulling this into git, and me uploading the current trunk?
<tseliot> pitti: sure, feel free to make a pull request and to upload
<zul> mterry:  repoze fixed now i think
<mterry> zul, awesome
<cjohnston> cjwatson: I believe its due to the cron not being turned back on after having it off for a bit for some troubleshooting.. an oversite most likely.. I have requested from IS that it be investigated..
<jamespage> doko: OK with you if I sync nmap from Debian?  delta no longer required (Debian have moved to dh_python2)
<cjwatson> cjohnston: thanks
<pitti> tseliot: argh, got disconnected
<tseliot> pitti: sure, feel free to make a pull request and to upload
<cjohnston> cjwatson: its re-enabled
<cjwatson> great
<pitti> tseliot: ah, thanks
<cjohnston> thanks for pointing it out
<pitti> tseliot: https://github.com/martinpitt/ubuntu-drivers-common/commits/master now has the release tag as well
<pitti> tseliot: pull request sent
<cjwatson> cjohnston: How frequently does it normally run, and how long does it generally take to update?  Just so I know how long to wait before reporting something in future ...
<cjohnston> cjwatson: its now at every three hours :-(
<tseliot> pitti: merged, thanks
<cjohnston> so it could be up to 6 hours from now in theory
<pitti> tseliot: uploaded
<pitti> tseliot: thanks for testing it!
<tseliot> \o/
<cjwatson> cjohnston: Fun
<cjohnston> cjwatson: it should be brought up for discussion during the release meeting
<cjohnston> it needs some love
<cjohnston> i most likely wont be there for it, but pitti seb128 and skaet are all aware of the issue
<pitti> tseliot: would it be possible for me to directly commit to the official branch?
<tseliot> pitti: let me check
<pitti> tseliot: I can e. g. commit to packagekit, hughsie gave me access
<pitti> tseliot: Admin -> Collaborators perhaps?
<tseliot> pitti: I've just done that. Can you see if you have access?
<pitti> tseliot: yep, page grew an "ssh" checkout now; thanks!
<tseliot> pitti: excellent :)
<pitti> good night everyone!
<mterry> zul, hiyo.  In python-jsonschema, you write that it's "An(other) implementation of JSON Schema".  Are there others?  Presumably none in main yet?
<zul> none in main yet
<mterry> zul, your patch for repoze.lru just comments out the tests, which doesn't seem like a real fix.  Do we know why they are failing?
<zul> mterry: no they work fine locally but not in the buildds
<mterry> zul, if they are provably bogus failures, that's one thing (and the patch should document why), but it's not clear these are completely bad tests (or at least, just need some grease to work in the buildd).
<zul> mterry: so document the patch and try to get a real fix later?
<mterry> zul, I meant the patch should document why the tests are provably bogus.  We don't have enough information to document it one way or the other
<mterry> zul, I'd like either a real fix or a real explanation for why they are failing in buildd and why it's OK to ignore them
<zul> mterry: i dont have enough information for you why they are failing but this is blocking python-routes which is blocking glance f1
<zul> and i dont have enough experience with repose.lru either
<mterry> zul, so once you get this in main, you update glance, and then how does that work with precise?  You're not moving python-repoze.lru in precise, right?
<zul> mterry: no we arent just quantal
<mterry> zul, so you're selectively backporting parts of glance to precise?  But you still need the version update in quantal before you backport?
<zul> mterry:  yes and yes
<zul> but repoze.lru is not a requirement for precise
<mterry> zul, can your team commit to fixing the test stuff before alpha 1?  (I'm OK with waving my hands at the tests for now, but they shouldn't stay broken)
<mterry> (and by fix, it may just mean explaining why buildd's can't reasonably run those tests)
<zul> mterry: yes i can commit to fix the test stuff before alpha1
<mterry> zul, cool.  I'll file a bug for that and assign it to the server team (or you?)
<zul> mterry:  preferably me :)
<mterry> zul, cool, approved that one then.  Just the dwarves one has problems then, I believe
<zul> mterry: yeah ill have a look after im done here
<henrix> pitti: any chance of having someone looking at kernel linux-ec2: 2.6.32-345.48 ?
<hallyn> slangasek: regarding /dev/shm (set up by initscripts), I notice that sid has /dev/shm as a bind mount of /run/shm;  precise has it as a symlink.  Is that difference intended?
<hallyn> (it affects whether sid's initscripts postinst can be deemed broken or not)
<henrix> pitti: we have the next kernel ready to upload, but we can't do it before this one is moved away from proposed
<slangasek> hallyn: a bind mount?  surely that's only in a chroot?
<hallyn> nope
<hallyn> amazon ami
<slangasek> hallyn: or prior to the first reboot?
<slangasek> er
<slangasek> then I think the ami was built wrong
<hallyn> feh
<slangasek> the bind mount is supposed to be a temporary "until next reboot" measure in the upgrade handling
<slangasek> after which it should be replaced by a symlink on shutdown
<hallyn> hm. lemme look through its init
<hallyn> yeah maybe i need to reboot the ami
<hallyn> except of course it doesn't want to reboot
<hallyn> slangasek: phew, right you are.  (for some reason after reboot /proc didn't get mounted, but I'll assume that's not my problem for now - instance badness)
<hallyn> so /dev/shm after reboot -> /run/shm.
 * slangasek nods
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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
 * dholbach hugs mterry
<seb128> jcastro, you got your chrome unity fix in proposed, thanks to Trevinho for the fix, popey for the packaging work and slangasek for the SRU processing ;-)
<cjwatson> Auto-sync from unstable in progress, as agreed at UDS
<bryceh> seb128, it scans for mentions of 'lucid' or '10.04' in description or comments (think it may look in attachments too.)  Certainly it isn't foolproof
<seb128> bryceh, ok, the bug description says "it was working on 10.04 but it's not on 12.04" so I guess that's it
<seb128> bryceh, you don't use the same logic to tag "precise" if 12.04 is mentioned?
<bryceh> seb128, yeah that type of description will get it doubletagged.
<seb128> bryceh, well it got only tagged "lucid" in this case
<seb128> bryceh, i.e no precise tagging
<bryceh> seb128, it should use the same logic for tagging precise; if it isn't then that's a bug.  point me at the bug report and I'll investigate when I get a chance
<seb128> bryceh, it's https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1001249
<ubottu> Launchpad bug 1001249 in xorg-server (Ubuntu) "EYE for Gnome 3.4.1 installed with Ubuntu 12.04 freeze the computer when displaying jpeg pictures from my nikon camera this is not the case with my 10.04 install having EYE 2.30 'tested with same pics'" [High,New]
<seb128> bryceh, thanks
<bryceh> seb128, ah, well to be honest these days I rely more on apport adding the tag when running apport-collect or ubuntu-bug
<bryceh> since most of the time if they've filed a report without doing that, their bug usually is not diagnosable anyway
<seb128> bryceh, I don't rely on the feature, I was just curious why a precise bug got tagged "lucid"
<bryceh> but I'll check my script
<seb128> bryceh, thanks, though it's very low priority, I was mostly curious there so don't bother much about it
<bryceh> seb128, hah, found it
<bryceh> the bot uses brad's kernel lookup table, which hasn't been updated since maverick
<bryceh> easy fix...
<alexbligh1> pitti, sorry to bother you again with what I was asking earlier. If I install a .deb with conffiles with owner root, then in my postinst chown www-data those files, then at some later date install an upgraded version of the package, will it treat those conffiles as changed (and thus not reinstall them) or will it leave them as it is?
<alexbligh1> s/leave them as it is/install the new versions/
<alexbligh1> I'm reading this: "Note that a package should not modify a dpkg-handled conffile in its maintainer scripts" <- does this only apply to the contents of conffiles, or also their permissions?
<slangasek> alexbligh1: generally applies only to the contents
<mterry> dupondje, btw, doing your bug now.  Thanks for the patch!
<mterry> dupondje, uploaded to quantal, working on SRU for 12.04
<alexbligh1> slangasek, so I am safe to chown conffiles in my postinst? I'm just wondering whether I should should be doing override_dh_install and a chown there at build time...
<slangasek> alexbligh1: files are stored in the .deb by numeric uid and you can't rely on that being the same on the build system and target system (sometimes you can't rely on the user existing at all on the build system)
<slangasek> well... www-data is actually an exception
<slangasek> because it's in /usr/share/base-passwd/passwd.master :)
<slangasek> so actually, yes, you can chown them in the package
<alexbligh1> slangasek, may be override dh_fixperms then, and do a chown www-data:www-data $(CURDIR)/debian/$(package)/etc/foo
<alexbligh1> ?
<slangasek> alexbligh1: yep, that works in principle
<slangasek> though, I do have to ask, why is www-data supposed to be able to write to these files?
<slangasek> we generally try hard to *not* let web apps write their own configs
<slangasek> since that tends to lead to security problems rather quickly
<alexbligh1> slangasek, they aren't really configs. They're .po files for different translations.
<slangasek> so a) why do they need to be owned by anyone other than root? b) why do they belong in /etc/
<slangasek> ?
<alexbligh1> slangasek, (a) so they can be uploaded through the webserver, (b) well, there are two ways of configuring these, the old way (which involves editing the files), and the new way which involves the pofile being uploaded, sanitised, running msgfmt on it, and putting it somewhere. I really don't want to suid the last process, hence owned by www-data. They are in /etc because we want conffile behaviour on upgrade.
<alexbligh1> (so yes they could be elsewhere but I still have the conffile interaction)
<slangasek> alexbligh1: well, if you're going to this much trouble to enable them to be updated via the webserver, I think conffiles are the wrong mechanism; it would probably be better to ship these as templates under /usr, and copy them to /var at package install time, letting the webserver update them there
<slangasek> tremolux: software-center accepted into -proposed now; and apologies, I had noticed the oddness of the fix for bug #999486 being commented out when reviewing the debdiff for the last one but didn't follow up
<ubottu> Launchpad bug 999486 in software-center (Ubuntu Quantal) "AttributeError: 'NoneType' object has no attribute '__contains__' when clicking the All Software button" [Low,Fix released] https://launchpad.net/bugs/999486
<slangasek> tremolux: oh, hold up - not accepted just yet
<tremolux> slangasek: oh, no worries, yeah, we overlooked that  :/
<slangasek> tremolux: hmm - it seems someone has already published 5.2.2 to -updates, that was unexpected
<slangasek> 5.2.2.1 accepted into -proposed now
<tremolux> slangasek: ?? really?
<slangasek> yes
<slangasek> I don't know who or why
<tremolux> slangasek: hmm, not all of the verifies were complete
<slangasek> yeah
<slangasek> well, it's done now
<tremolux> slangasek: but it should not be a problem, we have all of those fixes in trunk and test everyday
 * slangasek nods
<tremolux> slangasek: so to get 5.2.2.1, we just need do the remaining verifies? (most of the unverified bugs from 5.2.2 were related to the regression and the disabled fix actually)
<slangasek> tremolux: yes
<tremolux> slangasek: ok, I'll look for it on here and take care of them: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<tremolux> slangasek: thanks a lot for your help!
<slangasek> tremolux: no problem :)
<seb128> bryceh, oh, good, thanks!
<seb128> slangasek, s-c, @who; pitti (from -changes), why: I guess it's "90% of the bugs verification-done and no verification-failed or regression signaled on a long list of bugs"
<seb128> slangasek, it's sometime tricky to wait that all bugs are confirmed on such updates and if most bugs are verification-done and nobody pointed regression it's better to get moving that to stale
<slangasek> well
<seb128> slangasek, just saying, and I might be wrong so keep the discussion for pitti if you disagree ;-)
<slangasek> honestly, I would rather we be prepared to kick proposed SRUs back out if we can't get full coverage
<slangasek> but yeah... the problem here is that tremolux had been talking with me about it, but we didn't actually mark any of the bugs verification-failed to block its promotion
<seb128> right
<seb128> that's one of the issues pitti raised on the list about SRU team and bug emails flood
<seb128> somebody has to watch for any regression mentioned in any of the bugs and set a failed flag somewhere
<slangasek> I don't think it was mentioned on the bug
<slangasek> on any bug
<seb128> slangasek, another issue with such uploads is that apport bugs often have no steps, they are like "they happen randomly to some users", so it's hard to get verification-done
<slangasek> we should've flagged it with the tag
<seb128> i.e fixed come from guessing from the stacktrace
<seb128> but it's hard to find anyone to verify the fix
<seb128> we can't block the updates for ever because "obvious code fixes" didn't get verified by anyone
<slangasek> yes, well, errors.ubuntu.com will help with that eventually :)
<seb128> it helps if we see that the issue stop being reported
<seb128> but it means we need a progress tracking for specific issues which I think we don't have yet?
<slangasek> yep - hence, "eventually"
<tremolux> slangasek, seb128: for bugs that are impossible to consistently reproduce (there were a couple out of about 20 fixes in this SRU), we simply try to provide the steps that can cause it and ask the verifier to do those steps repeatedly..that sort of thing
<tremolux> slangasek, seb128: but we are definitely counting on errors.ubuntu.com, because that's where we prioritized them from
<seb128> tremolux, right, it's not specific to you, most of the segfaults are like that
<seb128> i.e we have g-s-d segfaults which apparently randomly happen at logout in a racy way
<seb128> it's hard to test them out of checking that the update creates no regression and watch the reporting status
<tremolux> seb128: yep, I see, just clarifying for our case
<seb128> stats
<tremolux> yes
<tremolux> same situation
<seb128> slangasek, btw speaking for SRU, shotwell has a SRU with 3 bugs listed, 2 got verification-done, the third one seems to not be enough of a fix but improve things (i.e incomplete fix)
<seb128> slangasek, what's the recommend way to mark the remaining bug in a way which doesn't hold the copy to -updates? (no reason since it fixes 2.5 issues and create no regression)
<slangasek> seb128: mark it 'verification-done' now, then reset the state after publishing
<seb128> slangasek, ok, thanks
<hallyn> what assumptions do we make about mounted MOUNTPOINT=/sys versus the rest of the base root filesystem (i.e. /usr/bin)?
<hallyn> Can I assume that if /sys is mounted, the programs installed by a package are going to be available?
<slangasek> hallyn: no
<hallyn> drat
<slangasek> hallyn: that's probably going to change this cycle, but you can't rely on it /yet/
<slangasek> hallyn: any reason not to just wait for the 'filesystem' event?
<hallyn> bug 995956 wants libcgroup to start earlier
<ubottu> Launchpad bug 995956 in libcgroup (Ubuntu) "cgconfig upstart job should start earlier and mount all available cgroup types by default" [High,Confirmed] https://launchpad.net/bugs/995956
<hallyn> oh that should be fine
<slangasek> hmm, well, 'filesystem' won't usually be much earlier than 'runlevel'
<stgraber> hallyn: is there any reason not to get that out of the archive and use cgroup-lite everywhere? last I checked cgconfig was so bad it'd prevent my laptop from resuming (still haven't figured out exactly how it managed that ;))
<slangasek> ('runlevel' is basically 'filesystem' + 'network')
<slangasek> hallyn: 'start on filesystem' definitely won't do what the bug submitter is asking for... lots of other stuff starts in parallel as soon as the 'filesystem' event fires
<hallyn> stgraber: that would be MY preference
<hallyn> i don't know why people insist on installing libcgroup :)
<dupondje> mterry: thanks alot! more bugkills to come! :)
<mterry> :)
<jbernard> hallyn: that would be my preference too. Also for debian, that might be the best solution
<hallyn> jbernard: i think i've asked this before, but (since you maintain it) what exactly do you need from libcgroup?
<dupondje> mterry: won't we need a rebuild of Remmina because of the multiarch lib dirs ?
<jbernard> hallyn: if you take out the initscripts, I think the package has some nice features.
<hallyn> jbernard: the utilities to manage cgroup settings you mean?
<jbernard> hallyn: yes
<hallyn> my main beef actually is not the initscripts but the daemon, which cannot deliver on its promises :)
<jbernard> i agree completely
<mterry> dupondje, probably, yes.  Not for 12.04, but for 12.10
<hallyn> the submitter of the above bug was also askign for some tools to change settings
<jbernard> the utilities are useful, but the daemon is a nightmare
<mterry> dupondje, it should find them in both locations I think
<hallyn> jbernard: so perhaps on top of the cgroup-lite package we should add a cgroup-mgmt package with whatever tools you like/need to use?
<dupondje> ah but you didn't do the multiarch stuff for 12.04 ?
<jbernard> hallyn: that would work well for me, but i don't know how many people rely on the daemon
<jbernard> hallyn: it seems like a great idea to me, remove cgroup-bin, replace with cgroup-lite + additional utils
<hallyn> jbernard: would that scratch a big enough itch for you to want to make a debdiff adding a cgroup-lite-mgmt package?  :)
<jbernard> jbernard: i think so, it's also an appealing way to re-sync the ubuntu package with the debian one
<jbernard> hallyn: in which bug is the user requesting additional managment utilities?
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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:
<hallyn> jbernard: bug 995956
<ubottu> Launchpad bug 995956 in libcgroup (Ubuntu) "cgconfig upstart job should start earlier and mount all available cgroup types by default" [High,Confirmed] https://launchpad.net/bugs/995956
<dupondje> bdmurray: about the remmina clipboard bug. Some people commented on the bugreport when they had crashes + on the upstream tracker. I also got some emails. All those crashes got fixed. And didn't had any reports anymore. Alot of people confirm its working fine.
<dupondje> I'm also using it myself, and having no issues :)
<dylan-m> Hey, mterry, do you know any examples of packages with that reboot-required metadata in their control files?
<dylan-m> I can't find anything about it, but that's probably because I don't know where to look ;)
<broder> dylan-m: network-manager
<broder> i don't think there's any metadata mechanism currently, unless one got added
<broder> you run a script which sets a flagfile
<slangasek> bdmurray: is the security bug that let apt passwords into attachments fixed now?  (for all releases?)
<slangasek> bdmurray: I ask because I see the bot still removing attachments
<dmitrii> negronjl: thanks for helping iamfuzz with the partition devices problem
<dmitrii> negronjl: I am the one seeing this on Precise: http://paste.ubuntu.com/1005486/
<JordiGH> Is there a way to contact someone on Launchpad if they didn't provide an email?
<JordiGH> I want to contact this guy: https://launchpad.net/~picaso
<slangasek> you can click the "contact this user" button
<JordiGH> He backported Octave to the PP release.
<JordiGH> slangasek: I don't see anything there for contacting them.
<slangasek> are you logged into launchpad?
<JordiGH> Yes, it says no public email
<JordiGH> C'mon, Steve, help me out. :-)
<slangasek> well, there is a "contact this user" button; I don't know why you don't have it if you're logged in
<JordiGH> Ah, it's top right.
<JordiGH> Had to grep for it.
<bdmurray> slangasek: just because its fixed doesn't everyone installed it
<slangasek> bdmurray: certainly... does that mean, though, that we're not going to have any apt clone tarballs at all in bug reports for the foreseeable future?
<slangasek> in theory those are important for reproducing upgrade bugs
<bdmurray> right, I heard cjwatson say that too
<slangasek> anyone know where the packages for "ubuntu satanic edition" are?  I think one of them has called dpkg --sacrifice-goat >> plymouth
<bdmurray> slangasek: in the bug mvo indicated he would work on a proper fix that scans data first
<slangasek> bdmurray: ok
<bdmurray> slangasek: I think at ubuntusatanic.com
<azeem> bdmurray: noooo, http://ubuntusatanic.org/
<slangasek> http://ubuntusatanic.org/hell/
<slangasek> what an obvious name for a repository
<azeem> and it has a ad banner for MS Dynamics
<bdmurray> slangasek: I might look at fixing the aptclone stuff too
<slangasek> bdmurray: that would be keen
<adam_g> how do i go about opening and pushing to a -proposed branch for a precise package that is getting its first update?
<stgraber> adam_g: you can't get the -proposed branch until at least one SRU was uploaded. So the first one you need to dput without commiting to bzr first
<adam_g> stgraber: ahhh gotcha, thanks
 * slangasek blinks at the follow-up to bug #1004121
<ubottu> Launchpad bug 989331 in plymouth (Ubuntu) "duplicate for #1004121 plymouth-theme-ubuntu-logo install failure because alternative is a symlink to self" [High,Incomplete] https://launchpad.net/bugs/989331
<slangasek> I certainly did not expect that
<tumbleweed> the new merges.u.c is too fast. it gets ahead of the LP importer which breaks my oldmerges page :)
<slangasek> heh
 * tumbleweed guards against that. such merges are *not* old
#ubuntu-devel 2012-05-25
<infinity> xnox: If this boost merge is yours, why does it ScottK's name in the changelog? :P
<infinity> xnox: Err, nevermind, I was looking at the changelog after patching with --dry-run.  I'm not awake.
<infinity> La la la
 * micahg pokes infinity with the -v stick
<cjohnston> cjwatson: fwiw, on the 31st we will delete the quantal db and the graphs will be started over, so you probably don't need to worry about the trend line for now
<cjwatson> cjohnston: ack, it was just a temporary tweak really
<cjohnston> thats fine.. just letting you know
<vibhav> Good Morning
<scientes> who has the link to the unity hello world app
<scientes> i remember it being in python
<micahg> scientes: https://launchpad.net/hello-unity
<pitti> Good morning
<roshan> Hello, I was compiling a kernel in Ubuntu 12.04 as specified in one of the Ubuntu help pages.
<roshan> A particular section says to enale "A particular section on the tutorial askes me to enable "Kernel module loader" , but I couldn't find any
<roshan> Where could I find that ?
<larsduesing> good morning, is here anybody who is sort of firm with apport-hooks?
<pitti> larsduesing: I should be :)
<vibhav> heh, pitti is being humble
<larsduesing> Ah :)
<larsduesing> hi pitti :)
<larsduesing> arghs, we had pastebin here?
<larsduesing> pitti: would you please have a look at that: http://pastebin.com/Y8D9u5yY
<vibhav> larsduesing: Which package is this hook for?
<larsduesing> the last two lines - how can I find out, if the specified reports are actually made, so that I only start masking for available reports?
<larsduesing> aiccu
<pitti> larsduesing: (looking in a bit, still reviewing an SRU)
<larsduesing> oh, sorry, take your time :)
<pitti> larsduesing: what do you mean with "if the reports are actually made"?
<larsduesing> the first report is only made, if a dpkg install fails
<vibhav> Is it fine to SRU "Wishlist" bugs?
<dholbach> good morning
<larsduesing> good morning dholbach
<pitti> larsduesing: I'm afraid I still don't understand the problem
<pitti> larsduesing: you can /msg me in German if that helps
<dholbach> hi larsduesing
<pitti> hey dholbach, wie gehts?
<vibhav> hi
<vibhav> dholbach: Is it fine to SRU "Wishlist" bugs?
<dholbach> pitti, hey hey - alles gut und bei Dir?
<dholbach> vibhav, no
<dholbach> vibhav, either they are important or they're not SRUs :)
<vibhav> oh ok
<dholbach> https://wiki.ubuntu.com/StableReleaseUpdates has some decision making help
<pitti> dholbach: prima, danke!
<larsduesing> https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix <- so I should use "Propose for merging" now, shouldn't I?
<alkisg> Any good tools for writing man pages? Is docbook + po4a a good choice, in order to have them translatable in launchpad etc?
<vibhav> Could anybody nominate https://bugs.launchpad.net/ubuntu/+source/glom/+bug/736913 for maverick?
<ubottu> Launchpad bug 736913 in glom (Ubuntu) "libglom dev package missing dependency on libxml++ dev package" [Undecided,Fix released]
<vibhav> oh wait, maverick's EOL
<vibhav> Could somebody nominate it for natty?
<Daviey> vibhav: Can you explain the impact?  It feels like a 'won't fix' for Natty IMO.
<pitti> yes, I agree; this is absolutely unimportant for natty now
<vibhav> Daviey: Ill agree with you then
<dupondje> Some question about virt-manager. Are all the current deps needed? Cause I don't know why I should need bridge-utils and ebtables for example if I just want to admin a remote server.
<seb128> bdmurray, hey, those "Missing SRU information" bot comments, what do you check for?
<henrix> pitti: hi, any chances of having a look at kernel linux-ec2 2.6.32-345.48?
<henrix> pitti: we need to upload a new version into proposed, but this one is on our way
<pitti> henrix: I'll try; please note that I formally left the SRU team
<henrix> pitti: oh, sorry. didn't knew that. any idea about who shall i bother next time? :)
<pitti> henrix: RAOF and SpamapS do regular SRUs
<henrix> pitti: ack, thanks.
<onosendi> I'm using mate with marco as my WM. How would I go about getting the geometry of a window when it is closed? It's x, y, w, h, etc?
<pitti> henrix: promoted
<henrix> pitti: great, thanks
<larsduesing> btw, dumb question: does anybody use any other urgency as "low" in changelogs (maybe except security ones?)
<larsduesing> and if yes: when it is advisable to do so?
<pitti> larsduesing: the urgency is entirely ignored in ubuntu; it should be kept as "low" in general
<Daviey> cjwatson: I assume you saw mjg59's EFI related blog post?
<larsduesing> ok, thanks pitti
<larsduesing> btw, pitti: branch is done: https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix/+merge/107351 (maybe it should be even a "security" fix, because of possible information disclosure...)
<seb128> diwic, hey
<diwic> seb128, pong
<seb128> diwic, hey, how are you?
<diwic> seb128, I'm okay, how are you?
<seb128> diwic, asac reported bug #1004384 and I can confirm it with a bt device, could you advice on whetever pulseaudio debug infos would be useful for it?
<ubottu> Launchpad bug 1004384 in gnome-control-center (Ubuntu Precise) "[soundnua]: segfaults when selecting bluetooth input device" [High,New] https://launchpad.net/bugs/1004384
<seb128> diwic, I'm good thanks
<diwic> seb128, hey, I fixed that an hour ago, as I found it myself :-)
<seb128> asac, ^
<diwic> I think so at least, judging from the title only
<seb128> diwic, great!
<asac> diwic: have the patch?
<asac> i can tryu ... hav ethe built tree here
<asac> debdiff preferrred
<diwic> seb128, I spent much of yesterday rewriting the profile get/set stuff, tested it some more this morning, that's when I found the bug
<cjwatson> Daviey: have now ... if only I had time to do something useful about it
<cjwatson> pitti: the urgency isn't *entirely* ignored, it has a tiny effect on build scoring - but yeah, not much :)
<Daviey> cjwatson: yeah :(
<seb128> diwic, do you have a patch,diff somewhere we could try?
<diwic> seb128, asac, now pushed to http://bazaar.launchpad.net/~diwic/+junk/soundnua-lp984637/revision/33
<seb128> diwic, thanks
<diwic> seb128, note that r32 of that branch is my profile rewrite, which might need more testing before releasing, so just take the r33 patch
<cjwatson> Need more installer team people who care about Macs
<cjwatson> And have any time at all
<diwic> seb128, at least that makes input look like output codewise, and it fixes the crash, so assuming it's the right thing to do, might wanna double-check with cjcurran when he comes back
<xnox> cjwatson: i have an old intel 32bit macbook, but it can't run Lion and up.
<seb128> diwic, could you add the diff to the bug report? that will be needed to SRU it, I will look to that
<seb128> diwic, thanks!
<seb128> asac, let me know if you try the patch
<pitti> cjwatson: oh, I didn't know that; thanks!
<diwic> seb128, what type of diff would you like
<seb128> diwic, standard unified diff over the current precise version (i.e over ronoc's vcs)
<seb128> diwic, i.e something we can apply with patch to our current package
<diwic> seb128, asac debdiff for precise-proposed added to bug
<Daviey> lool: https://launchpad.net/ubuntu/+source/btrfs-tools/0.19+20100601-3ubuntu2 still seems to be a delta with Debian... is this really warranted ?
<cjwatson> Daviey: xnox is working on that
<cjwatson> (the merge I mean)
<xnox> Daviey: I did a merge it's sitting in the sponsor's queue. The delta is still warranted
<xnox> see the merge bug discussions.
<xnox> between me and other contributors.
<Daviey> ah, neat
<xnox> Daviey: there is also mdadm and e2fsprogs bugfix/merge in the queue if you are up for it =))))
<Daviey> xnox: i see you asked slangasek for a review... i wouldn't want to step on his toes or anything :P
<xnox> Daviey: I'm sure slangasek wouldn't mind if somebody else does review/upload
<asac> seb128: diwic: ack. crash is gone
<seb128> asac, things work as well?
<seb128> asac, i.e can you configure your bluetooth?
<asac> seb128: yes, i can select it and it seems it uses the bluetooth input afterwards ... let me try a few more things
<xnox> Daviey: btrfs-tools is on this list http://qa.ubuntuwire.org/oldmerges/
<asac> seb128: all good ... all input and output channels work ... and i can use bluetooth and switch between high fidelity and telephony profile
<asac> seb128: i tried the patch though by manually moving the return;
<asac> i have no input of the complete branch
<seb128> asac, diwic: thanks, I will test build it there and get it SRUed
<asac> rock
<asac> :)
<asac> i have a good one with debug symbols now :)
<pitti> tseliot: hey Alberto, how are you?
<tseliot> pitti: hey Martin, fine thanks, you?
<pitti> tseliot: you said you had a hybrid nvidia system, right? i. e. right now "ubuntu-drivers list" should show the nvidia drivers, but we are supposed to hide them, right?
<pitti> tseliot: I'm great, thanks! Looking forward to the long weekend (Monday is national holiday)
<tseliot> pitti: yes, I have a hybrid system here. Well, we shouldn't always hide them
<pitti> that's at least what the current jockey handler does
<pitti> if "intel" is loaded by X.org, it doesn't offer the nivida driver
<tseliot> pitti: lucky you (no nationaly holday here)
<pitti> I'm going to add that special-case to u-d-common
<tseliot> pitti: right, let keep doing that for now. There's a special case we need to cover but it can wait
<Daviey> xnox: comment added
<xnox> Daviey: thanks
<Daviey> xnox: if you are happy with my comment, i'll just upload it here.. no need to bother fixing in bzr
<pitti> tseliot: are you currently using the intel or nvidia driver in X.org?
<pitti> tseliot: I pushed this to git now with a test case, but if you could pull, build, and double-check "ubuntu-drivers debug", that'd be nice
<xnox> Daviey: yes please upload. I don't like leading slashes either... and it was not me who introduced the link =))) I will comment on the bug report to the other contributor.
<tseliot> pitti: the nvidia driver but only because I can select the graphics card from the BIOS. Not all laptops have this feature
<pitti> tseliot: runnign "PYTHONPATH ./ubuntu-drivers debug" will do fine
<tseliot> pitti: sure
<pitti> tseliot: ah, cool
<xnox> Daviey: yes, please upload! it will unblock a couple of workitems for the btrfs spec ;-)
<pitti> tseliot: so in your current setup it should still show the nvidia driver
<tseliot> pitti: would this work in precise?
<pitti> tseliot: it should
<pitti> tseliot: the tests currently fail, I'll fix that
<tseliot> pitti: ok, as the laptop has precise on it
<Daviey> xnox: uploaded
 * xnox 0/
<xnox> Daviey: last time I have checked CEPHs mailing list w.r.t. btrfs I saw loads of people with bug reports & errors/warnings from btrfs as well as degraded performance after some time
<pitti> tseliot: erk, git skills failure; really pushed now, with test case fix
<tseliot> pitti: unmet build deps: python-aptdaemon.test (>= 0.43+bzr810-0ubuntu2~) gir1.2-packagekitglib-1.0
<tseliot> pitti: I should probably upgrade to quantal
<pitti> tseliot: that's fine
<xnox> Daviey: do you have interest in btrfs for particular workloads/services?
<pitti> tseliot: just run it out of the source tree
<pitti> tseliot: PYTHONPATH ./ubuntu-drivers debug
<tseliot> pitti: ah, ok
<Daviey> xnox: tentative :)
<lool> Daviey: the delta that you point at was required to have btrfs work ok with upstart + mountall
<lool> Daviey: Back then I was playing with ARM btrfs images, and was getting at least one of the two bugs fixed in this upload; the other one had enough comments supporting the proposed fix that warranted the patch to be included IIRC
<lool> Daviey: maybe upstream/the Debian package have been changed similarly in the mean time though
<xnox> Daviey: there were not many folks from server/cloud at the https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-btrfs-requirements
<pitti> tseliot: so it should list nvidia if you are on nvidia, and hide it if you are on intel
<xnox> Daviey: any comments about btrfs in Ubuntu are welcome
<pitti> tseliot: the test cases reproduce this fairly well, so I'm rather sure it's going to work, but oh well, theory and practice ... :-)
<tseliot> pitti: it seems to work. Let me get you the output
<tseliot> pitti: here you go: http://paste.ubuntu.com/1006259/
<tseliot> very nice, BTW
<Daviey> xnox: wilco
 * xnox ?
 * xnox Wilco is an American alternative rock band based in Chicago, Illinois. 
<Daviey> will comply. :)
<xnox> ah =) ok.
<pitti> tseliot: ok, that's with nivida?
<tseliot> pitti: yep
<pitti> tseliot: good, thanks
<pitti> I'll upload that and then wave good bye
<tseliot> pitti: we have two more cases: 1) intel on and nvidia off; 2) both intel and nvidia on
<pitti> tseliot: I thought 2) wasn't possible with current X
<tseliot> pitti: well, both cards can be on but only one card can drive the display
<tseliot> pitti: i.e. only one driver can be used
 * tseliot -> lunch
<pitti> splendid
<tseliot> ;)
<pitti> tseliot: so, see you next Tuesday, and enjoy the weekend!
<tseliot> pitti: thanks, you too!
<pitti> tseliot: I'll add apport hook (with u-drivers debug) etc. next week
<tseliot> great :)
<asac> diwic: noticed something odd ... i have two microphone input devices (webcam + built in) ... i need to set both explicitely to mute to really mute the input level in the sound preference area
<diwic> asac, uhm, can you tell me what you did in more detail?
<diwic> asac, how were you recording e g?
<asac> diwic: i am not recording ... i am just looking at the control center. what i see is this:
<asac> i make noise and the input indicator goes up (shows signal)
<asac> i check the "mute" box
<asac> still signal on noise
<asac> i go to the other input device and check the mute box and signal is gone
<asac> diwic: makes sense?
<diwic> asac, right, sounds like the input level is taking its input from the wrong card essentially
<asac> diwic: more background: i have a thinkpad in a dock; a built-in mic, a usb webcam mic and a bluetooth mic
<asac> diwic: this problem seems to only affect the built in and usb mic
<asac> diwic: well, but it feels it takes it from both, because it doesnt matter which card i mute
<diwic> asac, can you verify which mic it seems to take its input from
<diwic> asac, by poking on the actual mic
<asac> diwic: no... as i said: doesnt matter in which order
<asac> ok
<asac> i can try
<asac> one sec
<asac> diwic: yeah. always from the usb mic
<asac> diwic: but if i have both mute checkboxes selected it gets disabled :)
<asac> thats the fun part
<asac> maybe something caused by dock rerouting magic?
<diwic> asac, so if you have the usb mic selected it takes the signal from the usb mic, but muting *only* the usb mic would not mute the signal?
<asac> diwic: restarting fixed it i think :/
<diwic> asac, ok, let cjcurran know if it's reproducable
<asac> yeah. how weird :)
<mr_pouit> cjwatson: quantal/i386 daily builds for Xubuntu fail because cdrom/non-pae/initrd.gz doesn't exist (the non-pae kernel was dropped I think). Could you do some magic again please? (do you prefer that I file a bug report?) Thanks. ;-)
<cjwatson> mr_pouit: Oh yes, I can just fix that now
<cjwatson> Thought I'd caught everything, evidently not
<cjwatson> mr_pouit: done
<mr_pouit> cjwatson: awesome, thanks!
<bdmurray> seb128: the bug matches my expectations now although I expanded the test case section a bit
<seb128> bdmurray, thanks
<seb128> SpamapS, hey, is there any chance you could do some SRU reviews today? ;-)
<psusi> cjwatson: there are a few bug reports that I think are caused by a size increase in the grub2 core image that makes it too large to fit in 62 sectors when including raid and lvm modules.  Is this just a too bad, you need more room, in which case it bears mentioning in the release notes?
<zul> mterry: ping dwarves builds fine now
<mterry> zul, was just about to look at it
<cjwatson> psusi: Sometimes it's fixable, it depends ... I generally think it's a bug although not necessarily a straightforward one
<cjwatson> Although I'd advise people to put their first partition at 1MiB rather than at sector 63 these days; much more efficient on modern disks, and no less efficient on disks since about oh 1985 or something
<cjwatson> Of course I realise it's tedious to move partitions
<psusi> cjwatson: indeed... but it seems some people are upgrading old setups from 10.04 and still have partitions starting at sector 63
<psusi> cjwatson: it seems that the image with both raid and lvm built in is now something like 200 bytes too large to fit in that space
<cjwatson> This is probably fixable but I'm afraid I don't have time for the next month or two
<apw> jodh, is there a simple way to tell from upstart --verbose output which thing we are waiting on
<apw> jodh, for a han
<apw> jodh, for a hanging boot
<jodh> apw: try http://upstart.ubuntu.com/cookbook/#establish-blocking-job
<jodh> apw: can you send me a log when booting with --debug ?
<apw> jodh, the end user is talking to us on #ubuntu-kernel now
<apw> jodh, http://sprunge.us/iGaU
<apw> jodh, for me i think its wiating on mountall ... perhaps mismatched UUID
<tjaalton> is it ok to add build-depends on a SRU release, to fix obvious omissions in the packaging? :)
<seb128> tjaalton, yes
<seb128> tjaalton, well adding build-depends is ok, turning on feature which were not is subject at review and rational
<tjaalton> seb128: yeah, of course. minor features but something that should've been enabled.. and have been on other distros
<seb128> tjaalton, well, the fact that they should doesn't change that they didn't get tested so it's not a trivial wave in change
<tjaalton> seb128: it'll get tested before the push
<seb128> tjaalton, right, well anyway I was just saying, adding build-depends is not something against the rules ... are those build-depends in the same pocket btw?
<tjaalton> seb128: the package is in universe, so no problem there
<tjaalton> package which is being sru'd
<seb128> ok
<stgraber> mvo: hey there, I was talking with jibel about getting automated upgrade testing up and running for Quantal. What's still required to get do-release-upgrade happy?
<mvo> stgraber: the release-upgrader is currently defnct due to the py3 porting in trunk once that is resolved there is nothing blocking it
<stgraber> mvo: ok. Who's doing the py3 port?
<cjwatson> That would be me
<SpamapS> seb128: I did some w/ bdmurray who is training to be an SRU team member yesterday. Between he and I, and slangasek, we didn't get your SRU's reviewed?
<cjwatson> I'll try to get that sorted out - mvo, is there an easy way I can reproduce the problems?
<mvo> stgraber: I meant to look at it this week, but couldn't quite find the time
<mvo> cjwatson: yeah, cd DistUpgrade; sudo ./dist-uprade.py will fail
<cjwatson> OK, thanks
<bdmurray> SpamapS: we did review one of his and he's updated it now and it looks good to me
<SpamapS> bdmurray: bug #?
<apw> cjwatson, i just installed a kernel and extras together and got an unexpected result: http://paste.ubuntu.com/1006472/ see the last line there
<cjwatson> apw: Looks like a bug in your postinst
<bdmurray> SpamapS: bug 980317 for gnome-control-center
<cjwatson> apw: Though actually, maybe not, try 'sudo dpkg --configure -a'
<ubottu> Launchpad bug 980317 in gnome-control-center (Ubuntu Precise) "details -> overview disk size includes network mounts" [Low,Fix committed] https://launchpad.net/bugs/980317
<cjwatson> Might just be a pending trigger
<apw> nothing happened
<cjwatson> case "$DPKG_MAINTSCRIPT_PACKAGE" in
<cjwatson> linux-image-*)
<cjwatson> hm, so maybe update-initramfs needs to exclude linux-image-extra-* from that since that behaves differently
<cjwatson> I don't suppose I can convince you to not call it something matching linux-image-*? :-P
<apw> cjwatson, yeah i was seeing the same lines ...
<apw> cjwatson, well i guess we can call it anything you like :)
<cjwatson> If it didn't match that wildcard you wouldn't have a probem
<cjwatson> *problem
<SpamapS> bdmurray: so, +1 to accept that upload?
<apw> cjwatson, so either we change the name or fix the trigger ... ok thanks
<apw> cjwatson, its possible we should be calling the hooks later anyhow as we carry half of the kernel
<bdmurray> SpamapS: yes
<SpamapS> bdmurray: I concur. Pulling lever... you want to run sru-accept?
<bdmurray> SpamapS: yes will do
<cjwatson> apw: Maybe, though I'd have thought the ordinary trigger would be sufficient
<apw> cjwatson, well let me think, iirc the generic trigger is unperameterised and triggers a rebuild of the running kerenl initramfs, and this is specificall not for the running one in the majority of cases
<SpamapS> bdmurray: did you notice bug 1004384 was also still missing SRU headers?
<ubottu> Launchpad bug 1004384 in gnome-control-center (Ubuntu Precise) "[soundnua]: segfaults when selecting bluetooth input device" [High,In progress] https://launchpad.net/bugs/1004384
<cjwatson> Oh, true, you want a specific version here
<cjwatson> So maybe you might as well just use your initramfs hook and then it would all be well
<cjwatson> Since indeed the trigger won't do the right thing
<SpamapS> bdmurray: I accepted anyway, but that one probably needs impact/regpotential/etc. as well
<SpamapS> seb128: ^^
<apw> cjwatson, ok will work on that, i presume i just need to run the kernel postint.d hooks as normal
<SpamapS> I think its probably time we sent an email out to ubuntu-devel about SRU headers
<SpamapS> too many people are uploading without following that bit of the process.
 * SpamapS goes to make pbreakfast
<SpamapS> pbreakfast - a clean chrooted breakfast
<cjwatson> apw: I think so
<apw> cjwatson, i suppose this will mean we will rebuild the initramfs twice for every kernel which isn't ideal
<apw> cjwatson, i suspect to avoid that properly we will want to have the initramfs trigger perameterisable
<cjwatson> Yeah, I'm having a slightly difficult time thinking about how to avoid that
<cjwatson> Well, it's technically possible; we could queue up the initramfs versions to rebuild in a file in /var and have the trigger process that
<cjwatson> That kind of thing is the usual way to pass data through the trigger interface
<apw> cjwatson, would it be reasonable to generate a list somewhere and ... yeah that
<apw> cjwatson, ok so for now i will bodge it to make it do both and take an action to make it perameterisable; where is appropraite in /var, is there a defined spot ?
<cjwatson> I wonder if there are things that currently assume that some kind of initramfs exists immediately after the kernel is configured
<cjwatson> Hopefully not ...
<cjwatson> /var/lib/initramfs-tools/ I guess
<apw> ok ... thanks ... sigh why is nothing every easy
<cjwatson> It should be per-package in any event
<apw> cjwatson, i suspect if we delay initramfs build to the end, then grub configure will have to be as well, so there is in initramfs for it to link to
<apw> there is bound to be untold fallout ...
<apw> but anyhow i can do the framekworks and we can iterate on the issue
<cjwatson> apw: Mm, that's a bit scary
<cjwatson> apw: The trigger could put an empty initramfs in place, maybe
<cjwatson> Just so there's *something*
<apw> cjwatson, yep ... thats what i am thinking ... yeah that might work, ick
<seb128> SpamapS, bdmurray: hey, some GNOME ones are sitting in the queue for some days, no hurry but they are mostly trivial ones and fix reported bugs ... if they are stalled because the "paperwork" is insuffisant to your taste please state it on the bugs rather than just keeping them sitting in the queue ;-)
<seb128> cjwatson, slangasek: is there a way to turn off multiarch for dh compat 9 level packages?
<slangasek> seb128: pass -- --libdir
<slangasek> to dh_auto_configure
<seb128> tkamppeter, ^ or that
<slangasek> why are you turning it off, though? :)
<seb128> slangasek, I suggested to downgrade compat to 8 but I figured there would be a better way :p
<seb128> slangasek, because it's a cups driver and cups is not multiarched
<slangasek> ah
<slangasek> good reason :)
<seb128> slangasek, i.e it doesn't look in the multiarch dir
<slangasek> yeah, this is probably a case where it doesn't make sense to ever multiarch
<slangasek> also, it's probably --libexecdir wanted here, not --libdir, right?
<slangasek> (helper executables - not DSOs)
<seb128> right
<seb128> slangasek, thanks
<slangasek> I've actually wondered if pointing --libexecdir at the multiarch dir by default was a mistake... too late now to change it for compat 9 though :/
<seb128> bdmurray, why is your bot randomly going through bugs and deleting some of the apt log files?
<bdmurray> seb128: its not random and its because of an update-manager cve
<seb128> bdmurray, ok, thanks, I was rather curious of the reason ;-)
<bdmurray> seb128: sure, no problem
<tkamppeter> slangasek, seb128, I have already tried "dh_auto_configure -- --libexecdir=/usr/lib", "dh_auto_configure -- --libdir=/usr/lib", "dh_auto_configure --libdir", "dh_auto_configure --libexecdir", all to no avail.
<slangasek> tkamppeter: can you link me the package?
<cjwatson> The third and fourth of those are unambiguously wrong
<cjwatson> (I don't have an answer for you, but you might as well not waste your time on options that definitely won't work)
<cr3> Is there a recommended PPA that might contain more python3 packages for Precise, like python3-openssl if such a thing exists?
<SpamapS> seb128: we actually have been stating in the bugs when the paperwork is insufficient. ;) There have been well over 100 packages uploaded to precise-proposed in the last 2 days.. so please just be patient.
<seb128> SpamapS, 85 of those being kde-l10n ones? ;-)
<SpamapS> seb128: probably :)
<seb128> SpamapS, but yeah, sure no hurry, though I blame a bit KDE for swamping the queue like that :p
<SpamapS> seb128: agreed, KDE always seems to make a lot of work. Anyway, make sure you have all your impact/testcase/regression potential filled out, and we'll get through your bugs faster. :)
<seb128> SpamapS, noted, thanks for the work!
<tkamppeter> slangasek, it is ptouch-driver. Simply "apt-get source" it. Then try to add an override_dh_auto_configure to it.
<cjwatson> infinity,cyphermox: Debian seems to have merged the wpasupplicant and hostapd source packages into a single wpa source package.  You two have outstanding Ubuntu modifications to the prior source packages; do you think one or both of you could merge those into the new one?
<cjwatson> It's showing up for auto-sync, which I'm holding off on due to the Ubuntu changes.
<cyphermox> cjwatson: sure.
<roshan> Hello
<cjwatson> cyphermox: thanks
<cyphermox> infinity: I'll take your hostapd changes as well
<cjwatson> slangasek: You're TIL for autoconf; do you think you could merge it, which will allow me to process the autoconf-nonfree removal?
<roshan> I would like to build a custom Ubuntu from the minimal Ubuntu vrsion.
<roshan> I plan to use the 11.10 version
<roshan> My question is, how to I dd the basic necessary packages like networking, desktop, apt-get , and all the basic stuff ?
<roshan> *add
<sladen> roshan: look up "Ubuntu Customisation Kit"
<roshan> thank you. Let me check that
<infinity> cyphermox: Sure, it was a small change.  Thanks.
 * infinity wasn't even aware those were from the same upstream, though it makes some sense.
<roshan> Does UCK support command line ?
<gyotoit22> http://www.reddit.com/r/nsfwhot/comments/u0upg/young_teen_brutal_fucked_by_two_big_cocks/
<cjwatson> apologies for that intrusion
<cyphermox> infinity: wouldn't the migration /lib/init/rw -> /run migration check work as well with just adding || true?
<cyphermox> I mean, so that postinst doesn't bomb if it's trying to move a file to the same destination as it already was
<infinity> cyphermox: Possibly, I don't remember the original code (or my modifications, for that matter).  I don't usually like to mask over errors in symlink/directory issues with || true, though, as there are corner cases that will give you nested directories and such that you really weren't expecting.
<infinity> cyphermox: This may not have had one of those cases.  Like I said, I don't remember. :P
<cyphermox> well, anyway I see this would probably avoid error messages anyway
<cyphermox> gah, I'm repeating words today repeating
<infinity> Heh.
<infinity> (Heh.)
<cr3> barry: if I'm wondering whether I can rely on some python3 package being available in quantal, like python-gst for example, where should I look for an answer instead of pinging you each time? :)
<tumbleweed> xnox: so, what's happening with boost-source1.49?
<xnox> tumbleweed: I am working on it. Didn't finish it yesterday evening.
<xnox> tumbleweed: and I wanted to unbreak the rest of boost.
<tumbleweed> cool. vtk is currently broken and waiting on boost to be unbroken first :)
<xnox> tumbleweed: I am "in charge" of boost1.49 transition =) and I hope to get it finished before alpha1. Note some of the build-failures are due to gcc4.7 and affect debian as well.
<xnox> tumbleweed: awesome =) I bet everyone loves broken vtk =)
<tumbleweed> naah, that's it's steady state
 * xnox "we will not break quantal" meh =)
<barry> cr3: if you know the python 2 version of the package, just search for python3-<whatever>
<roshan> Does Ubuntu Customiation kit allows us to change the look of the Ubuntu ?
<cr3> barry: of course but, if it's not there now, is there a roadmap for quantal?
<sladen> roshan: you can change anything you want in Ubuntu.  The amount of customisation you'll get  depends on the amount of effort you're able/prepared to put into it
<barry> cr3: only if it's required for the desktop cd.  if not, work isn't scheduled, but i am always happy to review ports
<roshan> okay
<infinity> cr3 / barry: In the case of python-gst it's on the desktop CD (apt-cache show python-gst0.10 | grep ^Task), so that answers your question.
<barry> infinity, cr3 it's in the spreadsheet: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AiT4gOXSkmapdFA1anRkWERsaXgtWnllUG9QWXhDVWc&pli=1#gid=0
<infinity> (That too)
<cr3> barry, infinity: awesome, thanks folks!
<barry> infinity, cr3 the suggestion though is to port anything on the desktop to pygi and get rid of the gst dependency :)
<xnox> barry: and no, the tracker update is not trigger from the spreadsheet (yet)
<ScottK> xnox: Does that mean you're working on boost-mpi-source1.49?
 * xnox as you probably figured, due to commits from you
<barry> xnox: that's okay, i figured out how to update the tracker :)
<xnox> ScottK: unless you really want to =)
<ScottK> xnox: No.  I'm glad you're doing it.  I took a first stab at it, it didn't work, and I've not had time to get back to it.
<xnox> barry: now that I have access to people.c.c I will set up a cron job there.
<ScottK> xnox: I have done the split before though, so if you have questions, I'm glad to assist if needed.
<xnox> ScottK: ...thanks =)
<barry> xnox: aweome, thanks
<cr3> barry: I'll try to rewrite scripts depending on gst to use pygi instead of just migrating them to python3, thanks for the heads up
<xnox> ScottK: ok, thank you.
 * xnox is this the time when timezones meet
<barry> cr3: fantastic.  i'm always happy to review
<cr3> barry: I'm equally unfamiliar with both, so should be the same amount of work :)
<infinity> barry: How does pygi relate to gst?  Or is it just that you can use pygi to talk to anything with gi bindings, thus elminating the need to have python bindings for every library?
<dobey> infinity: the latter sort of
<barry> i am not a pygi expert ;)
<dobey> though i don't think gst is really usable from gi yet. though maybe gst 1.0 fixes that
<dobey> hi barry
<slangasek> cjwatson: yep, will do... sorry, I'd so far only looked at the list that launchpad's +localpackagediffs was showing my name for, and that list is... small
<barry> dobey: hi
<dobey> barry: so i am at the brink of having python-oauth 1.0.1 working on python3
<dobey> barry: at least, it does work, except for 1 tiny problem which may be some insanity in the base http server stuff changing in 3
<slangasek> tkamppeter: this works for me:
<slangasek> override_dh_auto_configure:
<slangasek>         dh_auto_configure -- --libdir=/usr/lib
<ScottK> dobey: By definition, if it's different in Python 3, the insanity was in Python, not Python 3.  You've got it backwards.
<ScottK> ;-)
<dobey> ScottK: my standards dictate that if it's python, it is insanity, regardless of version. ;)
<dobey> also, python-oauth is a pretty good example of things to not do in python
<ScottK> Fair enough, but you'll make barry sad.
<dobey> on the contrary, i think making python-oauth work in python3 will make barry quite happy :)
<ScottK> True.
<cjwatson> If you want to print Unicode text to sys.stdout, the insanity required is merely different in Python 3 :-/
<cjwatson> (And not as bad, I'll grant)
<cjwatson> sys.stdout = io.TextIOWrapper(sys.stdout.detach(), encoding="UTF-8", line_buffering=True)  # is the least awful approach I've found that's safe against LC_ALL=C, although not exactly pleasant
<dobey> barry: are you in the debian python module maintainers team?
<slangasek> cjwatson: heh, can that be documented somewhere?
<slangasek> because that's going to come in handy in the future I'm sure :)
<ScottK> dobey: He is.
<cjwatson> barry: ^- perhaps you could document that on Python/3, or some alternative that's more right
<dobey> ScottK: thanks
<cjwatson> this is basically what you need if you have something that might ever run in LC_ALL=C (i.e. the default locale) and processes non-ASCII text
<cjwatson> well, at least in a pipeline-based way
<cjwatson> if it opens files and writes to those it's fine; Python makes an illogical distinction here
<barry> cjwatson: good idea
<barry> dobey: re python-oauth - that's fantastic, can i take a look at a branch?
<dobey> barry: i'm working on getting a branch pushed
<cjwatson> Oh, wait, that's not true about files
<cjwatson> But at least with files you can open with an explicit encoding straight off
<cjwatson> Still a bit of a gotcha though; I wonder if we need to do more explicit encoding= :-/
<dobey> barry: do i need to do all the dh_overrride and python%-foo stuff to make python2 and 3 installs work, or does --with python2,python3 handle that automagically?
<cjwatson> (Which is evil in its own way, though)
<cjwatson> In ubiquity I perpetrated a hack that forces the locale to C.UTF-8 on startup if it's C; but that won't be appropriate for all applications
<barry> dobey: for now, you'll need the overrides for py3, since dh doesn't handle that automatically
<dobey> ok
<barry> dobey: http://wiki.debian.org/Python/LibraryStyleGuide
<tumbleweed> --with doesn't ever affect dh_auto_* AFAIK
<barry> cjwatson: maybe you should subscribe to https://wiki.ubuntu.com/Python/3 ?
<dobey> barry: yep, i'm looking at that. :)
<cjwatson> Sure, done
<dobey> dpkg-deb: building package `python-oauth' in `../python-oauth_1.0.1-4_all.deb'.
<dobey> dpkg-deb: building package `python3-oauth' in `../python3-oauth_1.0.1-4_all.deb'
<dobey> barry: ^^ :) pushing the branch now
<barry> dobey: awesome.  so the main development branch will be the ubuntu branch?
<barry> (dobey: that's fine, as long as vcs-bzr is up-to-date i think)
<dobey> barry: oh no, i just made a patch
<barry> dobey: k
<dobey> barry: was hoping it would just be uploaded into debian that way :)
<barry> dobey: how are you getting it into debian?  bug report?
<dobey> barry: of course, this is completely untested in the Real World (TM) so far.
<dobey> barry: i haven't filed a bug yet, but was hoping you could upload it there
<dobey> barry: anyway, it's at lp:~dobey/ubuntu/quantal/python-oauth/python3-packages
<barry> dobey: actually, i'm not a dd.  i can upload to ubuntu though
<tumbleweed> it's usually best to give ports to upstreams first
<dobey> oh, ScottK lied then :)
<barry> tumbleweed: upstream is long abandoned
<tumbleweed> ah
<dobey> and i am not trying to become the upstream
<barry> no no, me neither :)
<barry> i'll test it and file a debian bug
<ScottK> dobey: No.  I didn't.  Being a member of DPMT doesn't imply being a DD.  You can even join yoursef.
<dobey> oh
<ScottK> barry not being a DD is a bug in the system that he should, however, fix.
<barry> ScottK: i am apparently "in the queue" for an am, but i think the queue is deep
<ScottK> barry: If it's in DPMT, you can just commit to svn.
<dobey> having a team that maintains a package, but for which people in taht team can't upload to, seems silly
<barry> ScottK: good point, i'll check that
<ScottK> barry: OK.  That's good to know.
<dobey> ah, well if can commit to the svn that's a start i guess
<ScottK> dobey: Having people work as a team and having them all be able to commit to the VCS aids sponsorship and getting stuff done.
<dobey> now i wonder if i didn't totally break python-oauth with that patch
<barry> dobey, ScottK http://anonscm.debian.org/viewvc/python-modules/packages/python-oauth/
<ScottK> You might want to email TANIGUCHI Takaki as well.
<dobey> oh, fail
<dobey> ah, of course. i'm an idiot
<dobey> barry: forgot the install files. but just pushed them to the branch
<slangasek> tkamppeter: did that override_dh_auto_configure rule help?
<tkamppeter> slangasek, yes, that works, thank you very much.
<dobey> barry: looks like at least 1 test fails in ubuntu-sso-client as a result of my patch to python-oauth
<apw> can someone remind me where an installed package's postrm is on disk on the machine?
<dobey> apw: in /var/lib/dpkg somehwere
<dobey> barry: hrmm, but this may actually be a bug in ubuntu-sso-client. the test has a unicode char in the url's path
<barry> dobey: nice
<tkamppeter> slangasek, fixed ptouch-driver uploaded to Q and also uploaded for P-proposed.
<slangasek> tkamppeter: excellent :)
<dobey> barry: hrmm. though it looks like after fixing that test, it still fails in the oauth signing, even though the URL looks correct outside of oauth.py. so will have to look at that some more
<barry> dobey: cool, no worries
<mterry> mvo, hello!  What does "update-manager --no-update" do?  I see where it affects the code (calling "self.list.update(self.cache)" or not), but I don't understand what affect that ends up having
<vsingh165> anyone here familiar with bug #822993? https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/822993
<ubottu> Launchpad bug 822993 in nautilus (Ubuntu) "Applying Permissions to enclosed files in Nautilus' Folder Properties window doesn't work" [Low,Triaged]
<vsingh165> I'm a new developer and still figuring this out.
<vsingh165> basically, there's a button in nautilus file properties that allows you to apply a folder's permissions to its contents.  but the button does absolutely nothing
<vsingh165> it was originally found in 11.10, but I've verified that it still happens in 12.04
<mterry> mpt, on the software updates spec (https://wiki.ubuntu.com/SoftwareUpdates), most of the mockups have the ubuntu logo.  But the last two mockups use a package icon.  Is that intentional?
<mpt> mterry, I'm planning to change the others to match those last two
<mterry> mpt, OK, so all should have package icons
<mpt> (the application icon, not a package icon per se)
<mterry> mpt, sure
<mpt> thanks for checking :-)
<ahasenack> hi, can someone please review and if all good upload landscape-client to quantal? This is the bug, and I attached a branch to it based on the current quantal branch (ubuntu:landscape-client):
<ahasenack> https://bugs.launchpad.net/landscape-client/+bug/1004678
<ubottu> Launchpad bug 1004678 in Landscape Client "Release 12.05" [Undecided,Fix committed]
<ahasenack> thanks
 * ahasenack bbl, walk the dog
<andreas__> back
<ahasenack> back :)
<bkerensa> cyphermox: Any more advice to resolve Bug #972063
<ubottu> Launchpad bug 972063 in bluez (Ubuntu) "Bluetooth Headset pairs but does not show up in Sound Settings profile" [Medium,Confirmed] https://launchpad.net/bugs/972063
<infinity> NCommander: Uhm, dude.  debian/rules clean? :P
<infinity> NCommander: Your flash-kernel diff includes debian/flash-kernel (and then on the next upload, you patched the contents of said directory!)
<cjwatson> Don't you have to work pretty hard to do that?  dpkg-buildpackage -S runs clean.
<cjwatson> (Also, *always* read the debdiff before uploading.)
#ubuntu-devel 2012-05-26
<allquixotic> Hi; I'm having an issue with the Rhythmbox external plugin headers in /usr/include/rhythmbox for Precise and Q. Create a C program that does: #include <rhythmdb/rhythmdb.h> and compile with CFLAGS="$(pkg-config --cflags rhythmbox)" . DOA. Can't find a header that it depends on, metadata/rb-ext-db-key.h. It's shipped in the .orig.tar.gz sources and the patchset doesn't rm the missing header and I can't see anything obvious in
<allquixotic> the debian packaging files that would cause it to be excluded. Ideas?
<allquixotic> It's pretty much a blocker for any native (non-Python) third party Rhythmbox plugins that depend on rb-shell.h (almost all plugins with a GUI will depend on that) or rhythmdb, since shell depends on rhythmdb which depends on the missing header.
<allquixotic> Also, if I compile our orig.tar.gz sources from the Precise repo download at https://launchpad.net/ubuntu/+source/rhythmbox/ then it successfully ships the file to /usr/include. The RB packaging scripts use .install files to specify files shipped in certain base directories to get shipped in specific packages; /usr/include is specified as going in rhythmbox-dev, which I have installed. It's just this one header missing; all
<allquixotic> the others are present.
<allquixotic> Oops, ignore that. My mucking around caused it to build. It's actually an upstream bug (referring to my previous monologue). Working with upstream Rhythmbox developer
<roshan> hello
<roshan> I have a question about ubuntu minimal iso
<roshan> Today, I downloaded the Ubuntu 12.004 minimal iso, and mounted using virtualbox.
<roshan> When I tried to install it, it was kind-of downloading some files.
<roshan> I use gprs connection using bluetooth to connect to net. So, if i plan to install that, how will i be able to connect to internet ?
<SpamapS> roshan: I've never insttalled on any such connection, but.. perhaps you should just download the full ISO? Much simpler.
<roshan> Actually, I was planning to customize my own ubuntu startig from the minimal cd
<roshan> Or, do u suggest UCK to remaster Ubuntu
<SpamapS> roshan: ah, I am not the person to ask how to make custom install inmages
<roshan> kei...
<roshan> I asked in general o this channel
<roshan> Hello
 * infinity blinks at how spectacularly a perl FTBFS on i386 breaks the rest of the world.
 * infinity goes about fixing this...
<Kalidarn> infinity: lol there's a wikipedia article https://en.wikipedia.org/wiki/FTBFS
<Kalidarn> "It may also be considered vernacular language because its use tends to be specific to the Debian and Ubuntu Linux distributions."
<Kalidarn> and the funniest thing is the example was for libsql-statement-perl a perl module
<infinity> With packages like "haskell-reactive-banana", I'm starting to see the appeal...
<iulian> Heh.
<FirePowi> Hi
<roshan> Hello
<roshan> I wish to compile a linux kernel for my Ubuntu 12.04
<roshan> When compiling, I wish to use an alternate config file, whih i have kept in the Desktop.
<roshan> How to use that ?
<roshan> I mean how o use this new config file in desktop?
<vibhav> How do I configure pbuilder to take packages from ubuntu mirrors in debian?
<jtaylor> why would you want to do that?
<vibhav> jtaylor: I own a debian VPS, I would like to configure it to build ubuntu packages
<vibhav> and I want it to use packages from ubuntu
<jtaylor> adding ubuntu sources to debian will more likely just break it
<jtaylor> or do you want an ubuntu chroot in debian?
<vibhav> yeah
<jtaylor> add the ubuntu keyring to DEBOOTSTRAPOPTS and set MIRRORSIRE and COMPONENTS
<vibhav> How do i do that?
<jtaylor> via the commandline or .pbuilderrc
<jtaylor> pbuilder-dist should do everything out of the box
<tumbleweed> ^ pbuilder-dist knows what to do
<vibhav> I still did not get it
<vibhav> pbuilder-quantal
<vibhav> -bash: pbuilder-quatal: command not found
<jtaylor> pbuilder-dist quantal
<jtaylor> read the manpage
<vibhav> Oh wait
<vibhav> got it
<vibhav> pbuilder-dist quantal create
<vibhav> thanks jtaylor
<tumbleweed> vibhav: I do prefer sbuild, though
<jbicha> +1 for sbuild
<roshan> Hello, I would like to remaster Ubuntu. For taht is it possible to modify the command prompt ubuntu@ubuntu to user@roshan-ubuntu
<penguin42> wth is going on with apt on my system - libqwt-dev is always claimed to be upgradable, it installs it, and then still claims to be upgradable with exactly the same package version
<jtaylor> yes thats a strange bug
<jtaylor> bug 997201
<ubottu> Launchpad bug 997201 in qwt (Ubuntu) "libqwt-dev (6.0.0-1ubuntu1) in update loop" [Undecided,Confirmed] https://launchpad.net/bugs/997201
<penguin42> jtaylor: Thanks
 * penguin42 can't see anything obviously wrong with the package or the state of the system
<dupondje> Given a GTK Application. Is it preferred to use cairo functions and gdk? Or are X functions also safe to use?
<dupondje> With wayland in minds.
<l3on> penguin42, which ubuntu release? oneiric ?
<jtaylor> precise
<l3on> it seems oneiric also affected. bug marked as duplicated of bug 921430
<ubottu> Launchpad bug 921430 in qwt (Ubuntu) "Package libqwt-dev wants to upgrade every time" [Undecided,Confirmed] https://launchpad.net/bugs/921430
<l3on> patches sent.
<jtaylor> still looks like a bug in apt to me
<jtaylor> but good work triaging it
<jtaylor> oh its main aI can'T sponsor :(
<penguin42> l3on: Thanks for the fix!
<l3on> thanks jt in any case ... penguin, you're welcome...
#ubuntu-devel 2012-05-27
<scientes> where is the BTS/buildd stuff for ubuntu?
<scientes> **alioth
<xnox> scientes: ?
<xnox> can you please expand your question?
<xnox> scientes: generally https://launchpad.net/ubuntu
<scientes> this: https://buildd.debian.org/status/package.php?p=openssh
<xnox> search for package name & it should give you everything
<xnox> scientes: https://launchpad.net/ubuntu/+source/openssh/1.1.2-2
<xnox> sorry
<xnox> scientes: https://launchpad.net/ubuntu/+source/openssh
<scientes> oh, he hasn't even uploaded 6.0 to ubuntu yet, only debian
<xnox> scientes: https://launchpad.net/ubuntu/+source/openssh/1:5.9p1-5ubuntu1
<xnox> and buildlogs there.
<xnox> scientes: well we have patches against openssh, so it will land in ubuntu after merging.
<scientes> he works on ubuntu, so he will merge it soonish
<Bluefoxicy> thank the white god for all he's done for legacy program that would otherwise have to suffer on closed source, outdated operating systems.
<Bluefoxicy> Selecting previously unselected package libwind0-heimdal:i386.
<ScottK> xnox: Uploaded boost-mpi-source.  Thanks.
<ScottK> xnox: If you extend the good/bad definitions for the boost transition to include the -dev packages (like you have in affected) you'll end up with fewer unknowns.  I think it would help.
<xnox> ScottK: ok, thanks. I copied the transition tracker out of debian ;-) it helps to cross-check with ftbfs/uninstallable list though
<ggherdov> Hello, I am noticing an oddity in a package for Precise: https://launchpad.net/ubuntu/precise/+package/solr-common . Basically, in the README file you read about an "example" and a "doc" directory, which is nowhere in the package (to my great disappointment :-). Here some data: file contained in the packade (dpkg -L) (note: no example/README.txt, no docs/index.html as well) : http://bpaste.net/show/QwgH5u0pjUAbKCiXhygd/ info
<ggherdov> about the package (dpkg -s): http://bpaste.net/show/sgpUDVlCEsEXSPo2FO68/ README where the folders are announced: http://bpaste.net/show/dHGcVlcO3yJvwVrYLgq1/ before filing a bug report, I wanted to check with you if I am missing something obvious
<ggherdov> if anything, even a pointer to contact the package mantainer would be fine -- I would ask directly him / her. How does one get the mantainer address for a given package?
<kimus> hi, where's the best place to help me why Virtualbox stopped to work configured in Bridged mode with libvirt's virbr0 interface?
<ggherdov> kimus: #vbox I guess
<kimus> ggherdov: they told me that "Bridged doesn't always work on wireless and to use NAT" !! That was the wrong answer to me :-) Bridged  works fine on wireless and I wanted to use the virbr0 interface :-D
<kimus> dnsmasq it's running but I can't have dns working on the guest VM or even static network does not work. :-S
#ubuntu-devel 2013-05-20
<vipzrx> hello
<vipzrx> hello ,everyone
<Noskcaj> if kirkland or andreseal is online, get them to ping me please
<jamespage> jodh, around? have you seen upstart doing something like this before: http://paste.ubuntu.com/5683425/
<cjohnston> cjwatson: I believe /7
<cjohnston> sorry. I believe I have an email pending on ubuntu-devel.. when you get a chance, could you please ack it
<cjwatson> cjohnston: done
<cjohnston> ty cjwatson
<jodh> jamespage: it looks correct based on what the somewhat elaborate .confs specify. I've never used ceph though :)
<jamespage> jodh, the ceph processes are OK - I just wondered why there are not proc 1 owned (the sh wrapper is)
<jamespage> i.e. init -> sh -> ceph-mon for example
<jodh> jamespage: because the job doesn't specify "exec" in the script stanza so upstart spawns ad shell to run what is in that stanza.
<jamespage> jodh, "exec /usr/bin/ceph-mon --cluster="${cluster:-ceph}" -i "$id" -f"
<jamespage> looks OK to me
<jamespage> jodh, full listing - http://paste.ubuntu.com/5683597/
<cjwatson> ${cluster:-ceph} requires a shell to evaluate it
<jodh> jamespage: ah - well, upstart cleverly detects that the exec line specifies shell syntax, and so passes the arguments through /bin/sh for you (otherwise, it wouldn't work :)
<cjwatson> See init(5) - "Any special characters, e.g. quotes or `$' specified will result in the entire command being passed to a shell for expansion."
<jamespage> cjwatson, jodh: ah! right - I thought it might be something like that
<jamespage> thanks
<jodh> jamespage: in your case, "$" is used, which causes the shell to be spawned.
<cjwatson> Any MIR folks want to have a look at graphite2?  It's a bit inconvenient for texlive to be uninstallable in saucy-proposed.
<infinity> cjwatson: It has no bug filed.
<infinity> cjwatson: (Also, I'm about to go nap, yay long weekend, but if someone like jdstrand or mterry doesn't beat me to it, I'll look at it when I wake up)
<ogra_> oh, canada too ?
<cjwatson> Yeah, I was tracking down the version of texlive-bin that introduced the build-dep before filing a bug
<cjwatson> But it's not in the changelog so that's involving a bit of downloading
<infinity> Hrm.  If graphite2 is a simple evolution of silgraphite2.0, you can just promote it without an MIR.  You might want to poke the sources and see if it's just a renaming of the upstream project.
<cjwatson> Oh, hadn't twigged to silgraphite2.0
<cjwatson> I'll see if the build-dep changes bear that out
<cjwatson> Looks like libgraphite-dev (>= 1:2.3.1) -> libgraphite2-dev
<cjwatson> -  --with-system-graphite  use installed silgraphite headers and library
<cjwatson> +  --with-system-graphite2 use installed graphite2 headers and library
<infinity> cjwatson: Yeah, I was more curious if it really is basically just a new version of the same source.
<infinity> Or if it's an entirely new and differently sketchy version of a similar library.
<cjwatson> Also would be nice if we could only have one in main
<infinity> Yeah, that's probably easily solved.  libgraphite3 has almost no rdeps.
<cjwatson> Hmm.  If it's the same thing, it's laid out very differently.
<infinity> *&%! tarball-in-tarball packaging of silgraphite2.0 makes diffing a bit of a pain. :P
 * infinity unpacks.
<cjwatson> Though graphite2's debian/copyright says http://sf.net/projects/silgraphite
<cjwatson> Which says "Graphite2, a new version of the Graphite engine"
<tumbleweed> tarball-in-tarball isn't dead yet? :/
<tumbleweed> infinity: are there any significant differences between PPA and primary archive chroots / environment? I'm trying to figure out why pypy PPA builds are hanging on a particular test
<infinity> cjwatson: The layout's completely different, but if the upstream's the same, I'm all for screaming "la la la", and swapping them.
<cjwatson> There seems to be a kind of spiritual ancestry here but I'm getting more of a rewrite-from-scratch sense
<infinity> cjwatson: texlive is the only thing in main that depends on it.
<infinity> tumbleweed: The chroots are identical, installed packages could differ if you haven't let your PPA depend on -proposed (it's a twiddle), and kernels could be different (virtual PPAs are hardy kernels on Xen, non-virt builders are precise kernels on bare metal)
<cjwatson> http://projects.palaso.org/projects/graphitedev/wiki
<cjwatson> Oh, I guess c-m-proposed doesn't want to drop silgraphite2.0 yet because binary deps aren't yet up to date
<tumbleweed> infinity: ok, that gives me some things to play with. thanks
<cjwatson> infinity: OK, sounds like "swap it", then - I'll make that happen today
<cjwatson> I have a bit of a chain of stuff on top of this.
<infinity> cjwatson: Bonus points if we could ditch the old one entirely, but who knows if pango-graphite is ported.
<cjwatson> infinity: Probably have to wait for Debian there
<infinity> cjwatson: We didn't end up breaking the world with a tex transition this time at least, I hope?  Just this component oops?
 * infinity has nightmares about having to rebootstrap tex* crap yet again.
<cjwatson> Hope not, but can't tell yet.
<cjwatson> texlive-bin doesn't seem to have tight build-deps.
<infinity> Well, the killer used to be that we carried a delta on exactly one tex* package, and if we let autosync sync the rest, it would skew and none of it would build anymore.
<cjwatson> Or indeed to build-dep on anything texish.
<cjwatson> I *think* we got rid of that delta ...
<cjwatson> Wasn't that tex-common?
<infinity> Yeah, that delta was in texlive-bin, I think.
<cjwatson> I've spent the best part of a day cleaning up bits in -proposed.  I should probably do some actual work at some point ...
<infinity> Heh.  At least it was your work day.
<cjwatson> https://launchpad.net/builders/ - are the armhf builders a bit sad?
<cjwatson> 47 minute queue, allegedly 7 builders idle.  I suspect porkies.
<infinity> cjwatson: They lost track of a PDU that happened to be the only way to stab a bunch of the Pandas, so as they've been dying for other reasons, they've been unrecoverable.
<infinity> I'm told this is in progress.
<cjwatson> Oh dear
<infinity> The idle buildds are suspicious, though.
<cjwatson> Yeah, sounds more like buildd-manager fail.
<infinity> That could be a Network Event causing a mass Right to Choose exercise.
<NikTh> Hello everybody.
<infinity> Anyhow, I'm going to go enjoy my freedom to not be tied to a laptop for a day.
<NikTh> QUESTION: Do I have to do something special in order for debuild to sign a .dsc file when I want to upload a custom kernel on a PPA of mine ?
<infinity> NikTh: Just run "debsign foo.changes" on the changes file that you plan to upload.
<NikTh> I uploaded without problems a custom package of unity-tweak-tool in my PPA ..
<NikTh> But I'm not able to debuild correctly a custom kernel. Deubild does not product a .dsc file (only source.changes is not enough)
<NikTh> infinity: Thanks I will try that immediately
<NikTh> I will describe here step by step what I'm doing right now.. (anyone who wants to help.. welcome)
<NikTh> 1) I'm downloading the source code of linux-image-3.8.0-21-generic
<NikTh> I'm patching the kernel.. "patch -p1 < ~/foo.patch
<NikTh> 3) Now editing the changelog file (dch -i)
<NikTh> Ok, what is the next command ?
<NikTh> debuild -S -sd -k<keyid> , is that correct ?
<NikTh> The results are "Successfully signed changes file" (but not .dsc file created)
<cjwatson> NikTh: You're making life hard for yourself by passing -sd.  Why?
<cjwatson> I never use -sd.
<cjwatson> NikTh: But as for the rest of it, debuild -S should be sufficient to create a .dsc.  Post the whole output on a pastebin.
<NikTh> cjwatson: because the source code already exist in Ubuntu repositories. Despite that I used debuild -S -k (without -sd) but the results were the same.
<infinity> NikTh: Also, due to the hilarious way the kernel is packaged, dch -i won't do what you think it will.
<infinity> NikTh: It's going to update debian/changelog, and then when the clean target runs, debian.master/changelog will get copied over debian/changelog. :P
<NikTh> Full terminal results here: http://pastebin.com/mKbn2ggu
<NikTh> Yes, yes, yes you have right about this infinity . Overrides my debian/changelog. But how can I fix that ? So I told before that MY source.changes file is exactly the same as the original :P  LoL
<infinity> NikTh: "dpkg-source: info: building linux in linux_3.8.0-21.32.dsc"
<infinity> NikTh: It built just fine, just with the old changelog.
<NikTh> Hahahaha
<infinity> NikTh: So, do your 'dch -i', then "cp debian/changelog debian.master/changelog", then do your debuild.
<NikTh> hmm.. lets see
<cjwatson> NikTh: already exists> -sd is not as necessary for that as you think it is.
<NikTh> cjwatson: I've read the instructions here> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage (see the "options when building" paragraph)
<cjwatson> -sd only makes any difference if you are packaging a *new upstream version* and have some specific reason not to include the upstream tarball in the upload.  Which is basically never the case - I haven't needed -sd in 14 years of development.
<cjwatson> Yeah, that advice is, well, maybe not wrong as such but pointless.
<cjwatson> You can quote me on that.
<cjwatson> Anyway, it's not actually the problem here, just a confusing red herring.
<cjwatson> -sa *is* sometimes needed because, unlike Debian, our versioning for new upstream versions isn't nearly-always predictable by dpkg-genchanges.
<NikTh> Thanks cjwatson . I have no reason to doubt about your development skills. I'm a newbie in ubuntu-devel and just followed the instructions there :-)
<cjwatson> Yeah, I appreciate that it's often easiest to just follow the docs.  I didn't realise we were recommending -sd to people.
<NikTh> OK, now I did what infinity suggested (cp debian/changelog ...etc) . What is the most correct command for debuild ? debuild -S -k<keyid> (correct cjwatson ? )
<cjwatson> Yep, that should be fine.  You can put DEBSIGN_KEYID=<keyid> in ~/.devscripts so you don't have to type it all the time.
<cjwatson> So most of the time for ordinary uploads I just use 'debuild -S'.
<NikTh> Thanks !
<iBelieve> I sent a message to the ubuntu-devel mailing list about a week ago with an idea for Click Packages, but I don't think it ever got posted (I checked the archives, and it isn't in there). Is there a way to see if it got sent to the list, or should I just resend it?
<cjwatson> it's probably in the mod queue
<cjwatson> I've flushed the remaining click-package-related things out of there now
<iBelieve> cjwatson, thanks, that is what I thought, but it just seemed a long time
<cjwatson> yours was in there
<iBelieve> cjwatson, good, that's nice to know that it actually did send.
<NikTh> Victory !!!
<NikTh> infinity, cjwatson  !! Thanks a lot. :-)
<rbasak> infinity: I've redone the facter merge and included SRU debdiffs for precise, quantal and raring in bug 1173265 - also including a fixes for bug 1170325. Could you have a look when you get in, please?
<ubottu> bug 1173265 in facter (Ubuntu) "facter fails to run from rebuilt source package" [High,Triaged] https://launchpad.net/bugs/1173265
<ubottu> bug 1170325 in facter (Ubuntu Raring) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New] https://launchpad.net/bugs/1170325
<infinity> rbasak: Long weekend here (I'm both asleep and not at my computer, and possibly also partying and drunk right now), but if you poke me tomorrow, I'd be happy to review and sponsor the lot. :)
<rbasak> infinity: will do - thanks!
<NikTh> And the e-mail just arrived " Accepted: " :-) :-)
<sil2100> Hello, is there anyone from the SRU team here right now?
<zequence> I'd like some help with targetting this bug to releases quantal and precise https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1163638, anyone?
<ubottu> Launchpad bug 1163638 in pulseaudio (Ubuntu) "pulseaudio fails to release card to jack" [Undecided,Confirmed]
<bdmurray> kirkland: do you have any plans to SRU bug 1173209?  If not I'll work on it today.
<kirkland> bdmurray: go for it
<kirkland> bdmurray: I'll verify it for you, if you like
<bdmurray> kirkland: I'll let you know thanks
<kirkland> bdmurray: thank you!
<ubottu> bug 1173209 in ubuntu-release-upgrader (Ubuntu Raring) "Prompted about New Release for 13.04 again after dist-upgrade and a restart" [Low,Triaged] https://launchpad.net/bugs/1173209
<psusi> shouldn't /etc/os-release identify the specific ubuntu flavor installed?  i.e. Ubuntu Studio or kubuntu?
<Riddell> psusi: they're all the same os
<psusi> hrm... I guess so..
<iBelieve> I've reinstalled Ubuntu several times for various reasons (switching derivatives, etc) so now I have 3 OpenPGP keys (a new one and 2 old ones). Do I need the old ones, or can I delete them?
<iBelieve> ^^ OpenPGP keys in my Launchpad account.
<tumbleweed> iBelieve: if you aren't going to be signing things with the old ones, you don't need them
<iBelieve> tumbleweed, since I don't have them on my computer, no I won't be. Will deleting them affect things that I've already signed, like the Code of Conduct or projects I've contributed to?
<tumbleweed> no
<tumbleweed> in future, I recommend revoking keys before you lose control of them (or just back them up)
<iBelieve> tumbleweed, Okay, thanks for the help and advice.
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<lifeless> barry: so, you suggested we could arrange a chat about image upgrades
<barry> lifeless: yep.  stgraber ^^
<stgraber> yep, can definitely find some time this week. Today's a public holiday here though so trying to minimize work-related time ;)
<lifeless> fair enough
<lifeless> what tz's are you both in?
<stgraber> we're both on EDT (US/Canada eastern)
<lifeless> stgraber: current local time for you?
<stgraber> 3pm
<lifeless> how about my thursday, your wednesday, at your 1600 ?
<barry> lifeless: that would work for me
<lifeless> I'd only have 30-45m then, but that's enough to have a solid chat.
<stgraber> works for me
<slangasek> stgraber: this is officially my worst dpkg hack ever (ifupdown)
 * Laney is excited to see it
<stgraber> slangasek: haha, yeah, I figured it'd have to be pretty ugly after I read your comment on the cause of the problem ;)
<slangasek> Laney: uploaded, enjoy ;P
<slangasek> (tested for precise conffile state -> 0.7.5ubuntu4; precise conffile state -> 0.7.5ubuntu3 w/ "no" response -> 0.7.5ubuntu4; precise conffile state -> 0.7.5ubuntu3 w/ "yes" response -> 0.7.5ubuntu4; raring conffile state -> 0.7.5ubuntu3 -> 0.7.5ubuntu4; raring conffile state -> 0.7.5ubuntu4)
<slangasek> the only case this doesn't test for is the possibility that in the *next* version of ifupdown the user installs, the md5sum of the conffile changes again
<slangasek> in that case, we probably get another conffile prompt :/
<slangasek> (only for the precise -> 0.7.5ubuntu4 -> somethingelse case, fwiw)
<slangasek> stgraber: ^^ so that means that if you have any reason to change /etc/init.d/networking for saucy+1, we'll need some additional maintainer script handling at that point ;)
<stgraber> slangasek: I don't plan on changing it myself, can't speak for Andrew though, he loves changing things ;)
<slangasek> stgraber: yeah ;)  but if you *merge* a change, too :)
<lifeless> stgraber: whats your ubuntu email ?
<stgraber> lifeless: stgraber@ubuntu.com
<lifeless> stgraber: barry: invity thing sent
<barry> lifeless: cool
<catbus1> Anyone know when kernel freeze will be for 12.04.3? No such info on https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<mlankhorst> catbus1: raring kernel is used
<catbus1> mlankhorst: the kernel freeze date for LTS point release is for new hardware support, right? raring kernel is already frozen, only critical patches/fixes can go in as SRU.
<cjwatson> Laney: Could you merge (ish) the new fonts-dejavu package from Debian?  It's needed to make texlive-fonts-extra installable again.
<cjwatson> And you're touched-it-last and ttf-dejavu
<cjwatson> s/and/on/  # how did that happen?
<geser> spell-checker? :)
<cjwatson> Evil things (so no)
<mwhudson> doko__: hey, are you around?
<Laney> cjwatson: a renamed source package?
<Laney> I'm sure I can manage that
<cjwatson> Yep, the usual ttf -> fonts dance.  Thanks
#ubuntu-devel 2013-05-21
<pitti> Good morning
 * pitti takes the plunge and uploads udev, got 10+ positive results now and no regression report
<doko> infinity, http://gcc.gnu.org/ml/java-patches/2013-q2/msg00046.html
<ubottu> gcc.gnu.org bug 2013 in c++ "g++ 2.96: typedefs + namespaces + inheritance == problem" [Normal,Resolved: fixed]
<doko> looks like stdc-predef.h is there since 2.16, but wasn't installed?
<xnox> ScottK: nope.
<theothertom> hello, is this the right place to ask about rebuilding packages in order to move them to /opt ?
<StevenK> We will not build packages for the Ubuntu archive that install files under /opt.
<Laney> I think you want #ubuntu-app-devel or #ubuntu-packaging (not sure which, I'm afraid)
<theothertom> Laney: OK, thanks. I'll check there
<Laney> theothertom: Cool, good luck. This channel is for "official" Ubuntu development really, I'm afraid - those other places should be more for third party stuff. :-)
<theothertom> I fell I'll need the luck, this turned out to be harder than it sounded at the start :)
<henrix> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, stgraber
<mpt> cjwatson, would turning off source packages by default (as in, indexes downloaded during apt-get update) be something changed in software-properties, or ubuntu-meta?
<cjwatson> Certainly not ubuntu-meta.
<cjwatson> apt-setup is the place that controls this during installation.  But it would also require changing every piece of documentation that assumes that 'apt-get source' works out of the box.
<cjwatson> Which is one reason I've always resisted this.
<mpt> ta
<xnox> mpt: it would be nice, to auto-enable or offer to auto-enable src-lines when one tries to fetch a source package, and no source entries are specified.
<mpt> I wouldn't care about it except that downloading unnecessary stuff -> update checks complete less often -> security updates installed later on average
<mpt> xnox, as I understand it, that's bug 301602
<ubottu> bug 301602 in software-properties (Ubuntu) "enabling proposed only adds deb line to apt.source, deb-src missing" [Low,Confirmed] https://launchpad.net/bugs/301602
<mpt> Oh, no, that's slightly different
<mpt> but yes, that would be nifty
<cjwatson> Unfortunately apt-get source runs as the user and apt configuration is owned by root, so it's not trivial.
 * ogra_ doesnt get why it would delay anything though
<cjwatson> It would only cause update checks to complete less often if the duration of updates exceeded the frequency of updates.
<ogra_> apart from making apt-get update minimally slower, the source packages should aways match the binaries
<cjwatson> Which doesn't sound plausible.
<xnox> sure, one should be able to be able to read those, copy out / guess-generate -src entries for the user and update-fetch as a user =)
<cjwatson> And in any case the growth of the archive over time eventually dominates ...
<mpt> cjwatson, what do you mean by "the duration of updates"?
<cjwatson> The time it takes to complete 'apt-get update'
<mpt> whereas by "the frequency of updates" you mean how often updates are issued?
<mpt> or how often apt-get update is run?
<apw> pitti, was it today we are expecting udev to explode ?
<ogra_> mpt, that was clearly hypothetical (the archive growing faster than an apt-get update takes)
<mpt> ogra_, I'm not sure what it means yet, I haven't yet got to whether it's hypothetical or actual :-)
<mpt> How long an apt-get update takes is measured in seconds. How fast the archive grows is measured in, what, kilobytes per second? Not even the same units.
<ogra_> mpt, apt-get update getting you package-x.1.2 and while it runs version x-2.3 was uloaded, built and promoted
<mpt> ah I see
<ogra_> *uploaded
 * apw wonders what just happened there... according to my logs you can all type like mad-people :)
<apw> pitti, was it today we are expecting udev to explode ?
<ogra_> s/getting you package/getting you info about package/
<cjwatson> mpt: I mean how often apt-get update is run
<cjwatson> mpt: What's the basis of your assertion that update checks complete less often?
<mpt> cjwatson, in that case, I don't see why frequency of updates-being-issued makes any difference at all. Update checks fail to complete because you turn the computer off, or lose the connection, not because a file was changed while it was being served.
<cjwatson> Oh, right
<cjwatson> (I wasn't talking about frequency of updates being issued, as it happens.  But anyway.)
<mpt> (I'm assuming Web servers are smart enough to keep around the old copy of a file long enough to serve the rest of it.)
<cjwatson> If the file is open, the open descriptor continues to refer to the original version
<cjwatson> And you entirely misunderstood my comment about how fast the archive grows.
<mpt> Clearly.
<cjwatson> My point is that turning off deb-src lines is a change we get to make once ever
<cjwatson> And the growth of the archive over time will dominate quickly enough anyway
<cjwatson> So, if there's a problem with unreliable updates, we still have to solve it
<cjwatson> For instance, dapper source + i386 binary index files: 5878756 bytes.  hardy ditto: 9671815 bytes.
<mpt> I don't know that unreliability is something we can "solve", as long as we're using TCP at least. :-)
<cjwatson> lucid ditto: 14048852 bytes.
<cjwatson> And the source accounts for rather less than a third of that.
<cjwatson> (OK, that's gzip, and we might actually end up fetching bz2 in practice, but much the same analysis applies)
<mpt> Wait, so we could speed up update checks by a quarter or so, and the argument against it is that they'll slow down later?
<cjwatson> That's not the argument against it; that's just an argument why it doesn't really help in the long term and we have to solve other problems *anyway*.
<cjwatson> The argument against it is that it significantly complicates any documentation that involves people helping us.
<cjwatson> (At least by way of contributing to source code.)
<cjwatson> Or documentation that tells people how to look at the source we provide.
<cjwatson> If people want to go hunting for that and figure out good ways to make it not suck, be my guest
<cjwatson> But everyone so far who's proposed this has just ignored the problem
<cjwatson> Which I don't think is OK ...
<mpt> All the "Let's switch to bsdiff" or "make -data dependencies smarter" or "parallelize apt tasks" are similarly things that can be done only once in the face of that growing archive.
<mpt> But I get your point about the documentation.
<cjwatson> And any of those would also have to be accompanied by going round and looking at the system as a whole and seeing what would need to be adjusted to match.
<cjwatson> It does look like the growth has slowed a little bit; I think part of this is archive-level changes, and part is that we've got more aggressive about removing packages
<cjwatson> By solve other problems, I mean that if updates are failing for whatever reason then that is something we need to (a) be tracking and (b) mitigate, perhaps by way of the system trying again earlier than it would otherwise do, for instance
<cjwatson> At the moment I believe we basically just pop up an indicator and punt to the user?
<mpt> Most often  update checks are done in the background
<cjwatson> Right, but there is a notification if they fail, I think
<cjwatson> And I don't think we schedule additional background runs if an update check fails
<mpt> If you get a notification merely because you restarted the computer during an update check that you didn't know was happening anyway, that would be a bug
<cjwatson> Oh.  So we make no effort at all.
<cjwatson> Well, I think there's room for the theory that we could be being more aggressive than that.
<mpt> I don't know. I know there are many bugs about misusing the applet area
<cjwatson> (And I don't mean by popping up more notifications.)
<Daviey> xnox: Regarding you suggestion.. you could make apt-get source and alias for pull-lp-source $DISTRIB_CODENAME .. I can't think that many people really use multiple release support. And if they do, they know how to fix it.
<cjwatson> I guess what I mean is that it seems unlikely that we wouldn't be able to complete an update check at some point during the day, unless the computer wasn't on for long enough to apply the updates anyway.
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, stgraber, xnox
<Laney> pilotfest
<seb128> some fall asleep in the seat? ;-)
<mitya57> xnox: hi, can you please look at https://code.launchpad.net/~mitya57/kubuntu-packaging/qt-lp1180067/+merge/164629 ?
<mitya57> (last time I fixed ui themes, but completely forgot about icon themes)
<xnox> mitya57: I see. The patch is interesting. I thout that when we are build with GTK style, we are linked against libgtk-x11 anyway, and thus can use that api directly instead of doing well esentially dlopen?!
<xnox> anyway do you have a url where it's applied upstream?
<mitya57> xnox: I just used the existing stuff from QGtkStyle...
<xnox> ack.
<mitya57> upstream change is https://codereview.qt-project.org/#change,56458
<mitya57> not applied yet, but (as I wrote) I got a pre-approval on IRC
<xnox> I wonder why they did it this way, instead of using pre-processor.
<xnox> I was after Qt5 location, but ok.
<mitya57> xnox: also, libQtGui.so.4 isn't linked against gtk here
<xnox> right, so they dlopen everything then. ok. sounds/looks scary to me.
<mitya57> yes, that will be weird if qt had a hard dependency on gtk
<ev> Daviey: can you let my post to ubuntu-server@.u.c through?
<cjwatson> FYI, if people are wondering (or indeed noticed) why auto-syncing from Debian stopped, or why you can't syncpackage things uploaded there very recently (12 hours or so I think), it's because there was a Debian upload with a syntactically-invalid Maintainer field that caused the LP import to explode.  Being fixed on the Debian side.
<mitya57> cjwatson: which upload? (just curious)
<cjwatson> gdb
<Laney> that seems like an unfortunate failure mode
<cjwatson> It's not ideal.  It's fairly noticeable though :)
<cjwatson> (I made that same comment on the ops channel)
<cjwatson> Hah, apparently auto-syncing anything alphabetically less than gdb works, though ...
<cjwatson> Updating: aafigure alpine calibre commons-daemon flickcurl
<geser> seb128: you mean like in http://articles.timesofindia.indiatimes.com/2013-05-03/india/39008133_1_flight-attendants-cockpit-airbus-321 ?
<seb128> heh
<cjwatson> SpamapS: does the Ubuntu change in drupal6 to add a debconf note need to be ported over to drupal7?  I ask because drupal6 is slated for removal
<jamespage> is there a nice way to override kernel.core_pattern during a package build? I have a library that wants to generate a core file for testing....
<pitti> jamespage: wouldn't it be easier to just set ulimit -c, and use `pwd`/core ?
<diwic> zequence, hi, I saw you submitted merge proposals, have you also tested the result so you know it actually fixes the problem?
<jamespage> pitti, the test wrapper sets ulimit -c 100000
<jamespage> pitti, but I don't get `pwd`/core
<penguin42> pitti: That does assume that core_pattern is set to the default when you start
<jamespage> pitti, in my local schroot the core_pattern is picked up from the host - "|/usr/share/apport/apport %p %s %c"
<pitti> sure, but why would the buildds chagne that/
<pitti> jamespage: right, but apport mimics the original "core" creation, and I don't think that the buildds have it installed
<jamespage> pitti, hmm - so its probably OK on a buildd - makes testing it locally awkward
<pitti> jamespage: oh, I thought you were talking about "during package build" on a buildd
<pitti> jamespage: but again, if you don't get a core file with ulimit -c with apport, that's a bug
<jamespage> pitti, well I don't get a core file
<pitti> $ ulimit -c 100000; sh -c 'kill -SEGV $$'
<pitti> Speicherzugriffsfehler (Speicherabzug geschrieben)
<pitti> $ file ./core
<pitti> ./core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'sh -c kill -SEGV $$'
<jamespage> pitti, and from within a schroot?
<pitti> $ ulimit -c 10000
<pitti> -bash: ulimit: core file size: cannot modify limit: Operation not permitted
<jamespage> hmm
<jamespage> lemme take another look - something wonky is going on
<pitti> I'm not sure why I can't do ulimit in a chroot
<jamespage> pitti, I think its hard limited to 10000
<cjwatson> Depends on your chroot, I guess.  100000 WFM.
<jamespage> pitti, cjwatson: I only get a core in the schroot filesystem if I "sudo sysctl kernel.core_pattern=core" on the host first
<mardy> kenvandine: hi! I updated https://code.launchpad.net/~mardy/ubuntu-system-settings/proto/+merge/164195 :-)
<pitti> asac: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<kenvandine> mardy, great, thanks
<pitti> asac: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/
<mlankhorst> can someone approve all the lts-raring packages for precise-proposed in NEW?
<zequence> diwic: Yes. The bug report is also prepared for SRU
<pitti> asac: mac80211_hwsim kernel module
<pitti> asac: and for ethernet, linux' veth
<zequence> diwic: I'm a bit unsure of what to do next, as far as the SRU goes, but I guess you guys will roll the package,or something. Seems a little different with pulseaudio
<diwic> zequence, thanks. Once it has been let through to -proposed you will have to do the testing one more time
<diwic> zequence, but I think you know that already. As for SRU next part is on me to merge and upload. I want to get a few other things through at the same time, so will not upload today.
<zequence> diwic: So, until the -proposed testing, is there anything more I need to do?
<diwic> zequence, except hit me in the head if I forget about it.
<jcastro> slangasek: I need your help when you're around
<zequence> diwic: I'll remind you by the end of the week then :)
<kenvandine> mardy, commented
<pitti> asac: http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
<mardy> kenvandine: your remark about the rpath is only about src/src.pro, right?
<mardy> kenvandine: because I think that in the other cases (for tests) it's needed
<geser> Could someone please do a give-back of ptouch-driver on armhf in saucy-proposed. It got hit by a chroot failure (on heka). Thanks
<kenvandine> for all of them
<kenvandine> mardy, it's not needed
<SpamapS> cjwatson: re drupal6->7 ... I don't think it would be the worst thing if we dropped that delta.
<mardy> kenvandine: mmm... not even for the tests? But won't they link to the installed library then?
<kenvandine> i don't think so
<kenvandine> mardy, nope, tests work fine
<cjwatson> SpamapS: OK - I can just go ahead and remove drupal6 if that's fine with you, then, since it's been removed from Debian
<cjwatson> geser: done
<NikTh> Here I'm again :P
<NikTh> New problem occurred
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, stgraber, xnox, Laney
 * Laney prods henrix stgraber xnox to pilot out if applicable
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, xnox, Laney
<henrix> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> 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, Laney
<NikTh> infinity: Hi.. remember from yesterday  where you helped me to solve the problem on how to upload correctly a custom-kernel in a PPA of mine ? :P Here I'm again ..
<NikTh> I would appreciate little more help on building failure messages. (or anyone else of course who knows and he/she is able to help)
<mardy> kenvandine: OK, the rpath I had before was wrong. Still, we need that option (set to /usr/lib/system-settings/) otherwise ld won't find it when starting the app
<NikTh> Go straight to the last lines where the failure message appear
<NikTh> https://launchpadlibrarian.net/140388814/buildlog_ubuntu-raring-i386.linux_3.8.0-21.32ubuntu1~nikth1_FAILEDTOBUILD.txt.gz
<kenvandine> mardy, ok
<mardy> kenvandine: I pushed it, and it seems to be working for me; please check
<mardy> kenvandine: it would work without it, if the lib was installed in /usr/lib
<mardy> kenvandine: maybe we should leave it there?
<kenvandine> tests don't work now
<kenvandine> ./tst_plugins: error while loading shared libraries: libSystemSettings.so.1: cannot open shared object file: No such file or directory
<kenvandine> mardy, so in this case you need the old rpath back for tests
<apw> NikTh, that is an ABI handling problem on your side when making your own custom version number
<mardy> kenvandine: right, for the tests that's needed
<SpamapS> cjwatson: indeed, remove away :)
<kenvandine> mardy, so making it a public lib makes adding dev packages less weird
<kenvandine> but, it isn't really useful for other apps
<mardy> kenvandine: that applies to many library, OTOH :-)
<kenvandine> mardy, your call, i don't mind either way
<kenvandine> indeed
<mardy> kenvandine: I'd vote for /usr/lib
<kenvandine> ok
<kenvandine> it is versioned
<kenvandine> so ok :)
<NikTh> apw: Thanks. Do you know the procedure to get over this problem ? I read somewhere that I have to disable the modules dependencies or something like that, but how ?
<kenvandine> mardy, but plugins should still go in PLUGIN_MODULE_DIR
<apw> NikTh, it looks like you have disabled the abi-check but not the modules check
<apw> NikTh, did you add like abi_check=false or something somewhere ?
<NikTh> apw: no. I did nothing except to change the debian/changelog (first line only)
<apw> hmmm.
<NikTh> apw: maybe this will help you to give me a solution (I did not understood what the say.. newbie here. Well I understood but I don't know how to disable modules-check)
<NikTh> apw: https://lists.ubuntu.com/archives/kernel-team/2009-October/007423.html
<mardy> kenvandine: indeed. Check what I pushed
<mardy> kenvandine: seems to work fine here
<geser> cjwatson: could you also do a give-back of libgphoto on armhf in saucy-proposed too please. Looks like heka has several chroot failures lately.
<mardy> kenvandine: I think I delete all the stale stuff, and after a make install it works
<apw> NikTh, i think you added a whole new version stanza at the top of the changelog which means you need to mangle the abi/module data or you need to disable it.  to disable them you would add skipabi=true and skipmodule=true to debian/rules
<kenvandine> ewww... make install is evil :)
<cjwatson> SpamapS: done, thanks
<NikTh> apw: the change at debian/changelog was from 3.8.0-21.32ubuntu1 to 3.8.0-21.32ubuntu1~nikth1 . Nothing else
<cjwatson> geser: done.  the first attempt segfaulted, so let's see ...
<kenvandine> mardy, ok, i'm happy with this
<NikTh> apw: but I will try what you suggested and see.
<apw> NikTh, the ubuntu1 is not in any of our packages, that was added by someone, or perhaps you did dch -i
<kenvandine> give me a few minutes and i'll propose a branch with a few packaging changes
<kenvandine> then we'll get it all merged into trunk
<mardy> kenvandine: excellent!
<NikTh> Yes I did dch -i , but the first line was already 3.8.0-21.32ubuntu1
<apw> dch -i adds the ubuntu1 version before you see the editor, so you did add it, you just don't know you did :)
<NikTh> apw: hahahaha  probably..
<apw> NikTh, it is probabally worth bringing specific kernel issues to #ubuntu-kernel channel where you are more likely to get a kernel expert to notice
<NikTh> apw: If I remove this ubuntu1 will everything build correct ?
<apw> NikTh, nope, it is the act of adding a new version to the changelog which messes up the abi handling, it is using that to determine the previous version and thus where to compare the abi to
<NikTh> apw: no matters, I will try both. (disable modules check and rename the version)
<NikTh> apw: I think I found MY mistake. I have screwed up ABI because I wanted to build 3.8.0-21.32 for raring , but the second line in debian/changelog indicated that this version belongs to raring-proposed
<cjwatson> I doubt that is your problem.
<cjwatson> raring-proposed is basically an incoming queue for raring (pre-release) or raring-updates (post-release).
<NikTh> cjwatson: :-)
<apw> NikTh, your pro
<apw> NikTh, your problem absolutly is that the first version is -21.32u
<NikTh> apw: LoL
<apw> NikTh, your problem absolutly is that the first version is -21.32ubuntu1 etc and the second is -21.32 when the abi thinks its is -19.31
<apw> NikTh, you either need to pull in the right abi information or more sensibly disable the checks
<apw> really, i build a lot of kernels
<tvoss> slangasek, you around?
<kenvandine> mardy, https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/packaging/+merge/164904
<NikTh> apw: This is the thing now. How to pull the right abi info ? Now I have changed the version from 3.8.0-21.32ubuntu1~nikth1  to 3.8.0-19~nikth1 and built this version against raring
<NikTh> apw , cjwatson : But cjwatson doubts that is the problem (raring against raring-proposed where the .21.32ubuntu1 belongs) :P
<apw> NikTh, you wuld need to get the abis for -21.32, and frankly what you are doing is makeing a non-abi compatible version of -21 abi so it make literally no sense to check the ABI
<apw> NikTh, raring and raring-proposed are the same from an upload point of view, they are rewritten to the same thing, and the ABI checker h
<apw> has no interest in the series or pocket
<NikTh> apw : Ok, understood.
<kenvandine> mardy, once you add a .pc file i can test building a plugin out of tree
<seb128_> kenvandine, mardy: oh, nice
<kenvandine> :)
<slangasek> tvoss: hi there
<slangasek> jcastro: what's up?
<jcastro> I am stuck between a rock and a hard place with MAAS: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1109283
<ubottu> Launchpad bug 1109283 in maas (Ubuntu Quantal) "[SRU] maas to Quantal and Precise" [Undecided,Fix committed]
<jcastro> tldr; the maas we're shipping in 12.04 is not working well enough for users
<slangasek> jcastro: right, and for that reason an exceptional SRU has been permitted here... but from what I'm reading of the bug log, the SRU will regress things for users on install?  Why is that not just something that someone is fixing in the maintainer script?
<jcastro> roaksoax: ^^^
<roaksoax> slangasek: it will not regress anything. The doubts that ScottK had were clarified and he was ok with the SRu. What I'm waiting on now is python-celery
<roaksoax> jcastro: the SRU is stuck because of dependencies (python-celery SRU)
<slangasek> ok, then I guess I'm not sure where the rock and hard place are
<slangasek> roaksoax: if the doubts were clarified, it's probably good to get that reflected in the bug status
<cjwatson> If Scott's OK with the SRU, it'd be nice if that were clear from the bug; the last comment is a question from him ...
<roaksoax> slangasek: so i'm just waiting for someone to process python-celery SRU and everything else should fall into place once that gets accepted
<slangasek> because what cjwatson said, and also the bug is still verification-failed
<rbasak> Might it be an idea to keep the whiteboard area updated with current blockers and status?
<roaksoax> cjwatson: yeah we discussed that over the IRC channel and never updated the bug report
<slangasek> ScottK: ^^ are you happy now with bug #1109283 proceeding?  If so, would you mind adding a comment to that affect and clearing the v-failed tag?
<ubottu> bug 1109283 in maas (Ubuntu Quantal) "[SRU] maas to Quantal and Precise" [Undecided,Fix committed] https://launchpad.net/bugs/1109283
<jcastro> slangasek: sorry was on a call, my rock/hardplace is that users are having a hard time getting maas to work
<cjwatson> That's just the rock part, isn't it? :)
<roaksoax> slangasek: so before maas can land we also need this: bug 1177855
<ubottu> bug 1177855 in celery (Ubuntu Precise) "[SRU] Drop Build-Depends on python-sphinxcontrib.issuetracker" [Undecided,New] https://launchpad.net/bugs/1177855
<roaksoax> jcastro: are all the users using precise?
<jcastro> cjwatson: my hard place was being confused as to what exactly is keeping the SRU stuck, which we appear to be resolving now.
<slangasek> ok :)
<mitya57> xnox: I have no clue on what those FTBFS errors mean :(
<jcastro> roaksoax: That's a guess on my part.
<jcastro> But I'm going to go out on a limb and say that the MAAS in LTS for server users should be way awesomer than "yeah well, go use a PPA and then chase down roaksoax in order for it to work, sorry!"
<roaksoax> jcastro: well if they use MAAS from precise and juju from PPA, obviously they are going to have troubles becuase juju from PPA is new upstream releases that might have regress stuff
<xnox> mitya57: btw, retext segfaults in saucy.
<cjwatson> Ah, good, libgphoto2/armhf finally built
<jcastro> roaksoax: I'm working with mgz to provide new juju in -backports
<mitya57> oh :(
 * mitya57 is still on raring
<roaksoax> jcastro: cool. But keep in mind that using juju from PPA will obviously break things if it is not the cobblerless maas
<roaksoax> which is really not MAAS' fault
<roaksoax> so if users were to use juju from precise and maas from precise they should not have any problems
<jcastro> roaksoax: I figure with MAAS SRU'ed and pyju and goju in backports that would be enough
<roaksoax> because we are telling them "use what we support on the LTS, but not juju"
<roaksoax> jcastro: yes the SRU would but not what it currently is in the archives
<jcastro> ok, so basically, worry about the SRU for now, and then we can revisit the juju thing after?
<xnox> mitya57: not sure either. cosmic rays? something funky in saucy-proposed? it did build fine on amd64 here locally in sbuild.....
<mitya57> looks like archive i386/amd64 builds are also going fine
<roaksoax> jcastro: I think juju can still hit backports since I expect the SRU would not take that long anymore now that all of the issues/doubts have been resolved/clarified. It is just queue processing that we really need for the dependencies
<jcastro> ok so is there anything I can do to help?
<jcastro> or is it just a matter of waiting for celery?
<roaksoax> jcastro: it is just matter of having someone to process it, since its been sitting in the queue for a few days now
<jcastro> so it's just a matter of being the squeakiest wheel at this point?
<mitya57> xnox: "btw, retext segfaults in saucy." â are you using stock pyqt or one compiled against qt5?
<xnox> mitya57: possibly =))))
<mitya57> xnox: it can be the problem in QFont constructor I've been mailing about (anyway they are removing qt5 support from pyqt4 now)
<roaksoax> jcastro: Yeah
<Laney> Riddell: You might like to look at https://code.launchpad.net/~timo-jyrinki/ubuntu/raring/qtwebkit-source/raring_231/+merge/160068 which could get you out of qtwebkit-source's current sticky situation
<seb128> kenvandine, looking to u-s-s, we need to stop adding packages with arch: "i386 amd64 armhf" just because qtdeclarative is not available on ppc, that's going to bite us back when e.g adding a new arch like arm64
<barry> slangasek: did you ever open an uber-bug for the EOF and bad marshal data bugs?
<Riddell> Laney: it has a sticky situation?
<barry> bdmurray: ^^
<Laney> being stuck in proposed is quite sticky
<slangasek> barry: no, I assumed we would use the existing bug report
<Laney> due to being FTBFS on 3/4 arches ...
<roaksoax> slangasek: could you also please process http://launchpadlibrarian.net/138209431/maas_1.3%2Bbzr1461%2Bdfsg-0ubuntu3_source.changes for raring and copy it to saucy?
<seb128> cjwatson, Laney, infinity, slangasek: do you have an opinion on how we should handle the arch list for packages using qt5 knowing that qt5 fails to build on powerpc (v8 not supported/qtdeclarative not working there)?
<barry> slangasek, bdmurray: well, there are a lot of them ;)  i'd like to dupe them all the same one for the changelog entries.  any preference on which one to make the master bug?
<cjwatson> seb128: Architecture: any
<Laney> yes, don't arch restrict - let that be handled further up the chain
<seb128> cjwatson, will that not create issues where things ported from qt4 to qt5 and which were available on ppc will depwait and not migrate?
<bdmurray> barry: what is the number of the one assigned to you?
<barry> bdmurray: lp: #1093071
<ubottu> Launchpad bug 1093071 in lsb (Ubuntu) "can't import lsb_release in python3 anymore" [Undecided,Confirmed] https://launchpad.net/bugs/1093071
<kenvandine> seb128, agreed... we have that all over the place now
<barry> bdmurray: but it's not restricted to python3
<seb128> kenvandine, why didn't we use arch: any?
<bdmurray> hmm i thought there was another
<kenvandine> depwait
<kenvandine> and
 * barry looks
<kenvandine> daily releases won't publish
<kenvandine> because it expects ppc to build
<seb128> right
<seb128> it's hard to say if things are depwaiting because they really wait
<seb128> or if they are just stucked on something that will never be there
<seb128> cjwatson, ^ do you have any suggestion how to deal with that?
<barry> bdmurray: nope, i think that's it
<kenvandine> we have a huge list of packages now that specify the list of arches
<seb128> :-(
<seb128> "fun"
<kenvandine> for some insane definition of "fun" :-D
<kenvandine> seb128, so i wonder if when qt replaces v8 with their new thing... maybe it'll build on ppc :)
<seb128> right
<seb128> that's not going to be done/land this cycle though, right?
<kenvandine> i don't think so
<kenvandine> mardy, do you know when that is expected?
<kenvandine> i thought someone said for 5.2
<bdmurray> barry: I'm still looking
<kenvandine> seb128, the worst part of that is we don't really have a way to get a definitive list of packages we've done this for
<seb128> kenvandine, <rdepends qt5> I guess?
<seb128> or qt5declarative
<kenvandine> i guess for saucy we'll be able to do that
<kenvandine> for raring we have stuff spread all over PPAs
<kenvandine> :(
<seb128> well, it doesn't hurt for raring ppas
<kenvandine> indeed
<seb128> I would like to solve it in saucy though
<kenvandine> thankfully we'll be landing it all in saucy
<kenvandine> so rdepends should give us a list
<seb128> we can't just keep pilling packages using "arch: i386 amd64 armhf" to the archive
<kenvandine> seb128, find me another solution :)
<seb128> kenvandine, I'm trying, that's why I started the discussion there
<kenvandine> :-D
<bdmurray> barry: ah bug 1058884
<ubottu> bug 1058884 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with EOFError in /usr/lib/ubuntu-release-upgrader/check-new-release: EOF read where not expected" [Low,Triaged] https://launchpad.net/bugs/1058884
<bdmurray> that's the first one we looked at
<barry> bdmurray: so let's do this.  i'll assign that one to myself and duple all the others that seem related to this one.
<barry> *dupe
<Laney> seb128: What's the problem with daily release stuff? That it'll block because ppc won't build?
<bdmurray> barry: okay, sounds good
<seb128> Laney, right, we don't know how to make the difference between a valid and a buggy depwait
<seb128> "buggy"
<seb128> one that will never unblock
<Laney> care/not care
<seb128> like qt5declarative
<seb128> Laney, "care/not care"?
<seb128> ah
<Laney> None of them are buggy - you're just choosing what to care about
<seb128> well, ideally we would care about depwaits
<seb128> that's why we list all archs but powerpc
<seb128> so it doesn't depwait wrongly
<seb128> "wrongly"
<seb128> the intend is really to say "those are not available on ppc", it feels weird/wrong to achieve that by just letting unresolved depwait status on ppc for those sources
<roaksoax> jcastro: btw.. i have a surprise for you
<Laney> I think it's good documentation to do that
<Laney> and it ensures that whenever the problem gets fixed then you get everything else for free-ish (modulo bugs)
<Laney> so, I don't know what the ideal solution is --- in proposed-migration things are allowed to migrate if they don't regress
<Laney> so it would see that powerpc doesn't exist already and consider that to not be worse than what it had before and let it through
<roaksoax> jcastro: http://www.roaksoax.com/2013/05/getting-started-with-maas-and-juju --> that should provide an overview of how MAAS works, I'll continue to write more blog posts with a quick start
<seb128> Laney, how do you know that the depwait is fine to "skip"?
<seb128> Laney, we might depwait on a new libunity where the depwait shouldn't be skipped
<Laney> it looks at the binaries produced and sees if it got worse than before
<cjwatson> kenvandine,seb128: proposed-migration won't care if an architecture doesn't build as long as it wasn't built previously
<cjwatson> ah, Laney said that
<cjwatson> this really does basically just work
<Laney> so I suppose daily release could do something like that
<seb128> cjwatson, what if it existed before (case for apps doing qt4 -> qt5)
<cjwatson> worst case, we remove those binaries
<seb128> ?
 * didrocks proposed that and seb128 came with the exact same right example :)
<cjwatson> encoding it in Architecture is wrong either way
<seb128> right, we just did it because we didn't find a right solution :/
<seb128> well we did it for a small set as a workaround
<seb128> but it's time we tackle that properly
<kenvandine> small has grown
<Laney> indeed, deleting the binaries can be thought of as documenting the new situation
<Laney> sorry, this thing (intentionally) doesn't work any more
<seb128> didrocks, do you think you could add the "publish even if ppc is depwaiting if the binary never existed" logic?
<didrocks> seb128: can add that to my TODO, but let's target that for next week though
<seb128> didrocks, thanks, I will open a bug
<seb128> kenvandine, ^
<didrocks> seb128: excellent, thanks!
<kenvandine> thanks
<seb128> Laney, cjwatson: thanks for the advices
<didrocks> seb128: hum, there is an issue with bootstrapping though
<didrocks> let's say you create libunity2-dev
<didrocks> this never existed on any arch
<didrocks> so the first arch which published wins?
<didrocks> publishes*
<kenvandine> didrocks, so maybe you should check for a list of required arches?
<didrocks> kenvandine: sounds even more hackish :)
<kenvandine> less hackish than all the packages listing the arches :)
<seb128> cjwatson, Laney: how the proposed -> archive migration works for new packages?
<kenvandine> so you require at least amd64, i386 and armhf
<seb128> that seems wrong and being back to hardcode archs
<didrocks> kenvandine: it would mean we don't care about powerpc, so if we don't care, we should maybe remove it :p
<cjwatson> seb128: it requires at least one binary; any more that come along are migrated separately
<seb128> cjwatson, ok, so they migrate as they build?
<cjwatson> (phone, btw)
<didrocks> so not a nice behavior for daily release, as we don't have this "let's migrate one, then another one and so onâ¦"
<seb128> I guess you can try to detect new packages and force a manual overwrite for first publishing
<seb128> like "if that package isn't in the archive yet, don't publish"
<kenvandine> oh, well there will be a packaging change
<kenvandine> adding the new binary
<kenvandine> so that requires a manual publish anyway
<xnox> mitya57: i hit retry button on armhf/powerpc, in case it's simply run out of disk space / cosmic rays. if they fail again, will escalate for someone to poke those builds harder.
<didrocks> kenvandine: right, but we don't want to say "everything is green" when there was a failure
<kenvandine> yeah
<didrocks> because for ignored everything but the first arch which published
<didrocks> seb128: not sure, it means, everytime you need to go to "next" ppa while one archive is frozen and the next one not opened yet, you need to revalidate all the apps manually to ignore powerpcâ¦
<didrocks> in the present case
<didrocks> I would rather go with kenvandine's idea of "required archs"
<seb128> whatever works for you, as long as we can go back to have "arch: any" in the sources ;-)
<kenvandine> at least then the list of arches is maintained in one place
<mitya57> xnox: thanks
<didrocks> seb128: I shouldn't have listen to you in the first place it seems though, I would have implemented that :p
<kenvandine> and if ppc starts working at some point, we can add that to the required list
<didrocks> kenvandine: yeah
<didrocks> ok, let's do that
<seb128> didrocks, sure, blame it on me :p
<didrocks> seb128: completely! :-)
<kenvandine> seb128, it's always your fault :)
<didrocks> seb128: mind opening a furious bug?
<seb128> didrocks, will do, with french swear words included
<didrocks> seb128: I don't expect less from you :)
<apw> pitti, ok the script i want to modify is a debian extra, so not upstream
<pitti> apw: ah, good; BTW, I have another change to make to systemd (most recent udev upload, which I didn't incorporate yet)
<pitti> apw: how urgent is your change? if it has time until tomorrow, perhaps you can just send me your diff, and I put it into my local packaging git and do that other change tomorrow morning?
<apw> pitti, not at all urgent
<apw> pitti, i'll add a debdiff to the bug and point you at it; once i have some testing in
<pitti> apw: splendid, thanks
<jamespage> pitti, core pattern looks OK on builds - https://launchpadlibrarian.net/140395622/buildlog_ubuntu-saucy-amd64.libunwind_1.1-1ubuntu1_UPLOADING.txt.gz
<pitti> jamespage: ah, good; so it's something in schroot which disallows ulimit ?
<jamespage> pitti, it restricts ulimit; but the core_pattern from the host appears to stop it dumping a core file to the local directory
<jamespage> at least thats the behaviour I see
<jamespage> ulimit -c 10000 was OK
<mnaumann> hi, could a patch pilot please review the patch discussed at https://bugzilla.xfce.org/show_bug.cgi?id=9709#c29 and https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1104435 and upload the patch to saucy, or package upstream 4.10.1 (saucy currently has 4.10.0) which fixes this?
<ubottu> bugzilla.xfce.org bug 9709 in General "periodic crashes of xfce4-session" [Normal,New]
<ubottu> Launchpad bug 1104435 in xfce4-session (Ubuntu Saucy) "xfce4-session crashed with SIGSEGV in g_slice_alloc()" [High,Triaged]
<mnaumann> (that's according to the chanelog at http://git.xfce.org/xfce/xfce4-session/tag/?id=xfce4-session-4.10.1 )
<tvoss> ricmm, ping
<ricmm> tvoss: pong
<cjwatson> seb128,didrocks: For daily releases, you could do exactly the same thing proposed-migration does: that is, copy once some minimal set of architectures builds (you might want that to be i386 amd64 armhf, rather than p-m's "any one") and once you have at least as many architectures as before, and you can just re-copy the same version if another architecture arrives later
<didrocks> cjwatson: yeah, not sure about the recopy, but first step, I'll do as you tell. Thanks! :)
<infinity> s/at least as many/the same list of/
<cjwatson> Er.  Why?  Having more isn't an error.
<cjwatson> Oh, sorry.  I meant >= in the set sense
<Laney> a superset of
<infinity> didrocks: The recopy is important, in case a new arch starts working that didn't before.
<cjwatson> And translated that wrongly into English :-)
<cjwatson> Apparently my brain thinks of these things in set notation or something.
<infinity> cjwatson: Sure, and I translated the math wrong too, should have been "the same list or better". :)
<infinity> (Or, as Laney said, the same list or a superset)
<didrocks> infinity: hum, if we make the binary copy and it's available in -proposed, it will certainly rebuild there if it's possible, right?
<cjwatson> And the problem with saying "superset" is you need to clarify that you mean that to include the trivial superset (identity).
<cjwatson> Ah, didrocks has a point there
<infinity> True, yeah.
<Laney> I was going to say something about strictness but gave up caring :P
<infinity> The beautiful thing about English is that you don't need precision, you just need a bunch of nodding heads that appear to all understand WTF you meant. :P
 * infinity still prefers math.
 * Laney writes an Agda program to express precisely what we mean here
<mnaumann> Laney: may i bug you about reviewing the patch discussed at https://bugzilla.xfce.org/show_bug.cgi?id=9709#c29 and https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1104435 and upload the patch to saucy, or package upstream 4.10.1 (saucy currently has 4.10.0) which fixes this?
<ubottu> bugzilla.xfce.org bug 9709 in General "periodic crashes of xfce4-session" [Normal,New]
<ubottu> Launchpad bug 1104435 in xfce4-session (Ubuntu Saucy) "xfce4-session crashed with SIGSEGV in g_slice_alloc()" [High,Triaged]
<Laney> mnaumann: You may, but have you tried bugging the Xubuntu developers (#xubuntu-devel) first?
<Laney> xfce4-session certainly has other problems that I'm aware of that are fixed by .1 (logind)
<seb128> Laney, find the bug I mentioned earlier back, bug #1181565
<ubottu> bug 1181565 in casper (Ubuntu) "wrong permissions on $HOME/.local/ on live session" [Undecided,New] https://launchpad.net/bugs/1181565
<mnaumann> Laney: have not, will do.
<xnox> Laney: mnaumann: I just uploaded that into saucy.
<mnaumann> oh thanks xnox
<Laney> thanks
<xnox> mnaumann: for raring though, it needs bug-report description to be adjusted to match https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<xnox> mnaumann: i presume you do want it as raring SRU.
<Laney> the upstream update should definitely be done quite soon though, assuming you didn't mean that you did that
 * xnox polishes the xubuntu-fake-dev badge on my profile.
<xnox> Laney: correct. All i did was upload into raring. The patch made sense to me anyway =)
<Laney> saucy
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<Laney> seb128: interesting. I suppose it could be the same thing if nothing else creates ~/.local
<seb128> Laney, I confirm, I just tested with a test user
<seb128> $ ls .local/ -l
<seb128> total 4
<seb128> drwx------ 3 ubuntu ubuntu 4096 mai   21 18:20 share
<ubottu> Ubuntu bug 4096 in meld (Ubuntu) "meld: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/4096
<seb128> Laney, after running g-s-d
<seb128> I guess it's just using the permission of the mkdir
<seb128> the mkdir for .local/share/sounds I mean
<Laney> that should be fixed now
<Laney> but it is g_whatever_with_parents, yeah
<Laney> hrm
<seb128> Laney, I'm trying https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=7f4af9ab7824c0479e3f4e77742042949b6d32da
<Laney> someone ... didn't ... add both patches to series
 * Laney runs
<seb128> lol
<seb128> I've been that someone in the past :p
<seb128> Laney, no, it seems to be fine
<seb128> you updated the patch that was there and added yours
<Laney> oh no, it wasn't a new patch
<Laney> yeah, phew
<seb128> Laney, I'm testing that commit I just pointed
<Laney> ok
<timholum> Hello, I am looking at intigrating my webapp into unity ( Like gmail, google drive and launchpad do ) Is there a tutorial on how to do that?
<seb128> Laney, hum, in fact I wonder if that bug is not already fixed
<seb128> Laney, the directory is 700 for me, that should be fine, no reason for the outside users to have access to ~/.local
<mitya57> seb128, Mirv: Please get an ack from ScottK before re-adding the appmenu patchâ¦
<Laney> seb128: it gets 0700 for me in a guest session
<Laney> let me boot an iso
<seb128> mitya57, why?
<seb128> mitya57, you recommend that we break something in the distro that is working just for the sake of dropping a patch which cause no problem?
<Logan_> pitti: Are you around?
<seb128> Logan_, hey, it might be a bit after his core hours, he starts early, you better leave your question directly so he can read it/reply later
<mitya57> seb128: if you add it back, there will be less interest in implementing it the right way
<seb128> mitya57, you don't create interest by breaking Ubuntu...
<Logan_> seb128: Kk, I'll message him.
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> will do some more tomorrow, got distracted
<mitya57> seb128: I'm fine with it if it'll be fixed later this cycle, I just wanted to make sure ScottK knows about your plans
<Laney> seb128: looks fine for me on today's daily too, probably was the same bug
<seb128> Laney, thanks for confirming
<seb128> Laney, oh, you forgot to push your release commit to g-s-d I think
<Laney> sure did, done now
<seb128> thanks
<pitti> Logan_: back
<pitti> seb128: oui, c'Ã©tait l'heure du glace :)
<seb128> pitti, ;-)
<Logan_> pitti: I sent you a message on Google Hangouts (embracing the future!), but Apport did something weird with my crash report here: https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/1181540
<ubottu> Error: launchpad bug 1181540 not found
<Logan_> It appeared to just remove the needs-amd64-retrace tag.
<pitti> Logan_: I don't see a message from you
<Logan_> Odd.
<Logan_> I sent it to your personal Google+, not the Canonical one, if that helps. :P
<pitti> Logan_: so the apport retracing service just removed the tag?
<Logan_> Yes.
 * pitti checks log files
<pitti> indeed, very strange
<pitti> no output at all
<pitti> Logan_: I have a list of affected bugs; I'll re-tag them and watch it
<Logan_> kk
<Logan_> Thanks!
<seb128> pitti, stop feeding the bot with icecreams, it starts being lazy
<seb128> ;-)
<pitti> lol
<pitti> Logan_: would you mind making it public? that would make things a tad easier for me
<Logan_> Sure.
<Logan_> pitti: lol, it just removed it again...
<rickspencer3> hey pgraner, gema, pitti, etc... nice to see so much green on the saucy smoke tests :)
<rickspencer3> http://reports.qa.ubuntu.com/
<apw> infinity, yo ... do you know if the Kernel-Version: and Package-Type: fields will be recognised correctly in ubuntu
<infinity> apw: Package-Type is in dpkg-dev going back to 1.15.7, I'm not sure what Kernel-Version is all about.
<apw> infinity, well kernel-wedge (which i am merging from debian) has just dropped the XB- and XC- prefixes from them
<apw> i assume this implies they have moved from 'extensions' to real entries, but i am not so sure who consumes them to be sure that we have the said changes
<infinity> apw: Kernel-Version should be safe, from what I'm seeing in a glance at dpkg code.
<apw> infinity, ok so according to the bug which removed them dpkg-dev since 2007 has them, so i assume we are good there
 * apw calls it good
<pitti> Logan_: yes, I know; retracing notify-osd is broken ATM, it cannot find the executable path; I'll investigate tomorrow morning
<Logan_> kk
 * pitti waves good night
<Logan_> Good night!
<seb128> pitti, night
<infinity> apw: Do we build kernel sources on saucy that then get uploaded to lucid?
<infinity> apw: The Package-Type thing could cause some weird issues on dpkg-dev << 1.15.7, and lucid is 1.15.5.6
<infinity> apw: Other than that corner case, I see no potential issues here.
<pgraner> rickspencer3, :)
<apw> infinity, well i think we should be building the relevant sources packages on the same release we are uploading, right
<infinity> apw: Ideally, yes, but I suspect that might not always be true. ;)
<infinity> apw: Oh, except you re-run kernel-wedge in your clean target, don't you?  So, even if it's "wrong" in the source package, it'll get unwronged before build.
<apw> infinity, ok so this would only be uploaded as far back as precise, but there is a risk that people would build real lucid wrong
<apw> infinity, right it is only wrong in what is used at source package build time, in a real build we re-re-build it to make it arch specific
<apw> infinity, so that sounds like we are good to go
<infinity> apw: Kay, then it should probably all be fine anyway.
<apw> infinity, thanks for the sanity check
<infinity> apw: (Though it's also true that, in theory, the lucid source packages should be generated in a lucid chroot, I just suspect that's not always the case)
<apw> infinity, i know that to not always be the case :(, though i have just at sprint supprised people by reminding them it was true
<rbasak> infinity: oops, forgot to poke you about facter. Too late? I'm EOD now :-/
<infinity> rbasak: I can give it a review in a bit.  If it needs fixing before I sponsor, I'll either JFDI and let you know what I did, or email you for a back-and-forth.
<rbasak> infinity: thanks!
<infinity> rbasak: Or stay connected to IRC so I can spew running commentary to you while you sleep. :P
<rbasak> Sure. I'll see it in my awaylog in the morning.
<rbasak> (not bedtime yet - but I'm out this evening)
<infinity> apw: Well, 99% of the time, where you generate your source package doesn't matter.  It's just weird cases like this where it comes up.
<apw> infinity, yeah but as a 'rule' it is a good one
<infinity> apw: Or the "apt is silly" case, where generating the source package reruns autotools, so you want to keep similar versions to minimize the diff.
<apw> yeah
<YokoZar> Has phase 2 of https://wiki.ubuntu.com/MultiarchCross  begun yet?  Will I be able to start multi-arching build-deps in Saucy?
<infinity> YokoZar: I'm not sure you're reading that right.
<infinity> YokoZar: Assuming you mean "can I build-dep on foo:i386 on an amd64 build", that's not what that's talking about, and no, you can't.
<YokoZar> infinity: Err maybe.  I'm more keen on being able to build 32 bit wine on amd64 without needed a chroot
<infinity> YokoZar: Should I introduce you to sbuild? :)
<infinity> (Which, yes, uses chroots, but building in your base system is silly anyway)
<YokoZar> infinity: I'm not sure I can convince upstream devs to build actual packaged wine -- the most common dev workflow is to build wine (for both 32 and 64 bit) simultaneously and then run it within the build tree.
<dobey> i just wish arch: all packages could be built on any arch, rather than only i386, on the buildds :)
<dobey> YokoZar: if they're not building packages, what does it matter what Build-Depends can or can't do?
<infinity> dobey: That's a different problem, and I need to sort out a finished proposal and implementation for that.
<dobey> infinity: i know. i just figured i'd take the opportunity to moan about an actual issue :)
<dobey> also. man does it take forever for packages to get built, in my non-work-related PPAs :)
<YokoZar> dobey: it's more about the coinstallability of -dev packages
<infinity> YokoZar: Oh, see, I was trying to sort out what you were driving at.
<infinity> YokoZar: Multiarching -dev packages is entirely supported today, if you so feel the urge.  The toolchain will find the headers in the right spots.
<infinity> YokoZar: But (and this is a big but), if you're moving headers around, beware that rdeps may suffer due to effin' stupid configure checks that look at absolute paths instead of asking the compiler about include locations.
<infinity> YokoZar: So, a full rdep rebuild test is in order if you multiarch a -dev package that's not a leaf.
<dobey> oh. hrmm
<dobey> maybe i should fix some things to add the arch host to --includedir
<infinity> (See the hideous pain we went through with multiarch python headers)
<infinity> dobey: Or just ask the compiler, full stop.
<YokoZar> infinity: Interestingly I suppose I can do the leaf packages first then, unlike with the original multiarch transition where we had to go in the opposite direction.
<infinity> dobey: Listing every possible header location on Linux (+ multiarch), Solaris, HP-UX, etc, is silly.  And /usr/local, and, and...
<dobey> infinity: listing them ehwere?
<dobey> where
<infinity> dobey: As in, configure scripts that test -f {/usr/include,/usr/local/include,etc,etc}myheader.h instead of doing a compile-test with "#include <myheader.h>" and seeing if it's found.
<infinity> dobey: The former is all too common, but the latter is correct, and requires no changes if headers move, so long as the compiler can still find them.
<dobey> infinity: oh no. i wouldn't do that. i meant i should change the packages i maintain that install headers, to add --includedir=/usr/include/${DEB_MULTIARCH_HOST}/ to the configure arguments (or do something similarly appropriate for cmake, etcâ¦)
<dobey> in debian/rules
<infinity> dobey: Ahh, yes.  It gets more fun than that, if you want to minimize bloat.
<infinity> dobey: If your headers aren't arch-specific, it's *correct* to have them in /usr/include, and the ones that differ should be in /usr/include/<triplet>
<dobey> infinity: and file conflicts between :i386 and :amd64 are so much fun :)
<infinity> dobey: Packages that have had to care about this sort of thing since long before multiarch (ie: glibc) already mostly get this right, but most libraries just dump the world in $includedir, so splitting it is an exercise in fun.
<infinity> dobey: If the files are identical, they don't conflict, that's the point.
<infinity> dobey: Multiarch is special that way.
<infinity> dobey: So, it's also true that if you have no arch-specific headers at all, you can just make your -dev package M-A:same and you're done.
<dobey> ok
<dobey> then i probably just need to do that
<infinity> dobey: Err, assuming you're installing other arch-specific stuff (like the .a) to a sane location, of course.
<dobey> right
<dobey> i also need to go through and add a bunch of dep8 tests to stuff; but haven't had time to do so yet :(
<infinity> dobey: Of course, you may have arch-specific headers and not realise it if you're using autotool substitutions for endianness or wordsize macros, etc.
<infinity> dobey: But simple enough to grab, say, an amd64 and powerpc binary and unpack them and diff /usr/include/*
<roaksoax> slangasek: it seems that celery is still in the unapproved queue: https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
<YokoZar> should apt-get build-dep foo:i386 do something under m-a: cross?
<roaksoax> slangasek: thanks if you just got it accepted :)!
<slangasek> roaksoax: yeah, that was me
<slangasek> roaksoax: sorry, don't know why it didn't take the first time
<roaksoax> slangasek: no worries :). Thanks though :)
<slangasek> roaksoax: as for maas in raring-proposed: I'll take a look at it, but we are past the window where it's ok to rely on pocket copies of SRUs into the development series; please reupload to saucy separately
<YokoZar> Oh I see the intended syntax is apt-get --arch=i386 build-dep foo    instead of apt-get build-dep foo:i386
<roaksoax> slangasek: yeah i wanted it to be a 0-day sru but never got processed unfortunately. Will do
<roaksoax> thanks
<roaksoax> slangasek: however, if you prefer it so, I could re-upload to raring with the correct versioning as well.
<slangasek> roaksoax: I don't mind having a "wrong" version for the SRU and you just incrementing to the next one for saucy
<roaksoax> slangasek: sure that works for me then! thanks!
<roaksoax> slangasek: hold on, now that I give a second thought, I want to include another minor fix so I won't have a SRU antoher time
<roaksoax> slangasek: please reject it and will shortly upload a new version
<slangasek> ok
<roaksoax> slangasek: thank you!
<Noskcaj> kirkland, ping
<kirkland> Noskcaj: hi
<Noskcaj> kirkland, yay, he responds.
<Noskcaj> kirkland, have you got a time for a testdrive hackfest yet?
<kirkland> Noskcaj: right now?  no
<Noskcaj> kirkland, ok, please let me know when you or andres have time to do one.
<kirkland> Noskcaj: okay
<kirkland> Noskcaj: what are you hoping to accomplish in said hackfest?
<Noskcaj> kirkland, get someone else admin status, learn a lott more of the code, try and get aas many people as possible helping. the hackfests were very effective with autopilot last series
<Noskcaj> and to get parallels out, which would make my classroom session a lot easier
<shankstaBytes> if I run make install will that overwrite my package of the same program that is install?
<cjwatson> That depends on the Makefile.
<cjwatson> They often default to some other prefix (e.g. /usr/local), but there's nothing I can say here that will apply to all programs.
<shankstaBytes> cjwatson: i see
#ubuntu-devel 2013-05-22
<ScottK> Mirv: It should not go back in.  That was the agreement.
<dantti> stgraber: hi, I've been told you could maybe give me a hand, grub2 isn't booting W7 it boots kubuntu fine then I installed Ubuntu and still no lucky, the boot-repair tool from what I can tell installed grub1 which then managed to boot Windows but not ubuntu.. the error message is around the web but nobody did have a real fix other than I reinstalled everything and now it works:/
<dantti> and the error is that it says Invalid EFI path when windows is choosen
<balloons> so a nice evening random question for anyone who might be about :-) If I want a stupid simple key-value store, is there any reason to look beyond berkeleydb?
<ScottK> Depends on how much you care about Oracle being the steward of the open source project you're going to depend on.
<psusi> dantti, sounds like an existing bug report about grub2 not generating the correct chainloader path on efi systems... i.e. it still tries to do chainloader +1
<balloons> ScottK, indeed.. is there an alternative?
<dantti> psusi: yes, that's right it is +1
<ScottK> I hadn't really thought much about it.
<ScottK> I'd just suggest that as a reason to perhaps look beyond it.
<dantti> psusi: I tried to change this to sth like boot/efi/microsoft... but didn work (tho I dunno if the path was correct)
<psusi> dantti, yea, there's a bug report for that
<balloons> ScottK, :-) thanks
<dantti> psusi: do you know if there is a workaround? like putting the right path?
<psusi> dantti, yea, put the right path ;)
<dantti> psusi: ok, I'll try some variants of the path here :) thanks
<infinity> ScottK: I'm not deeply concerned about Orable messing up BDB, to be fair.
<infinity> ScottK: Or Oracle. :P
<ScottK> I think so far they haven't, but looking at the trends in mysql and java, I'm not sure how much one should assume that will continue.
<ScottK> In other news, I figured out why sip4 didn't migrate and fixed it.
<infinity> ScottK: Wildly different projects.  MySQL already had the dual-license model, Java already had completely closed IP, BDB is, on the other hand, one of the freest of the free.
<infinity> ScottK: If they try to mess up BDB in any meaningful fashion we'll all just fork and they can eff off, but it wouldn't be painful like the MySQL/Maria business.
<ScottK> Right.
<ScottK> Is LP running slow on updating from Debian?  There's a package that was accepted in Debian over 24 hours ago that I still can't sync via LP.
<infinity> ScottK: I believe zumbi broke our imports.
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709118
<ubottu> Debian bug 709118 in src:gdb "gdb: truncated Maintainer field" [Serious,Fixed]
<infinity> Though, I think wgrant was going to blacklist that gdb version and make it all go again.
<wgrant> Yes, getting there :)
<wgrant> mipsel of -2 failed to build
<ScottK> Nice.
<infinity> So did mips.
<wgrant> So -1 is going to stick around blocking gina for a while
<wgrant> infinity: mips failed on -1 too
<ScottK> OK, now I don't feel guilty for manually syncing pyqwt5 so sip4 could migrate.
<wgrant> It's only mipsel that's regressed from -1 to -2
<ScottK> The other package I'm waiting for though is no rush.
<wgrant> It'll hopefully be working again tonight
<ScottK> Tonight where?
<wgrant> Here :)
<wgrant> So next <12 hours
<ScottK> "Lunchtime"
<pitti> Good morning
<GunnarHj> slangasek: ping?
<slangasek> GunnarHj: hi
<GunnarHj> slangasek: Hi, Steve! What about the other tasks at bug 1155327? Are they possibly invalid now?
<ubottu> bug 1155327 in nvidia-graphics-drivers-304 (Ubuntu Raring) "skype crashed with SIGSEGV in malloc@plt()" [High,Confirmed] https://launchpad.net/bugs/1155327
<slangasek> GunnarHj: oh... probably
<slangasek> (closed them out now)
<slangasek> or rather, would have if LP hadn't timed out
<GunnarHj> slangasek: Ok, you are fast today. :)
<GunnarHj> slangasek: I removed the GLib upstream task as well, so now the whole bug report is history.
<pitti> ev: FYI, I just fixed apport (-retrace) to actually be able to map files for the target release; before, it was always using Contents.gz for the host release, which led to bad retraces
<pitti> ev: so it would be good if you could update apport to current trunk, and apply http://bazaar.launchpad.net/~ubuntu-archive/apport/lp-retracer-config/revision/7 to your retracer config
<dholbach> good morning
<mlankhorst> slangasek: ping?
<mardy> cyphermox: hi! Could you please have a look at this whenever you got a spare minute? https://code.launchpad.net/~mardy/qmenumodel/root-index/+merge/164705
<tjaalton> I need an advocate for the debian NM process.. volunteers? :) (I'm a DM already)
<Noskcaj> could someone look at http://launchpad.net/bugs/1172015 . i'm starting to think someone hates sydney
<ubottu> Launchpad bug 1172015 in ubiquity (Ubuntu) "Sydney timezone is in the wrong location" [Undecided,Confirmed]
<Mirv> ScottK: I know (appmenu). There's a dispute, not sure how it could be resolved. I quoted the FFe bug text, but I was asked to push it anyhow. For my part I'm neutral, I understand the agreement and also understand the wish to not have regressions (but then why have an agreement in the first place). The QPA plugin is still under work, and there's now a blueprint for it https://blueprints.launchpad.net/appmenu-qt/+spec/qt5-qpa-appmenu
<Mirv> hopefully it will get completed soon and the patch dropped for good
<Mirv> the patch does not do other harm but potentially give a wrong impression of a problem solved, while it's not yet
<seb128> ScottK, Mirv: I don't have the backlog but I discussed it with didrocks and it doesn't make sense to us to break Ubuntu "just to drop a patch that's not creating any issue", knowing that a proper solution is being worked and that we will drop the patch this cycle anyway
<tvoss> didrocks, ping
<didrocks> seb128: +1
<didrocks> tvoss: pong
<Mirv> seb128: yes. it should have been rised during the FFe approval discussion to disagree with the saucy plan. that's the only problem.
<seb128> ok
<Mirv> so not optimal, but here we are
<seb128> right
<seb128> I also though we would have the QPA by now, but as said, as long as that's happening there is no reason to drop the patch in that upload and break Ubuntu
<didrocks> yeah, Qt5 is not really used in saucy, and the patch doesn't break anything, so as long as the replacement isn't ready, I don't see why we will break saucy for the sake of breaking it
<didrocks> then, once touch is in saucy, we can resume the QPA work
<didrocks> and have something clean
<didrocks> (help from the kubuntu team is welcomed of course)
<rbasak> doko: have you seen bug 1182613?
<ubottu> bug 1182613 in puppet (Ubuntu) "puppet completely broken on saucy" [Undecided,New] https://launchpad.net/bugs/1182613
<ttx> rbasak: oops.
<rbasak> dep8 tests FTW
<ttx> rbasak: rolling distros are hard, when you only test 1% of your functionality ;)*
 * rbasak is waiting on review for a facter merge which adds one for the same issue
<ttx> it's much easier for upstreams than for distros.
<jamespage> rbasak, does puppet support ruby 1.9 at all?
<rbasak> jamespage: http://docs.puppetlabs.com/guides/platforms.html#ruby-versions
<rbasak> jamespage: for 3.x, looks like 1.8.7 and 1.9.3 only
<rbasak> "To the best of our knowledge, these issues were fixed in the second public release of Ruby 1.9.3 (p125), and we are positive they are resolved in p392 (which ships with Fedora 18). Unfortunately, Ubuntu Precise ships with p0 for some reason, and thereâs not a lot we can do about it. If youâre using Precise, we recommend using Puppet Enterprise or installing a third-party Ruby package."
<mitya57> xnox: did you "escalate for someone to poke those builds harder" or should I do that?
<xnox> mitya57: well, the second rebuild failed as well. I've been recommended by myself to poke it harder myself on my pandaboard.
<xnox> mitya57: briefly discussed on #ubuntu-release last night.
 * mitya57 reads the log
<mitya57> that was a very brief discussion :)
<mitya57> I don
<mitya57> I don't have a pandaboard, but if someone gives an armhf-enabled ppa to me, I could try to debug this
<geser> mitya57: https://dev.launchpad.net/CommunityARMBuilds
<pitti> rsalveti: hey Ricardo! Can you please forward http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/udev/saucy/revision/237 to upstream? (bugzilla or systemd-devel@lists.freedesktop.org)
<pitti> apw: I'm about to do a systemd upload; should I still wait a bit to include the fix for bug 1100386, or do you reckon that this will take longer?
<ubottu> bug 1100386 in udev (Ubuntu Raring) "Server installations on VMs fail to reboot after the installations" [High,In progress] https://launchpad.net/bugs/1100386
<xnox> ScottK: $ syncpackage --force cmake ;-))))))
<apw> pitti, yeah i have that here ... give me 5m, i am struggling with unity, it has lost half my windows
<xnox> apw: stop using Windows =)
<apw> xnox, heh ... even restarting it is not sorting its head out, dammit
<NikTh> Hey all
<NikTh> anybody here ? apw , cjwatson  , infinity  ?
<NikTh> How to overcome this error ? => https://launchpadlibrarian.net/140439152/buildlog_ubuntu-raring-i386.linux_3.8.0-21.32ubuntu1~nikth2_FAILEDTOBUILD.txt.gz
<apw> pitti, ok ... finally got unity sorted (logout time) and I have attached the diff to the bug: bug #1100386 (for systemd)
<ubottu> bug 1100386 in udev (Ubuntu Raring) "Server installations on VMs fail to reboot after the installations" [High,In progress] https://launchpad.net/bugs/1100386
<apw> NikTh, you are better off coming over to #ubuntu-kernel for these kernel related build issues
<NikTh> apw: Thanks
<apw> NikTh, ping me when you get there
<pitti> apw: great, thanks! (and no hurry, if you need more time then take it)
<apw> pitti, that one should be good to go, tested and the like, though i did mod the changelog to get the bug number right :)
<pitti> apw: ack, thanks; uploading now
<apw> pitti, ta
<mitya57> geser: Qt takes more than 4 hours to build on armhf (i.e. the 4:4.8.4+dfsg-0ubuntu9 build took 13 hours, 28 minutes, 34.2 seconds)
<mitya57> (sorry for not noticing your message earlier, I was not online)
<vassie> hello, not sure if this is the correct channel to ask but i packaged an app for raring, i have packaged a new version of it and uploaded to my ppa, i'm not sure what i need to do now
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<ScottK> xnox: No.  There's one Ubuntu change left.
<pitti> yolanda: did you see the postfix autopkgtest failure on i386? that looks curious, is that a bug in python itself?
<ScottK> seb128: I approved an FFe based on an agreement.  If people didn't want to follow the agreement, then that was the time to discuss it.  I can't stop anyone from uploading whatever they want, but I can learn the lesson to never, ever agree to such an FFe again.  What's the date when the patch can be dropped?
<yolanda> pitti, no, i didn't see it, can you point me at it?
<seb128> ScottK, "when the qpa is ready"
<seb128> ScottK, it doesn't make sense to advocate for runtime regressions for users just for the sake of dropping a patch which is creating no issue...
<ScottK> i.e. maybe never  and who cares what we agreed.
<pitti> yolanda: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-postfix/1/ARCH=i386,label=adt/
<seb128> ScottK, well, I do care about fixing it properly, but I don't see the point to break users for the sake of making a point
<ScottK> OK.  That's why I asked for when.
<ScottK> I didn't say I'd try to stop you adding it back.
<seb128> good, sorry that the qpa thing is not ready yet
<yolanda> pitti, let me test them locally again
<xnox> ScottK: hm?!
<ScottK> I think keeping our patches in Qt5 to a minimum and not having them devolve into a unmaintainable mess is an important goal and it has to start now.
<yolanda> i haven't seen that error before
<seb128> ScottK, agreed
<xnox> ScottK: after last merge by Riddell, there were two patches left, both are in Debian and filed upstream.
<pitti> RAOF: do you plan to package colord 1.0 soon? if so, any chance you can import upstream commit 4c6792 to drop the g_type_init() calls, and add a valgrind test dependency? that's the two issues I see on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/
<ScottK> seb128: I do, however, consider this going back on an agreement and I'll of course consider that when reviewing FFes in the future.
<ScottK> xnox: OK.  I knew about one being in Debian.  I didn't check the other.
<seb128> ScottK, hum, that's fair enough, I don't think the request made by then was appropriate (e.g "let's accept it but add a clause that we will regress it early next cycle for no good reason if the new work is not ready yet") but that one is done so no point to discuss it now
<ScottK> Then was the time to discuss it, not now.
<ScottK> I would be less grumpy about the situation if there was a date beyond "when ready" for dropping this Qt4 forward port.
<seb128> well, the guys are working on the QPA support but that's not the only thing they have to work on, and I've no idea how much work that is
<seb128> I just know it's being tracked but it's not trivial enough to say "it will be squeezed in an afternoon next week"
<seb128> e.g it's going to take some extra time
<ScottK> Could you ask for an estimate?
 * cjwatson curses at build systems that don't fail immediately
<yolanda> pitti, i tested with saucy - amd64 and works locally, let me test with i386
<pitti> yolanda: yes, it succeeds on amd64 in jenkins, too
<seb128> ScottK, ok, I will try to get one
<mitya57> xnox: no, there is also disable_overlay_scrollbars.diff which is not in Debian/upstream
<mitya57> it is of course an ubuntu-specific hack, and I don't know if there is another way to fix the issue (see i.e. bug 1170384)
<ubottu> bug 1170384 in qtbase-opensource-src (Ubuntu) "[sna] Xorg crashed with SIGABRT in memcpy_blt() - <Address 0xb8070f48 out of bounds> when using ReText with Qt5" [High,In progress] https://launchpad.net/bugs/1170384
<xnox> mitya57: are we talking about the same thing? I was discussing cmake package with scottk.
<xnox> mitya57: btw. I could give you ssh access to a panda board if you want to poke qt4-x11.
<xnox> pm if you are interested.
<mitya57> xnox: I was talking about:
<mitya57> <ScottK> I think keeping our patches in Qt5 to a minimum and not having them devolve into a unmaintainable mess is an important goal and it has to start now.
<mitya57> xnox: not today (I hope it's not urgent)
<xnox> ScottK: ^, not me then =) I'm not involved in Qt5 packaging much.
<xnox> mitya57: nah. I'll get around to it eventually.
<mitya57> xnox: btw, do you have any plans to package pyqt5 or do you want me to do that? :))
<xnox> mitya57: i haven't tried it since before they published qt5 preview snapshot.
<xnox> i think i did push my latest trial somewhere to launchpad.
<mitya57> xnox: ok, I'll look at it next week and let you know if I get any success
<mitya57> pitti: fyi, I have dep-8 fixes for docutils and pandas in the sponsoring queue
<pitti> mitya57: ah, splendid, thanks
<mitya57> (pandas is not yet failing on jenkins, but it doesn't work with the latest nose)
<seb128> there is a good stack of tests work in the sponsoring queue
<seb128> we need a patch pilot round from somebody from qa :p
<seb128> there are like 10 of those waiting
<yolanda> pitti, fails for me locally on i386 also
<pitti> mitya57: ah, you fixed it in Debian and merged? awesome
<pitti> seb128: yeah, I sponsor quite a lot of them (but mostly just if someone pokes me outside of my patch pilot days)
 * pitti looks at these two
<seb128> pitti, you are piloting next monday I see ;-)
<mitya57> pitti: if you speak about nose, then I broke it, not fixed :)
<pitti> mitya57: I meant docutils
<mitya57> pitti: jwilk fixed that
<pitti> +XS-Testsuite: autopkgtest
<pitti> mitya57: ^ FYI, this is perfectly fine for Debian
<pitti> it's part of the DEP8 spec
<pitti> mitya57: and dropping pysupport in Debian will certainly get you applauds from doko, too :)
<pitti> mitya57: what is debian/x-rst.xml? (that's not mentioned in the remaining delta)
<mitya57> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=685509
<yolanda> pitti, it fails in that regular expression, but looks good to me? child.expect(r'.*[pP]assword', timeout=5)
<pitti> yolanda: yeah, hence my suspicion of "bug in python"
<pitti> it said "internal error in regex machine" or so
<mitya57> pitti: oops, x-rst.xml is an old version of docutils.xml, will now remove it
<yolanda> oh yes: RuntimeError: internal error in regular expression engine
<yolanda> all the failures are the same
<pitti> mitya57: no worries, I can just remove it in the merge
<mitya57> pitti: already removed it, and fixed the version number
 * pitti pulls again
<pitti> mitya57: forgot to push?
<mitya57> pitti: no, pushed
<mitya57> pitti: looks like mdeslaur just uploaded pandas fix
<pitti> heh, me too
<mitya57> (thanks!)
<pitti> so I guess mdeslaur's will win :)
<mdeslaur> oops :)
<pitti> mitya57: anyway, thank you! (also uploaded docutils)
<pitti> mdeslaur: sorry
<mitya57> pitti: thanks
<yolanda> pitti, so what we do with that isuse?
<cjwatson> Riddell: Was kdegames-data going away intentional?  Looks like that needs some transition work in saucy-proposed.
<pitti> yolanda: I suppose as a first step you should report a bug against python3.3; then, maybe you can find a workaround by slightly altering the RE
<cjwatson>   ** gcc version 4.8 found, expected gcc 3.x with x>1 or gcc 4.x with 0<x<8!
<cjwatson> seriously, virtualbox?
<cjwatson> debfx: ^- you might like to have a look at that
<Riddell> cjwatson: mm not sure, will look into it thanks
<cjwatson> infinity: I synced libnss-db, although you're touched-it-last; I'm pretty sure that Julien's and my QA uploads cover everything we need between them, but feel free to double-check.
<Mirv> cjwatson: can you comment on keeping or ditching Architecture line delta to Debian related to powerpc builds? you were mentioned here: http://pastebin.ubuntu.com/5690298/ - we're planning to do uploads/syncs tomorrow
<cjwatson> Mirv: please see the discussion in this channel yesterday
<Mirv> cjwatson: ok, scrolling back
<cjwatson> But I'll address one thing to make sure it sticks: the assertions that proposed-migration prevents migration of packages with FTBFSes is false.  It prevents migration of packages with regressions in the set of builds that worked.
<cjwatson> s/is false/are false/.
 * cjwatson peers at the sweep package.  So much ugliness that could just be dh_autoreconf
<Mirv> cjwatson: thanks, read the discussion
<seb128> Mirv, I opened https://bugs.launchpad.net/cupstream2distro/+bug/1182570 on the daily landing tools
<ubottu> Launchpad bug 1182570 in Canonical Upstream To Distro "Should force publishing if archs-which-were-never-available are depwaiting" [Undecided,New]
<seb128> Mirv, didrocks said he would work on it next week I think
<didrocks> yep
<mardy> kenvandine: hi! Did you see my "categories" branch for the SystemSettings?
<mardy> (the branch name doesn't match the content very closely, actually :-) )
<kenvandine> mardy, yes... did you see my comment on it?
<mardy> kenvandine: obviously not :-)
<kenvandine> Looks like you forgot to add SystemSettings.pc.in
<kenvandine> :-D
<mardy> ops
<kenvandine> mardy, i also pushed a fix for my branch you reviewed
<mardy> kenvandine: just approved
<kenvandine> thx
<kenvandine> i'll just merge these to trunk until we get the merger setup for it
<kenvandine> mardy, i'm going to add a settings stack for daily release today
<kenvandine> and get that configured for the merger, etc
<kenvandine> and CI
<mardy> kenvandine: looking forward to it!
<mardy> cyphermox: hi, thanks for your review. Do you have some names to suggest?
<cyphermox> mardy: not really. people who've done Qt and helped you with QMenuModel before?
<NikTh>  waiting
<cyphermox> mardy: perhaps timo, but he doesn't seem to be around
<cyphermox> NikTh: ask in #ubuntu-kernel, but I think your config file for the kernel you're building is incorrect or not found
<NikTh> cyphermox: I'm sorry, I just tested some commands on IRC .. to another channel , but the message appeared here too. Sorry. :-)
<NikTh> cyphermox: Actually I'm waiting but not for an answer here. I'm waiting for building results.. :-)
<kenvandine> mardy, merge conflict now :)
<cyphermox> NikTh: ok
<mardy> kenvandine: updated :-)
<kenvandine> thx
<kenvandine> mardy, can you make me an admin of ~system-settings-touch
<kenvandine> i want to setup a PPA for CI builds
<rsalveti> pitti: I didn't forward that patch upstream as it's only relevant when you're booting in an android kernel
<mardy> kenvandine: done
<rsalveti> which is what happens only with touch
<kenvandine> mardy, thx
<rsalveti> but I can give it a try
<pitti> rsalveti: yeah, I don't think it hurts to have that working in udev upstream; thanks!
<mardy> seb128: about this blueprint: https://blueprints.launchpad.net/ubuntu/+spec/client-s-touch-system-settings
<mardy> seb128: you added one item "[mardy] write the "base shell" app: TODO"
<mardy> seb128: isn't that the same as the first item?
<kenvandine> mardy, not part of this merge, but i just noticed some copy and paste noise, like a reference to signon-ui.pot in src.pro
<mardy> kenvandine: oh, that might be. I'll check
<kenvandine> mardy, i've merged this branch, just clean that up in your next branch
<mardy> kenvandine: OK
<stgraber> pitti: hey, so I'm definitely loosing ACLs on /dev/snd/* every so often, it's not directly related to suspend/resume but it does happen every few days or so (may be related to some package updates)
<stgraber> (physical sound card)
<cjwatson> pitti: I'm trying to figure out why all our livefs builds are hanging, and it turns out that there's a stray 'udevd --daemon' process running, started a rather suspicious 40 seconds after the start of the build.  Do you know what might have regressed here?
<cjwatson> pitti: Specifically, started during debootstrap
<cjwatson> pitti: I notice we no longer have the udevadm.upgrade stuff; might that be relevant?
<cjwatson> pitti: This appears to be the same as bug 1182540
<ubottu> bug 1182540 in lxc (Ubuntu) "lxc smoke test, test_lxc_apparmor appears to hang on saucy VM" [High,Confirmed] https://launchpad.net/bugs/1182540
<seb128> mardy, yes, seems so, sorry I just dumped the session notes in there and didn't check for duplicates
<slangasek> mlankhorst: pong
<pitti> re
<pitti> cjwatson: ah, I didn't really see why disabling udevadm is related to starting/stopping the daemon
<cjwatson> I suspect something else calls udevadm which starts udevd
<pitti> cjwatson: so I'll put it back; it's almost certainly due to dropping these bits, yes
<cjwatson> I have an strace but it's gigantic
<pitti> I'll use above bug for that
<pitti> shouldn't be too hard to reproduce
<cjwatson> just debootstrap and you'll find an extra udevd --daemon process hanging around when you're done
<pitti> *nod*
<mlankhorst> slangasek: can you accept all the new packages in precise?
<pitti> stgraber: does that only affect /dev/snd/*, or other devices as well
<cjwatson> Hm, it actually looks as though it's being started directly
<cjwatson> 11398 write(1, " * Starting the hotplug events dispatcher udevd\n", 48) = 48
<cjwatson> Why is that touching /etc/init.d/udev ...
<slangasek> mlankhorst: I don't think I'll have a chance to look at it this morning; maybe SpamapS has some time?
<pitti> hm, where does that string come from; doesn't look like /etc/init/udev.conf
<cjwatson> /etc/init.d/udev
<mlankhorst> slangasek: friday's fine too, it's been lingering for ages in NEW
<SpamapS> slangasek: definitely not. I'm wrangling contractors today
<cjwatson> Via invoke-rc.d, WTF
<stgraber> pitti: assuming I should have an ACL on /dev/dri/card0, it affects all devices, though I think sound devices are more visible as pulseaudio appears to close them and reopen rather frequently (whereas the dri devices are kept open)
<pitti> cjwatson: hm, I assume we have a policy-rc.d somewhere?
<cjwatson> Ah
<cjwatson> This might be a debootstrap bug
<cjwatson> It has a fake initctl which doesn't respond to initctl version
<cjwatson> Which invoke-rc.d now cares about
<pitti> oh, I remember slangasek's mail about that
<cjwatson> So I could make it pass through version and see if that helps
<cjwatson> Something like http://paste.ubuntu.com/5690668/
<pitti> double quoting?
<pitti> ah, I guess it's a script that writes a script
<pitti> right, nevermind me
<slangasek> cjwatson: hah, doh
<cjwatson> Wonder what else might have a similar bug
<pitti> stgraber: do you still have a running session? ("loginctl show-session")
<cjwatson> debian-installer-utils and ubiquity at least
<cjwatson> With any luck that's the limit of the clone-and-hack
<slangasek> why is this not done via policy-rc.d?
<cjwatson> It installs a policy-rc.d as well
<cjwatson> I believe this is insurance against policy-violating packages
<cjwatson> Of which there were many more earlier on
<cjwatson> I mean, even openssh was at best skating on very thin policy until this morning
<stgraber> pitti: http://paste.ubuntu.com/5690694/
<stgraber> pitti: loginctl also says "c2     201105 stgraber         seat0" so the session is definitely registered
<cjwatson> Yep, that debootstrap change appears to fix it - just testing a bit more and I'll upload
<pitti> cjwatson: thanks
<cjwatson> Wonder if gina's unstuck yet
<pitti> stgraber: can you check if the devices have TAGS=:uaccess in "udevadm info --export-db|less"?
<stgraber> pitti: E: TAGS=:seat:uaccess:
<pitti> ok
<stgraber> (looking at /dev/dri/card0 in this case)
<pitti> stgraber: do the ACLs come back if you switch to VT1 and back?
<pitti> stgraber: you can also try "sudo udevadm trigger --sysname-match=card0 --verbose"
<stgraber> pitti: hmm, well, interstingly enough I can't switch vt... ctrl+alt+FX won't work and chvt won't either
<pitti> stgraber: try the udev trigger?
<stgraber> pitti: the udevadm trigger didn't help, still no ACL for my user on the device
<stgraber> pitti: starting to wonder if I somehow hit a kernel bug... stracing chvt I'm seeing "ioctl(3, KDGKBTYPE, 0x7fffbecbf14f)     = -1 ENOTTY (Inappropriate ioctl for device)" when trying to do the ioctl against any of /dev/tty, /dev/tty0 or /proc/self/fd/0
<stgraber> oh, actually that's wrong, tty0 doesn't give the ENOTTY
<stgraber> but it doesn't quite work either
<pitti> stgraber: otherwise, the output of this might give some insight:
<pitti> sudo strace -fvvs1024 udevadm test-builtin uaccess /devices/pci0000:00/0000:00:02.0/drm/card0
<stgraber> http://paste.ubuntu.com/5690716/
<pitti> stgraber: the sysfs path probably doesn't match for you, you can look it up in udevadm info --export-db
<pitti> stgraber: hm, wait -- I remember that I've seen something like this in otto
<pitti> stgraber: i. e. with ACLs in a container
<pitti> stgraber: you run your whole desktop in LXC, right?
<stgraber> pitti: strace => http://paste.ubuntu.com/5690719/
<cjwatson> slangasek: Ah, though it's true that if we had a policy-rc.d that would have acted as a stopgap.  We have that in other stop-daemons-running code but *not* in debootstrap
<stgraber> pitti: nope, that's a fairly standard desktop machine, I have a container running though but it doesn't have tty access
<cjwatson> So I think I should fix both
<pitti> cjwatson: so disabling udevadm during package upgrade wouldn't help at all here, right? (as the daemon is not normally started through udevadm)
<slangasek> pitti: udevadm needs to be disabled during package upgrade anyway; was that change dropped?
<pitti> stgraber: ok, comparing mine to your's, I have getxattr() == 44, then setxattr() == 0, and the writev("unload module index"), your's is missing the setxattr
<stgraber> right, that confirms it's not even trying to set the ACL, doesn't really tell us why
<pitti> slangasek: it wasn't ported over, yes; what's wrong with running udevadm during package upgrade?
<cjwatson> pitti: It's unrelated, but as slangasek says, I believe it's important for packages not to be able to call udevadm during udev package upgrade for the same reason it always was
<cjwatson> Let me dig up Scott's post about it
<pitti> yeah, I'm curious why that is
<stgraber> though I wonder if my messed up VTs could somehow break the code that detects whether I'm at the console or not
<pitti> at least info works just fine without udevd
<pitti> it just reads /run/udev, it doesn't query the daemon
<slangasek> pitti: I think that's the wrong question; why would you drop any part of the packaging before knowing why it was there?
<cjwatson>   * It is not permitted to call udevadm trigger or settle during an upgrade
<cjwatson>     without depending on udev.  Attempting this will fail.
<cjwatson> was the specific one
<slangasek> yes
<pitti> well, that's not much of an explanation
<slangasek> there were lots of upgrade failures because of this
<cjwatson> And info is a complete red herring, because udevadm.upgrade *passed through info calls*!
<pitti> and both trigger and settle work fine without udevd
<pitti> so that seemed obsolete to me
<pitti> I can add it back, but it seems like unnecessary complexity to me
<slangasek> how can 'trigger' work without udevd?
<cjwatson> This was associated with https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html
<cjwatson> Although that doesn't really explain it very well either
<pitti> slangasek: the trigger operation works fine, but of course rules wouldn't be processed
<stgraber> slangasek: IIRC trigger just uses /sys/..../uevent to re-emit the uevent
<pitti> but that's just the same net result as diverting udevadm trigger and saying that it won't work
<cjwatson> So I think Scott was concerned precisely that rules wouldn't be processed, and was trying to force packages to get this right
<cjwatson> Even if udevadm "works" (i.e. exits 0)
<pitti> ah, so that's not for *preventing* package installation failures, but for *causing* them to expose problems
<slangasek> cjwatson: but if 'udevadm trigger' now passes with no effect, how does that enable the caller to retry later?
<pitti> so in that regard we could put it back, but if anything that should cause more install failures, not less
<cjwatson> slangasek: indeed I'm arguing that we should put the previous implementation back because it's better to fail than to do the wrong thing
<slangasek> ah
<slangasek> the previous implementation failed?
<cjwatson> especially given that this has been intentionally failing for four years, so it's not a hidden source of problems
<slangasek> oh, right
<cjwatson> if [ "${0##*/}" = "udevtrigger" ] || [ "$1" = "trigger" ]; then
<cjwatson>     echo "udevadm trigger is not permitted while udev is unconfigured." 1>&2
<slangasek> yes, now I have the right end of the stick
<cjwatson>     exit 1
<cjwatson> fi
<cjwatson> etc.
<slangasek> yes, so udevadm would be called but we would lose the trigger
<slangasek> (potentially)
<tvoss> seb128, ping
<seb128> tvoss, hey
<pitti> so I guess what that really wants to say is that udevadm trigger should fail if udevd isn't running
<pitti> (udevadm settle, info, monitor, hwdb, test, etc. are all fine)
<cjwatson> pitti: If it causes install failures, we've been seeing those for four years, so they aren't new - it's basically an assertion about the correct design of other packages using udevadm
<cjwatson> The previous implementation explicitly excluded settle as well
<pitti> ok
<cjwatson> And doesn't settle also essentially require rules to be in place?
<pitti> trigger does (as that will cause re-processing the rules)
<pitti> settle just waits for udevd to finish with this, but if there's no udevd, there's nothing to wait for
<cjwatson> Mm, I suppose ...
<pitti> anyway, I'll put it back
<slangasek> right, furthermore I heard 'settle' no longer works upstream
<pitti> sorry for the misunderstanding
<cjwatson> if udevd isn't running> provided, basically, that udevd works as if it were Essential and can operate even when the package is unconfigured
<cjwatson> pitti: It's not this critical bug affecting lxc and livefs builds, anyway, so you can take a little more time about it if you like
<pitti> cjwatson: yeah, I won't get to that today any more anyway
<cjwatson> I've stolen that bug and will sort it out
<pitti> filed as bug 1182948
<ubottu> bug 1182948 in systemd (Ubuntu) "disable udevadm trigger during package upgrade" [Medium,In progress] https://launchpad.net/bugs/1182948
<pitti> slangasek: why doesn't "settle" work any more? there's even a systemd unit for it
<slangasek> pitti: I don't know; it's just something I heard, perhaps I heard wrong
<ion> mvo: Any thoughts about this? https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1182932
<ubottu> Launchpad bug 1182932 in software-properties (Ubuntu) "Add PPA keys to /etc/apt/trusted.gpg.d/{owner}-{ppa}.gpg" [Undecided,New]
<mvo> ion: I think that is a good idea
<mvo> thanks for working on this!
<ion> No problem, it was little effort.
<mvo> ion: any preferences what I should put in the changelog?
<ion> â[Johan Kiviniemi]â, â* Add PPA keys to /etc/apt/trusted.gpg.d/{owner}-{ppa}.gpgâ perhaps? Feel free to write anything you like.
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ion> mvo: Hmm, i suppose apt-key should be patched to create keyring files using a more permissive mode than 0600.
<mvo> ion: hm, 0644 should be ok
<davmor2> mvo: how do chap, how's life?
<mvo> ion: commited, thanks, I will upload in a bit
<mvo> davmor2: hey! nice to see you. I'm good, how are you?
<davmor2> mvo: I'm well thanks, busy as hell, but that is good too :)
<mvo> davmor2: haha, indeed! nice to see all the progress on the touch front, its very exciting to watch
<ion> mvo: I fail to see a gpg parameter to set the mode. Perhaps a chmod in apt-key after running gpg when --keyring was given? For every invocation or only when we detect a new keyring file was created?
<mvo> ion: I think its ok to keep 0644, /etc/apt/trusted.gpg is also 0644
<mlankhorst> 666 ofc
<mlankhorst> trust goes both ways right?
<tvoss> slangasek, ping
<slangasek> tvoss: hi
<debfx> cjwatson: re virtualbox: is it urgent to fix that? otherwise I'd fix it through Debian once it has migrated to testing.
<tvoss> gema, ping
<tvoss> slangasek, is there a wiki page around somewhere that captures any resource measurement things
<tvoss> ?
<slangasek> tvoss: I believe there is...at least there's one that lool created
<slangasek> but I don't remember the page and don't see it linked from https://wiki.ubuntu.com/Touch/
<slangasek> tvoss: ah, https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage - should maybe be converted to live under Touch/
<gema> tvoss: pong
<tvoss> slangasek, thanks
<tvoss> gema, did you start summarizing the memory measurement work, yet?
<gema> tvoss: we are looking into the stacked graphing you showed me
<gema> tvoss: doanac is leading this work and can give you previews as we make progress
<gema> doanac: ^
<tvoss> gema, cool. but I'm looking for a wiki page documenting the current work
<gema> tvoss: if you are referring to the memory performance indicator (the summary page) we haven't started that one yet
<gema> tvoss: this is where the work is being tracked: https://blueprints.launchpad.net/ubuntu/+spec/qa-s-dashboard
<pmcgowan> cjohnston, hey can ask you some questions on how topics and blueprints work
<doanac> tvoss: documenting the plan to improve the view or a document about the existing view?
<tvoss> doanac, documenting the measurement approach :) not necessarily the UI
<doanac> tvoss: ah - okay. will do and get back to you on it
<tvoss> doanac, perhaps you can take it from here https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage and move it to Touch. Would you mind keeping me and jasoncwarner in the loop?
<doanac> tvoss: okay. also an idea: instead of doing this in the wiki. would it make more sense to put these explanations in the views themselves?
<tvoss> doanac, for step two: yes, having a wiki page would help on a short timescale
<doanac> tvoss: okay. will do and will keep jason in the loop as well
<tvoss> doanac, awesome, thank you
<ion> mvo: Does this look okay? https://github.com/ion1/apt/commits/debian/sid
<cjohnston> pmcgowan: you can
<pmcgowan> cjohnston, if I want to define new topics and associate blueprints to them, is that all done via bp dependencies?
<pmcgowan> what makes a topic show up
<pmcgowan> for ubuntu-s status tracking that is
<cjohnston> pmcgowan: IIRC lool made a doc on it last cycle. trying to find it
<ScottK> wgrant: Still not picked up.  How's it going?
<roaksoax> howdy! Has something change in saucy that symlinks (in /etc/init.d) are no longer being create for upstart jobs
<roaksoax> ?
<infinity> roaksoax: https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html
<roaksoax> infinity: thanks!!
<ev> pitti: ooh, thanks! Will do!
<roaksoax> infinity: what about for packages that do not exist in debian and have no init script, any ideas what's needed to get to work correctly?
<rbasak> roaksoax: just the upstart job, surely? Why do you need init.d symlinks?
<rbasak> Forget I said that. I'm being stupid.
<roaksoax> rbasak: I don,t but dh_installinit is add a check of "if [ -x "/etc/init.d/XYZ" ]; then", which means that invoke-rc.d will never be called, hence the server will never start on postinst
<roaksoax> is adding*
<roaksoax> s/server/service
<barry> bdmurray: lp: #1173704
<ubottu> Launchpad bug 1173704 in python-imaging (Ubuntu Saucy) "PILcompat needs to add PngImagePlugin" [High,In progress] https://launchpad.net/bugs/1173704
<ScottK> barry: You should ask doko to push your python-imaging change to Debian (if you didn't) and phatch is PAPT maintained.
<stgraber> lifeless, barry: so where do we meet? hangout?
<lifeless> yeah
<lifeless> sounds good, let me see
<lifeless> stgraber: barry; sent you a hangout invite, no response :P
<roaksoax> infinity: --upstart-only doesn't seem to make an effect
<barry> lifeless, stgraber sorry i was a bit late, looking for the invite now
<cjwatson> debfx: as long as it's in the next couple of weeks, I guess that's fine
<Logan_> Has anyone been noticing that new Debian versions aren't being picked up by LP, according to syncpackage?
<stgraber> Logan_: is the source package name > gdb? :)
<Logan_> Yup...
<stgraber> so yeah, known issue
<Logan_> Bug link?
<stgraber> good question, I just saw that mentioned a couple of times on IRC, there's probably a bug against Launchpad/the package importer
<Logan_> Not seeing any. :/
<stgraber> Logan_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709118
<ubottu> Debian bug 709118 in src:gdb "gdb: truncated Maintainer field" [Serious,Fixed]
<cjwatson> Yeah, it's being fixed
<cjwatson> wgrant is applying a workaround in LP at some point
<Logan_> Ooh, awesome.
<Logan_> Thanks guys!
<cjwatson> Ideally we'd be able to work out why that got accepted in Debian in the first place, as the code says it shouldn't have done
<cjwatson> Ansgar's best guess observes that the lintian command in question is run through sudo and that maybe sudo fell over
<cjwatson> But without dak privileges on ftp-master.d.o I can't really check
<ScottK> DktrKranz: ^^^ maybe you could ...
<Laney> cjwatson: Couldn't it be because dak checked the _amd64.changes which doesn't seem to be invalid: http://packages.qa.debian.org/g/gdb/news/20130520T194802Z.html
<Laney> (didn't check what that lintian check actually does, mind)
<cjwatson> Laney: It's the .dsc that's invalid, and lintian does fail on the _amd64.changes (which is sourceful) when run manually
<cjwatson> Even when run manually on franck, I'm told (I've only tried on ries myself)
<Laney> ho hum
<cjwatson> Furthermore, 'dak process-upload' rejects it when run by hand
<cjwatson> All a bit mysterious really
<cjwatson> Logan_: It's annoying me though so don't fear it'll get forgotten.  Also I will notice when it gets fixed in the form of a gigantic mail from auto-sync, I expect ...
<cjwatson> debfx: Ah, I see you fixed it anyway - thanks
<Noskcaj> kirkland, can you merge some of the changes into testdrive? Andres has been rather slow to respond
<cjwatson> Riddell: I've uploaded rebuilds of the stuff that was still depending on libkdegamesprivate1, which should be enough to get it past proposed-migration
<cjwatson> Didn't test-build them all but the result of test-building kapman looked plausible
<doko> rbasak, so what about rebuilding all the facter stuff?
<cjwatson> Riddell: Oh, except kmahjongg apparently needs adjustment because libkmahjongg took over one of its binary packages?  Not going to worry about that now - bedtime.
<rbasak> doko: I've fixed facter in bug 1173265 - infinity said he'd review and sponsor soon
<ubottu> bug 1173265 in facter (Ubuntu) "facter fails to run from rebuilt source package" [High,Triaged] https://launchpad.net/bugs/1173265
<rbasak> doko: is the puppet failure due to facter?
<NikTh> Here I am again. You will never get rid of me :P New build error. As I guess I must add something in debian/rules, but what ? Error here: https://launchpadlibrarian.net/140487585/buildlog_ubuntu-raring-amd64.linux_3.8.0-21.32ubuntu1~bfsbfq0_FAILEDTOBUILD.txt.gz
<wgrant> cjwatson, ScottK: Working on getting the fix deployed... a bit difficult atm.
#ubuntu-devel 2013-05-23
<NikTh> anybody home ? :P
<NikTh> it is possible the fault because of that I had run "make xconfig" in current version ? => https://launchpadlibrarian.net/140487585/buildlog_ubuntu-raring-amd64.linux_3.8.0-21.32ubuntu1~bfsbfq0_FAILEDTOBUILD.txt.gz
<sarnold> NikTh: it's been absolute agest since I've compiled a kernel 'by hand', so I may be rusty, but that sounds exactly right
<sarnold> NikTh: perhaps 'make config' or 'make oldconfig' wouldn't leave a pile of object files all over your kernel sources tree..
<sarnold> NikTh: are you trying to make something that very closely approximates a distro kernel? or would the results of kernel-package's 'make-kpkg' utility do what you need?
<NikTh> sarnold: Now I have ran only "fakeroot /debian/rules editconfigs" and uploaded the package for building. We will see.
<NikTh> sarnold: I have history in here in the last few days.. LoL. I want to create a custom-ubuntu-kernel. Some patches included such as BFS & BFQ optimization ..etc
<NikTh> I can build the kernel locally very easy. sarnold :The problem here is that I don't know and as it seems I cannot understand how the Launchpad virtual builders work. So Failedbuild logs are coming to me.. continuously
<sarnold> NikTh: using a tool such as sbuild can help you get closer to a local environment like the buildds.. not perfect, but closer.
<NikTh> sarnold: I use debuild as all documents suggest. I don't know the sbuild. I have no other problem now, only that Launchpad builders create FailedtoBuild logs all the time :P
<wgrant> NikTh: Launchpad isn't designed as a test build service. You should try building in a clean environment locally using pbuilder or sbuild
<wgrant> eg. https://wiki.ubuntu.com/PbuilderHowto
<NikTh> wgrant: I always do this. pbuilder returns NO errors. It can build the package successfully.  I know tha launchpad builders are not for tests and that have other more important packages to build.
<NikTh> Well this is one of my last times I try to upload my custom-kernel to my PPA. One , perhaps 1 or 2 more attempts and I will give up. :-)
<NikTh> Ok, thanks for help. I have to leave now.
<pitti> Good morning
<pitti> stgraber: is there a standard way for a process to detect whether it's running in a container?
<infinity> pitti / stgraber: Maybe adding an iscontainer to debianutils to accompany ischroot would be handy?
<pitti> *nod* I tried to look at /proc/self/root, but that always seems to be / from inside the container
<infinity> pitti: Oh, wait.  /bin/running-in-container may be the trick.
<pitti> oh, nice
<pitti> stgraber: ^ is any of this applicable to upstream LXC? it seems /run/container_type is created by /etc/init/container-detect.conf, i. e. is ubuntu specific
<pitti> is /proc/1/environ containing "container=lxc" upstreamable?
<slangasek> pitti: indeed, if container=lxc is set in /proc/1/environ, that's the standard case that container-detect.conf handles
<slangasek> the /run/container_type is Ubuntu-specific, and is just there to avoid everything that cares having to reimplement container-detect.conf on Ubuntu
<pitti>         if (putenv("container=lxc")) {
<pitti>                 SYSERROR("failed to set environment variable");
<pitti> ah, nice
<pitti> thanks slangasek
<pitti> http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=blob;f=src/lxc/start.c;h=aefccd6505008dc7681f90d5b271287ebd13f1b5;hb=HEAD#l684
<pitti> jamespage: do you know about the openvswitch DEP8 failure? https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-openvswitch/7/ARCH=i386,label=adt/
<pitti> jamespage: the dkms test has some stderr output; either dkms should handle the absence of apport silently, or should depend on apport, or your test should pull in python(3?)-apport
<pitti> jamespage: "ma" fails as well
<dholbach> good morning
<geofft> yes
<geofft> and then I tried running a 'make ios' at the command prompt, but that's presumably the same thing
<geofft> er, wrong channel.
<tvoss> didrocks, ping
<didrocks> hey tvoss
<wgrant> cjwatson, ScottK: LP's view of Debian is now up to date
<infinity> wgrant: \o/
<Daviey> pitti: The discussions of udev yesterday.. that didn't break udev monitor, via pyudev ?
<Daviey> I ask because the tail of this build failure suggests some udev issue, https://launchpad.net/~openstack-ubuntu-testing/+archive/havana/+build/4600555/+files/buildlog_ubuntu-saucy-i386.quantum_1%3A2013.2%2Bgit201305222014~saucy-0ubuntu1_FAILEDTOBUILD.txt.gz
 * Daviey pops afk for a bit
<debfx> cjwatson: yeah, who knows when it'll migrate (yay for uncoordinated transitions).
<pitti> Daviey: no, that was unrelated (both disabling udevadm during upgrade and disabling udevd startup in debootstrap)
<Daviey> pitti: Odd, ok - i'll try a rebuild.  Thanks
<pitti> slangasek, cjwatson: I added back the scripts, but I don't do an upload just for this. We don't even stop udev in preinst (just restart it in postinst), so there is really no real danger for packages to get this wrong, and no urgency
<pitti> (for udevadm trigger disabling during upgrade)
<sladen> gavinguo: re: your message to ubuntu-devel@, I have caused an unsubscribe message to be generated.  You will need to confirm this
<Riddell> thanks for the upload cjwatson, I'm doing merges of all kde packages so working through them slowly
<mitya57> xnox: Hey again. I've just discovered Debian #696096 (and #696506) which have an error message very similar to our's
<ubottu> Debian bug 696096 in src:qt4-x11 "qt4-x11 ia64 FTBFS only on the buildds" [Important,Open] http://bugs.debian.org/696096
<mitya57> cc1plus: fatal error: .pch/release-shared/QtCore: No such file or directory
<mitya57> looks like adding "extra_configure_opts += -no-pch" is a workaround (but I don't know how dangerous it is)
<xnox> mitya57: it will make the build a lot slower.
<bl4de> hi to all! :)
<cjwatson> infinity: FYI I promoted zziplib to satisfy texlive-bin; shouldn't need an MIR as a copy was previously bundled in the texlive-bin source package.
<ev> mpt: are you in the office today?
 * NikTh Thanks the awesome f...ing guys in here, who helped him to solve all sorts of problems
<ion> mvo: Are you around?
<jdoles> Why do I have to find that some bug has been fixed in Debian in 2011 and that this bug in Ubuntu still exists to this very date?
<penguin42> jdoles: What are the package versions in the two - does Ubuntu have the package that debian has?
<jdoles> It is Debian bug 620800
<ubottu> Debian bug 620800 in rpcbind "reduce startup blather" [Normal,Fixed] http://bugs.debian.org/620800
<jdoles> In Ubuntu there are two duplicates for it and a combined heat of around 300.
<jdoles> Ubuntu bug 947638
<ubottu> Ubuntu bug 835833 in rpcbind (Ubuntu) "duplicate for #947638 spurious syslog error message because of use of -w on boot [rpcbind.xdr / portmap.xdr : errno 2 (no such file)]" [Medium,Triaged] https://launchpad.net/bugs/835833
<ScottK> wgrant: Thanks.
<penguin42> jdoles: Well Ubuntu has that debian package (albeit with some change)
<jdoles> penguin42: Ubuntu does not even have /etc/init.d/rpcbind
<jdoles> penguin42: likely because it used Upstart.
<GridCube> does commenting with # works in lightdm.conf?
<jdoles> penguin42: /etc/init/rpcbind-boot.conf contains nothing of use.
<jdoles> penguin42: how *does* Ubuntu start rpcbind?
<jdoles> Found it already.
<jdoles> penguin42: Ubuntu most definitely applied these changes.
<jdoles> penguin42: er not applied
<jdoles> What's the point of reinventing the wheel (Upstart) if you are not prepared to keep up with even Debian Stable (yes, Debian Stable has these changes)?
<lool> cjwatson: on the topic of dev series, would it be known to Launchpad in the web UI and listed series in the API and such, or would just be an archive.u.c symlink?
<lool> cjwatson: I'm asking because cjohnston is curious on whether the workitems tracker would have to cope with this and I'm also curious because we'd actually like to experiment with blueprints targeted at a stable series rather than moving across series, but it would like be fine to use something like an ubuntu-blueprints project with a single series there for experimenting
<cjwatson> lool: It wouldn't be a separate series in LP.  LP would know about it but I don't think it would be exposed in the UI
<cjwatson> lool: The less the scope creeps the more likely it is to happen ;-)
<lool> cjwatson: either way is fine, was just wondering how much LP would know about it; I guess you're saying as little as technically possible, which is fine  :-)
<cjwatson> Indeed.  Initially I'd just been planning a symlink created by the publisher, though I might have been persuaded to make uploads work too
<cjohnston> cool. thanks cjwatson
<cjohnston> It's always fun talking to cjwatson because I always get pinged for him anyway
<geser> hmm, it would be interesting to know if cjwatson has also a highlight on cjohnston (due to tab-fail from others) :)
<ev> rsalveti: wooo! http://paste.ubuntu.com/5693714/
<ev> it's not working outside the ubuntu chroot yet, but I suspect that has more to do with debuggerd running
<ev> thanks for getting the new kernel working
<cjohnston> :-)
<mitya57> that issue is even mentioned in ... xchat changelog! https://launchpad.net/ubuntu/+source/xchat/2.8.8-7ubuntu2
<mitya57> Mirv: nice work with Qt 5!
<cjwatson> geser: I do not
<mitya57> (Qt 4 is broken by me at the moment)
<Mirv> mitya57: thanks :)
<Mirv> not for breaking Qt 4 though ;)
<mitya57> Mirv: xnox said he'll look at Qt 4 (I can't because I don't have any ARM hardware capable of building Qt)
<Mirv> cool. ARM problems are quite slow to debug indeed, except maybe a little nicer with some recent Cortex-A15 quad-core.
<xnox> Mirv: mitya57: well I want doko to look into borked pch. I am suspecting it's the same thing that kills abi-compliance-checker for jodh in upstart.
<doko> don't use pch
<xnox> doko: ok.
<xnox> doko: but will you fix them, please, anyway? =)
<doko> xnox, test case?
<mitya57> doko: qt4-x11 on armhf/powerpc (that's not a minimal test case though)
<doko> indeed
<ion> mvo: Hi. Are you around?
<xnox> doko: yeah, should get you a more minimal one. But for example abi-comliance-checker -test fails which should be quite minimal. I'll try to get you even a smaller one.
<mitya57> jamespage: hi, did you see https://bugs.launchpad.net/ubuntu/+source/blktap-dkms/+bug/1157421/comments/5 ?
<ubottu> Launchpad bug 1157421 in blktap-dkms (Ubuntu Precise) "blktap-dkms version in 12.04.2 is not compatible with the 12.04.2 kernel" [High,Fix committed]
<mitya57> I don't know what those errors mean and whether it is verification-done or verification-failed :)
<jamespage> mitya57, neither do I :-(  sorry
<mitya57> jamespage: do you know someone who does? or who can test it independently?
 * rbasak reads
<rbasak> I'd say that we need verification that there hasn't been a regression from a 3.2 user
<rsalveti> ev: cool
<xnox> jodh: are you looking into merging json-c from debian? You have the TIL =)
<jodh> xnox: we can't update any of upstarts dependencies until lp:~jamesodhunt/upstart/serialise-remaining-objects is reviewed.
<xnox> jodh: correct.
<roaksoax> slangasek: howdy!! so I was wondering what should I do with those packages which are not in debian and only have upstart jobs (no init scripts). dh_installinit is still checking for /etc/init.d/<service-symlink> existance, which causes that the services are not started on install...
<stgraber> jodh, slangasek: hey, does one of you know why the following appears to confuse mountall?
<stgraber> UUID=c9f13d56-0dcd-4bac-b913-ee3b81d5deac /home ext4 discard 0 1
<stgraber> /home/stgraber/data/vm/lxc/lib /var/lib/lxc none bind 0 0
<stgraber> jodh, slangasek: /home is a partition on encrypted LVM which gets mounted fine (well, usually, there's a race there I need to look into) but then I'd expect mountall to properly figure out that it can't mount the second entry so long as /home isn't mounted
<xnox> stgraber: can you run mountall with debug enabled and get the logs?
<xnox> or if you have them already, paste them. It should build a tree and figure out the dependency....
<stgraber> xnox: I'd have to do quite a few tricks to be able to run mountall in debug mode against that but yeah, I'll do that if nothing obvious jumps at jodh or slangasek. My current feeling is that mountall doesn't understand bind mounts and so doesn't actually build a dependency tree for the source device and only does so for the mount point.
<stgraber> and fixing mountall to wait for the source to be mounted may lead to new issues (as some people may want to bind-mount a directory to some other place before mounting something over the source directory...)
<xnox> stgraber: hm. on normal systems one just modifies the mountall upstart job to include --debug + reboot and collect log from /var/log/upstart/
<stgraber> xnox: ah didn't know that worked, I somehow assumed --debug would conflict with --daemon and so would prevent mountall from daemonizing (blocking the boot in the process)
<xnox> stgraber: i had do that once, can't remember if i removed daemon or not (to keep it in the background for upstart to collect the log output) it may ended up in the upstart log and/or bootmessages.
<xnox> but yeah, it's easy and doesn't inhibit booting.
<jodh> stgraber: looks like mountall should indeed wait so we need to see the debug log.
<stgraber> jodh: ok, I'll reboot in a bit and grab the debug logs
<doko> apw, ogasawara: could you test kernel builds using the binutils from the ubuntu-toolchain-r repository?
<rbasak> doko: it looks like my facter merge will fix bug 1182613. But please could you test your uploads in future? A dep8 test could help with that, too.
<ubottu> bug 1182613 in puppet (Ubuntu) "puppet completely broken on saucy" [High,Triaged] https://launchpad.net/bugs/1182613
<doko> rbasak, thanks for checking. please could you add one? puppet is supposed to be maintained by the server team. just trying to get rid of ruby1.8 (which should have happened long time ago)
<roaksoax>  /win 13
<rbasak> doko: sure - I'd expect the server team to maintain puppet. I had looked into any potential breakages with updating to puppet 3.x and was surprised to see that you bumped a major version without communicating with us.
<rbasak> I plan to add a dep8 test soon. I did one for facter. Just not got as far as puppet yet.
<doko> rbasak, I did communicate for quantal and raring, nobody did listen
<rbasak> doko: not seen anything on the mailing list.
<doko> yes, same for mysql-4
<doko> 5.5
<slangasek> cjwatson: so wrt dd-list, were you wanting the list of affected packages by Debian maintainer or Ubuntu maintainer?
<cjwatson> The former
<cjwatson> I don't expect the latter will be very useful, but the former would let us deal with things like orphaned packages in Debian quickly
<slangasek> ok
<bdmurray> TheMuso: can you add a regression potential statement to bug 1163638?
<ubottu> bug 1163638 in pulseaudio (Ubuntu Quantal) "pulseaudio fails to release card to jack" [Undecided,Fix committed] https://launchpad.net/bugs/1163638
<dpm> hey seb128, I'm new to this so I'm not sure I need to ping an archive admin or if it is something that they already do regularly: I've got a package for a personal project (qreator) in saucy's new queue. Would it be possible to get in the archive?
<seb128> dpm, hey, no need to ping, queue is worked on on regular basis, it "just" require an archive admin to do a shift (a bit like sponsoring)
<seb128> dpm, I will try to have a look tomorrow if nobody beats me, sounds like a good friday thing ;-)
<dpm> ok, cool, I can wait, no worries. I understand how it works now, thanks!
<NikTh> Hey guys.
<NikTh> Question: What is the correct name to avoid the update of existing kernel ? As you can see (and with your help of course) I managed to upload and build correctly my custom-kernel to PPA: https://launchpad.net/~nick-athens30/+archive/custom-kernels
<NikTh> The thing that is wrong here, is that it replaces (update) the current ubuntu kernel. I don't want this. Is not safe (IMO). I want a new kernel that the user must install by hand. (manually).
<NikTh> I know that I must change the name in debian/changelog file, but what characters I must add to avoid this problem ?
<NikTh> eg: 3.8.0-21.32-new~nikth will do the job or not ?
<cjwatson> I don't have time to help properly now, but you're on the wrong track there; it has nothing to do with anything in debian/changelog
<cjwatson> you need to change the *binary* package name, either by changing the flavour or by changing the ABI
 * cjwatson -> dinner
<NikTh> cjwatson : Thanks ! and .. Bon appetite :-)
<NikTh> But the binary package name does not   depend on debian/changelog file ? Here with dch -i  I can specify the version and the final binary package has the name that I declare there.
<NikTh> Be aware here that I had skipmodule=true and skipabi=true (inside debian/rules) to avoid building problems
<NikTh> Topic needs a replacement ? (hardy is not supported anymore - EOL)
<cjwatson> NikTh: debian/changelog specifies the source package name and the source package version (which is normally, although not always, equal to the binary package version).  Binary package *names* are determined primarily by debian/control, although much of the rest of debian/ goes into that too.
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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:
<NikTh> cjwatson: Thanks. I just changed the ABI version. We will see. :-)
<jdstrand> mdeslaur: so, I feel like I am doing something wrong: http://paste.ubuntu.com/5694963/
<jdstrand> mdeslaur: I'm combining your patch with ted's upstart-app-launch
<jdstrand> mdeslaur: and gedit is launching, but I don't think it should be based on the man page entry you added
<mdeslaur> jdstrand: oh, I definitely don't support wildcards
<jdstrand> wildcards?
<mdeslaur> well, $APP_ID
<jdstrand> that should evaluate to 'apparmor switch gedit'
<mdeslaur> jdstrand: yeah, I don,t support that
<jdstrand> ok
<jdstrand> well, if I change it to 'apparmor switch foo', the job still starts
<jdstrand> but I didn't think it should, based on the man page
<mdeslaur> ok, I'll take a look
<jdstrand> mdeslaur: so, am I abusing the implementation? I just tried to connect the dots between ted's upstart-app-launch and what you had
<jdstrand> mdeslaur: did you see this working another way?
<mdeslaur> abusing?
<jdstrand> using 'apparmor switch $APP_ID'
<mdeslaur> well, I'll have to figure out how that's handled elsewhere in upstart if you want to do that
<mdeslaur> that's an environment variable?
<jdstrand> mdeslaur: I don't think it's an environment variable... but maybe?
 * jdstrand hasn't looked
<mdeslaur> jdstrand: ok, I'll figure it out
<jdstrand> eg, in the modified job of ted's, he has 'env UBUNTU_APPLICATION_ISOLATION=1'
<mdeslaur> yeah, APP_ID=foo on the start command line creates an environment variable called APP_ID
<jdstrand> it feels more like a variable declaration in upstart
<jdstrand> ah, I see
<mdeslaur> but the apparmor_parser doesn't handle that
<jdstrand> mdeslaur: so, on the one hand, it seems very clean from a job POV to support 'apparmor switch $APP_ID'
<jdstrand> cause you just have one job file for this type of launcher
<jdstrand> (ie, ted's /usr/lib/x86_64-linux-gnu/upstart-app-launch/desktop-exec)
<jdstrand> on the other hand, it seems a bit messy in terms on implementation to resolve that env var to give to apparmor_parser
<jdstrand> s/on/of/
<jdstrand> now that I understand how it works, it would require a change to the parser, and APP_ID is fairly arbitrary, and we would need to do all kinds of input sanitization, etc, etc
<jdstrand> but not doing it means we need to have a different job file for each app
<jdstrand> which may or may not be ok, but is contrary to ted's idea
<jdstrand> mdeslaur: thoughts? ^
<mdeslaur> I don't know, I'll think about it
<jdstrand> mdeslaur: I was initially thinking that upstart would somehow resolve that internally, but now I see that makes no sense
<mdeslaur> well, it could
<mdeslaur> it's doing it for the instance stanza for example
<jdstrand> ah, yes, true
<jdstrand> mdeslaur: so, writing 'exec foo' to '/proc/<pid>/attr/exec' will change profile to foo for <pid>?r
<mdeslaur> no, it will change the profile for the next exec
<jdstrand> ah
<jdstrand> right, so in my job, /usr/lib/x86_64-linux-gnu/upstart-app-launch/desktop-exec should be executed under the 'foo' profile
<mdeslaur> huh, first time I see desktop-exec
<mdeslaur> we're not directly launching stuff now?
<mdeslaur> if we're going to use an external launcher, why even use upstart for this?
<jdstrand> mdeslaur: this isn't in Ubuntu or anything yet. ted came up with http://gould.cx/ted/blog/Application_Centric_User_Experience
<mdeslaur> yeah, but the desktop-exec launcher is new to me, and wasn't part of the initial upstart job he showed me
<jdstrand> mdeslaur: upstart gives certain things for free (see the blog)
<mdeslaur> hrm, maybe doing this with upstart is overkill now
<jdstrand> mdeslaur: which this?
<mdeslaur> jdstrand: if we're already going to use an external launcher, why use upstart? just for application uniqueness?
<mdeslaur> jdstrand: anyway, let me look at why switch isn't working in user sessions to begin
<jdstrand> mdeslaur: uniqueness and management. it's also possible to do the cgroups stuff sometime down the line, aiui
<mdeslaur> well, not if we're using an external launcher...that just took all the niceness out of it
<jdstrand> mdeslaur: I'm not advocating for desktop-exec btw-- it is just what was out there and I thought that is what you guys discussed :)
<jdstrand> I don't see how it takes the niceness out of it
<jdstrand> desktop-exec doesn't persist or anything
<jdstrand> start and stop all work ok
 * jdstrand doesn't understand the issue
<jdstrand> mdeslaur: desktop-exec is a way to launch a .desktop file via upstart
<jdstrand> it is very simple
<jdstrand> perhaps too simple. 'start aa-app APP_ID=nonexistent' causes a core dump :)
<jdstrand> mdeslaur: but going all the way back, 'apparmor switch foo' doesn't actually seem to fail like the man page says it will
<mdeslaur> jdstrand: yes, that's why I said to wait until I fix it
<jdstrand> mdeslaur: I didn't see that you said that, sorry
<mdeslaur> jdstrand: np :)
<mdeslaur> oh, hrm, a user can't see if apparmor is enabled in the kernel
<mdeslaur>  /sys/module/apparmor/parameters/enabled is 600
<mdeslaur> jdstrand: ok, I know why it doesn't work, and I'll work on it tomorrow
<jdstrand> k
 * jdstrand tries it with an existing profile
<mdeslaur> jdstrand: ok, need an updated kernel with a bug fix from jj
<mdeslaur> jdstrand: you can comment out the "silently fail if apparmor isn't available" check in apparmor.c if you want to try it without jj's updated kernel
<jdstrand> mdeslaur: thanks
<mdeslaur> jdstrand: ok, I know how to make apparmor switch handle variables...I'll fix it and test it tomorrow morning
<jdstrand> mdeslaur: neat :)
<jdstrand> mdeslaur: fyi, the patch you gave me earlier worked fine just now
<mdeslaur> cool
<jdstrand> mdeslaur: and yeah, commenting out the apparmor_available() bit makes it work
<jdstrand> (for now)
<TheMuso> bdmurray: Ah crap ok missed that, its not my bug so will have to bug the original reporter/patch filer.
<mwhudson> doko: hey
<mwhudson> hm, i should stop doing this and just write an email
<mdeslaur> jdstrand: lightly tested: http://paste.ubuntu.com/5695234/
<doko> mwhudson, ?
<mwhudson> doko: q about the python3 package
<mwhudson> doko: i notice that it enables the --with-computed-gotos configure option
<doko> yes?
<mwhudson> doko: but in my testing, unless you also disable CSE (-fno-gcse) it has no benefit
<mwhudson> has anyone done testing with/without the flag?
<doko> I did enable this a long time ago ...
<mwhudson> (even with no-gcse it seems a bit marginal on sandy bridge, it definitely helps on cortex-a9 though)
<doko> and after that, I did enable lto and pgo too
<mwhudson> yes, those definitely help :)
<doko> I see that mans did ask to you check this for a single function/file?
<mwhudson> oh yes, i need to reply to that
<mwhudson> but in my traces pyeval_evalframeex is so dominant in run time that pessimizing everything else to optimize that is still a win i think
<mwhudson> doko: anyway, i just wanted to raise this fact: "--with-computed-gotos + default -O3 -> no benefit"
<doko> mwhudson, to make sure, you didn't enable pgo and lto in your tests?
<mwhudson> doko: i've also backported --with-computed-gotos to 2.7 if you're at all insterested
<mwhudson> doko: yes and no
<mwhudson> doko: i've just checked out the v2.7.4 tag and built with various options
<mwhudson> and i've also built debian packages with --with-computed-gotos with default O3 and with O3 & no-gcse
<mwhudson> (and those did lto and pgo)
<doko> on x86, but the last ones not on armhf
<mwhudson> mostly all on armhf
<mwhudson> i've been building amd64 in my ppa but not actually doing a lot with that...
<doko> can we follow-up on that tomorrow/next week? it's late here
<mwhudson> sure
<mwhudson> i'll file a bug i guess
<mwhudson> on python3.3 in ubuntu
<doko> saucy?
<mwhudson> makes sense i guess
<mwhudson> or maybe even debian i suppose...
<doko> well, I would like to start with current 4.8.x
 * mwhudson blinks
<mwhudson> doko: 4.8.x?
<doko> gcc-4.8
<mwhudson> oh gcc?
<mwhudson> ahh right
<mwhudson> yes makes sense
<mwhudson> doko: https://bugs.launchpad.net/ubuntu/+source/python3.3/+bug/1183600
<ubottu> Launchpad bug 1183600 in python3.3 (Ubuntu) "--with-computed-gotos optimizations probably nullified by cse" [Undecided,New]
<jtaylor> mwhudson: do you have a benchmark?
<jtaylor> I think just disabling it for the one function is probably safer, can be done easily with gcc attributes
<mwhudson> jtaylor: pystone is quite a good benchmark for this
#ubuntu-devel 2013-05-24
<ScottK> xnox: What's your plan for quantlib?  Your upload's been sitting in saucy-proposed FTBFS for almost a month.
<infinity> ScottK: I'm guessing that'll need some TLC to sort out why the testsuite is hanging. :/
<infinity> ScottK: It's possible that reverting to gcc-4.7 might make it happy for now, at least, though that won't make doko happy.
 * infinity tries that locall.
<infinity> y
<pitti> Good morning
<didrocks> xnox: hey, I would prefer a step by step for https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_exposing_a_new_C.2B-.2B-_symbols_in_my_library.2C_it_seems_that_some_packaging_changes_are_needed.2BICY- as upstream doesn't really know what a symbol files is, so better to put all commands to guide them (and replace the version with 0replaceme for new symbols, how they can see them and so on)
<tjaalton> pitti: if your arrandale laptop is on saucy there's a new mesa update available which hopefully fixes the slow blur properly :)
<tjaalton> dash blur
<pitti> tjaalton: oh, nice! I got some new Xorg-ish packages this morning, but haven't rebooted yet
<tjaalton> yeah new -intel minor bump too
<dholbach> good morning
<tjaalton> pitti: looks like blur is slow on sandybridge again with the new mesa
<tjaalton> so it's not actually fixed in the stable tree
<ev> wgrant, StevenK: looks like we're nearly there with ddebs in the librarian (if LP bugs is any guide). Thanks for the hard work!
<wgrant> ev: Yeah, just the one known issue left
<ev> bug 1179329?
<ubottu> bug 1179329 in Launchpad itself "lp.soyuz.adapters.overrides doesn't respect ddeb override rules" [High,In progress] https://launchpad.net/bugs/1179329
<ev> and woohoo
<ev> Does anyone know of a hackish way around "The build target must not do anything that might require root privilege." in 4.9 of Debian policy? As part of a package of test crash reports, I'm attempting to install a package that purposefully crashes in its postinst.
<cjwatson> ev: manually run stuff in fakeroot?
<cjwatson> ev: (note, you don't get real root in the binary target either)
<ev> cjwatson: you mean with a chroot? dpkg isn't going to be happy that it cannot write to a number of places.
<ev> even after I -o away the ones I can.
<cjwatson> LD_PRELOAD
<cjwatson> I mean, you can't do any better, if you want to do this in a package build
<cjwatson> Leaving aside policy 4.9, you *don't have root* at any point in the build that you control ...
 * ev nods
<cjwatson> I know that it's possible to LD_PRELOAD dpkg sufficiently, because I did it in lp:click-package :-)
<ev> all these years complaining about dpkg running maintainer scripts as root, I guess I deserve this ;)
<cjwatson> You can borrow from that if it helps
<ev> cjwatson: oooh, will do; thanks!
<cjwatson> (There's some extra kind of mini-sandboxing stuff you don't need)
<infinity> ev: fakechroot might be enough for what you want.
<infinity> But installing a package during a package build just seems wonky on a few levels. :P
<cjwatson> fakeroot fakechroot gets you most of the way there, yes.  I think it was (a) slightly inadequate for me in some way I forget and (b) slow to stack up all the external helpers, so I just rolled my own
 * StevenK twitches at the memories of attempt to hack moblin-image-creator to work under fakeroot and fakechroot
<cjwatson> infinity: Test suite, I expect
<cjwatson> ev: Mind you, if you care about having the maintainer scripts actually run, you'd be better off using fakeroot and fakechroot than my stuff.  I had the luxury of being able to just turn off chroot and execvp.
<infinity> cjwatson: Yeah, I assumed it was a testsuite, it still feels hackishly evil to require "root" in a testsuite. ;)
<infinity> (Unless it's real root, which is entirely valid for some kernel testsuites and such)
<infinity> Can't dep-8 specify wanting root for tests?
<cjwatson> Yes.
<infinity> ev: Might it not be better to just do a dep-8 test with real root, instead of trying to do this at build time?
<cjwatson> I'd personally prefer doing things without requiring that, but each to their own.
<infinity> ev: If it's going to blow up the dpkg DB, "Restrictions: needs-root breaks-testbed" looks appropriate.
<pitti> however, ev's test-crashes package just lives in a PPA AFAIK, it's not actually in Ubuntu
<pitti> we can run DEP-8 tests from selected PPAs, though, so it might still be an option
<infinity> cjwatson: I'm of two minds.  I'm all for not requiring root to test things, but there's also the reality that when you abstract and synthesize a little too much, you lose all the fun corner cases of the original test conditions.
<infinity> (And synthesizing root definitely can fall under that umbrella, since you end up faking a bunch of calls that you might otherwise have broken something with)
<NikTh> Hello. Can someone tell me why the "~" character is not allowed in package name ? Read here another build failure of mine. https://launchpadlibrarian.net/140581585/buildlog_ubuntu-raring-amd64.linux_3.8.0-999~bfsbfq1_FAILEDTOBUILD.txt.gz
<xnox> didrocks: the c++ specific symbols go right after the "how to add c symbols", I'm not sure it makes sense to copy & paste and repeat the same information twice. Hence the c++ answer starts with "similar to above,..."
<didrocks> xnox: from my knowledge, upstream doesn't really go through and won't look at it. They are looking for step by step instructions
<didrocks> it's already hard to have them reading the documentation (again illustrated yesterday :p)
<didrocks> so let's make this as simple as possible for them
<cjwatson> NikTh: Er, it just isn't
<cjwatson> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source has the rules for package names
<infinity> NikTh: If you make that 3.8.0-999.1~bfsbfq1, you'll be fine.
<infinity> NikTh: Understanding how the kernel package does ABI/build numbering is helpful here.
<infinity> NikTh: But might I also point out that you're perhaps doing a disservice to your users by jacking up the version number on -generic unless you intend to rebase for every single security upload as soon as we release...
<infinity> NikTh: (A different flavour entirely, so they know what they're getting into might be better, I dunno)
<NikTh> infinity: exactly. I thought this too. Because I have already uploaded a package with this.. tilda (I think is the name) character inside and I had no problem. 3.8.0-21.32nikth1~bfsbfq1
<infinity> NikTh: 3.8.0-21 is the kernel ABI in that example, .32nikth1~bfsbfq1 is the build ID.
<infinity> NikTh: The first part ends up in the binary package names, the latter part is only in the versions.
<infinity> NikTh: It splits on the first '.' after the '-'
<NikTh> I want to upload a completely different version, so I changed the ABI. I don't want users to upgrade the official ubuntu kernel with mine. I want to install it (if they want) by hand. Manually
<infinity> NikTh: Notice how the official kernel packages are versions like: "3.8.0-21.32" and "3.8.0-21" is in the package name, but ".32" isn't.
<NikTh> What name you suggest infinity
<NikTh> infinity: to achieve my goal. Not upgrade the Ubuntu official kernel when users add my PPA, but install a new kernel instead
<cjwatson> Haven't people suggested several times that for kernel-specific questions you should use #ubuntu-kernel, BTW?
<cjwatson> (Because this line of questions is absolutely an artifact of things that are specific to the kernel packaging)
<NikTh> cjwatson: I thought this was a debian package system error.  But I will ask there too. Thanks
<cjwatson> It is not, it's kernel-specific.
<cjwatson> As has been pretty much everything you've asked about over the last few days :)
<cjwatson> The kernel has very complex packaging that needs to be tickled just right
<mlankhorst> first sign of kernel developer, perceiving inanimate kernels as alive?
<pitti> Don't anthropomorphize computers, they don't like that!
<StevenK> pitti: Haha
<xnox> didrocks: collapsed both c & c++ answers into a single symbols question on the wiki, with caveats and links to further reading.
<didrocks> xnox: ok, will give a look later, thanks!
<mpt> ev, any idea why Ubuntu 12.10's error rate has plummeted since the last week of April?
<davmor2> mpt: every moved to 13.04 it's better
<davmor2> mpt: everyone even
<mpt> ooh, that might actually be it
<mpt> People upgrading and the error tracker hasn't yet realized they aren't using 12.10 any more
<ev> mpt: I'm not sure. It's surprising, given that awful "oh you want to upgrade? Sorry pal, not happening" bug.
<mpt> ev, how does the ID work on upgrades? Does it stay the same?
<ev> mpt: by ID do you mean at what point does the release change for new crash reports on the system during an upgrade?
<mpt> That might also explain the (lesser) dip in 12.04's error rate when 12.10 came out
<mpt> ev, no, at what point (if any) does the machine ID change.
<ev> it never changes
<ev> purposefully
<ev> it's based off a value in the DMI tables
<ev> the system uuid, sha512 hashed
<mpt> ev, good, so, as soon as we get a report from a machine release N+1 do we remove it from the count of machines known to be running release N?
<ev> mpt: in the calculation for the number of unique machines seen in a 90 day window?
<mpt> ev, yes.
<ev> mpt: no - I suppose we could take the set difference, working backwards
<ev> so figure out the unique machines seen in Saucy in the past 90 days, hold those in memory, then figure out the machines seen in Raring in the past 90 days, removing any that are present in the Saucy list
<mpt> something like that
<ev> I'm just wondering if the 90 days part breaks that
<ev> hmm
<ev> no, I think we're okay. It's simply preventing double counting a machine against two releases.
<ev> filing a bug
<mpt> I'm already doing it :-)
<ev> ah excellent
<ev> I do wonder what the effect will be for issues like the upgrader bug
<ev> we'd be counting those machines for Raring, even though the issue happened in Quantal
<ev> because they were seen on that day as using Quantal, assuming they found a way around the upgrade problem
<mpt> bug 1183759
<ubottu> bug 1183759 in Errors "Machine counts for Ubuntu version include machines known to be running newer version" [Undecided,New] https://launchpad.net/bugs/1183759
<mpt> If that's the cause of the 12.10 slump (and the bug isn't fixed first), the 12.10 error rate will return to ~0.05 towards the end of July.
<cjwatson> RAOF: Could you merge libxfixes?  I'm touched-it-last, but only for a rebuild; the substantive changes are yours.
<xnox> ev: how is release detected? i'm running a mixed saucy/raring install and I did not use upgrade-manager to upgrade.
 * xnox 'd like to know if I am counted as raring or as saucy.
<ev> xnox: whatever is in lsb-release/os-release, I imagine
<xnox> saucy, all good.
<cjwatson> I fear I may have temporarily made texlive-base uninstallable in the next publisher cycle.  It shouldn't be a big problem except for people installing saucy or upgrading to saucy in the relevant window (upgrades within saucy won't be affected, as far as I can make out), and it ought to fix itself after the next proposed-migration run and publisher cycle.
<cjwatson> Sorry about that.
<sil2100> cyphermox: hi! I just checked https://code.launchpad.net/network-manager and noticed that the importer failed importing for git over 5 times
<maxb> sil2100: Check the logs:
<maxb> 2013-05-22 11:48:25 INFO    Unable to import branch because of limitations in Bazaar.
<maxb> 2013-05-22 11:48:25 INFO    The repository you are fetching from contains submodules, which are not yet supported.
<pitti> cjwatson: wow, apologizing for 30 minutes of minor installability breakage in a cycle is a really nice testament to how far we've come!
<cjwatson> Heh, yeah.  Hopefully it was just that; unfortunately once you break something proposed-migration will basically do whatever it takes to improve things, so it's hard to see what may have broken as a result.  The total uninstallable count appears to have gone up by one per architecture ...
<cjwatson> Can't quite work out what though
<cjwatson> Processing NBS to see if that helps
<ev> drat. I got so far with a few fakeroot fakechroot lines and then hit the wall that is needing /proc in the chroot.
<pitti> ev: you can create a /proc -> /proc symlink in the fakechroot
 * ev beats his head on the desk
<pitti> (at least that worked a few years ago when apport's retracers were still using fakechroot)
<ev> thanks pitti
<pitti> it looks recursive, but back then it was acting like pointing "outside" the fakechroot into the real fs
<hallyn> when installing a new package which has preinst and postinst, as well as an upstart job, will the upstart job be started after preinst and before postinst?  (I should think so, but wanted to make sure)
<pitti> that surely depends on the start condition?
<pitti> jodh: ^
<rbasak> Doesn't the upstart job get started _by_ the postinst, usualy courtesy of debhelper? Or does it work differently with upstart, or have I completely misunderstood the question?
<cjwatson> The upstart job is indeed normally started by the postinst
<hallyn> rbasak: no, that's the question...  the issue is lxc.preinst is setting up /etc/default so that the lxc-net.conf upstart job can start lxcbr0 - but lxcbr0 is not being started.
<hallyn> until you reboot or manually restart lxc-net
<cjwatson> It would be incorrect for it to be started before the postinst, in general, because the package is unconfigured then
<cjwatson> hallyn: It's your postinst's responsibility to do that.  Is this an upstart-only job though?
<cjwatson> Yeah, it is
<cjwatson> I think there are some (unfiled?) problems with upstart-only jobs at the moment
<cjwatson> 20:36 <infinity> slangasek: Does dh_installinit need a bit more mangling for the upstart-only case now that the upstart-job links disappeared?
<hallyn> ah
<rbasak> Ah - so nothing is starting the upstart-only job in hallyn's postinst?
<hallyn> cjwatson: to be clear - the #DEBHELPER# should insert the necessary code if dh_installinit is being used, right?  I don't then ahve to manually do it in postinst?
 * hallyn looks up
<cjwatson> Indeed, you shouldn't have to do this manually, it's a debhelper bug
<hallyn> is there an open bug for this?
<cjwatson> I don't see one
<cjwatson> Let me see, maybe it's not too hard
<hallyn> ah, found the backlog.  Note everyone uses UTC for their irc log timestamps? :)
<hallyn> cjwatson: just wanted to mark bug 1183807 a dup of it if there was one
<ubottu> bug 1183807 in lxc (Ubuntu) "lxcbr0 is not created on package install" [High,Triaged] https://launchpad.net/bugs/1183807
<cjwatson> I've added a debhelper task
<cjwatson> lxc will need to be rebuilt after it's fixed though
<hallyn> cjwatson: great, thanks
<cjwatson> hallyn: Fancy trying http://paste.ubuntu.com/5697031/ ?
<hallyn> building
<hallyn> d'oh, clerical error.  retrying
<hallyn> (had built debhelper, then built lxc... without installing the debhelper pkg :)
<hallyn> alas, still no lxcbr0
<hallyn> cjwatson: ^ :(
<cjwatson> hallyn: Can you put the resulting .deb somewhere for me?
<hallyn> cjwatson: but the test in http://paste.ubuntu.com/5697031 is for '-x /etc/init.d/*.conf', but none of those are executable
<hallyn> sure, you mean the lxc deb right?
<hallyn> cjwatson: http://people.canonical.com/~serge/lxc_0.9.0-0ubuntu9_amd64.deb
<cjwatson> hallyn: No, the test is -e /etc/init/*.conf ...
<cjwatson> (ignore the LHS)
<cjwatson> oh, it's not being substituted properly
<cjwatson> hallyn: http://paste.ubuntu.com/5697103/
<aa10123> wedgwood:
<hallyn> cjwatson: success!
<hallyn> no wait
<hallyn> yup, success
<cjwatson> hallyn: OK, thanks - uploaded
<bdmurray> doko: dobey mentions that bug 1171568 was fixed by a version of sqlite3 in saucy.  could we get that SRU'ed?
<ubottu> bug 1171568 in sqlite3 (Ubuntu) "libsqlite3-0 3.7.15 breaks u1db tests" [High,New] https://launchpad.net/bugs/1171568
<hallyn> cjwatson: so lxc needs a rebuild-only upload?
<cjwatson> hallyn: It will do after debhelper has built and published
<hallyn> great, thanks
<xnox> bdmurray: I disagree, that it fixed anything.
<xnox> still FTBFS in sbuild here.
<xnox> commented on the bug report.
<bdmurray> xnox: kay, thanks
<tvoss> slangasek, ping
<cjwatson> hallyn: you can safely upload lxc now
<cjwatson> roaksoax: ^- you were asking about what turned out to be the debhelper part of bug 1183807 the other day too - fixed now
<ubottu> bug 1183807 in lxc (Ubuntu) "lxcbr0 is not created on package install" [High,Triaged] https://launchpad.net/bugs/1183807
<hallyn> cjwatson: oh, i misunderstood you before then.  ok, will upload
<cjwatson> misunderstood how?  (out of interest)
<roaksoax> cjwatson: awesome! thanks!
<hallyn> cjwatson: "hallyn: It will do after debhelper has built and published" I thought you meant a rebuild will be triggered automatically
<hallyn> :)
<cjwatson> Oh I see
<cjwatson> Sadly we don't have automatic rebuild support
<cjwatson> So the best I could have done (but didn't) would have been cron.cjwatson ;-)
<hallyn> :)  cool, pushed.
<hallyn> still don't see why pull-lp-source is being so flaky for me, on several (but not all) hosts.  I'm just defaulting to dget from the launchpad publishing history
<tvoss> slangasek, ping
<alexbligh> When building stuff with pbuilder etc., how does it persuade debootstrap to use (e.g.) precise-updates as well as precise. IE how do you know you aren't building using a buggy version of gcc or against a buggy static library?
<dobey> alexbligh: i run pbuilder-update before every build. but precise has -updates and -security enabled by default, so the chroot will also have them enabled by default. just run the update regularly
<alexbligh> OK - so it relies on pbuilder-update. Thanks. I was hoping there was a way to persuade debootstrap to produce up to date builds out the box. Oh well. I think I need to try multistrap then.
<cjwatson> I know pbuilder is hideously inefficient but it doesn't debootstrap every time.
<cjwatson> That would be a bit much.
<slangasek> tvoss: hi
<alexbligh> cjwatson, nah I was seeing whether pbuilder had solved the problem I was looking at. I want to do a debootstrap (or better a cdebootstrap) to build an image using precise AND precise-updates. I was just hoping someone had fixed this for pbuilder.
<slangasek> cjwatson, infinity: hmm, evidently I missed that dh_installinit question before... so under Debian policy, there should no longer be any "upstart-only" jobs, but I believe the dh_installinit bits were written to work anyway if you do have one
<cjwatson> You definitely shouldn't use cdebootstrap for anything - it's obsolete.
<cjwatson> The last useful innovation it introduced was incorporated into debootstrap in 2005.
<alexbligh> cjwatson, the innovation I want is looking at more than one repo. But I don't think it does that either.
<cjwatson> For debootstrap I'd probably just write a trivial wrapper which makes sources.list look the way you want it and then run an update.
<alexbligh> that actually doesn't work well. Firstly, my image which I am trying to keep small ends up with the ghosts of packages removed. Secondly there are packages like linux-image-current-generic which are not actually in precise, but that's (obviously) exactly what you want to install. 2 kernel packages inflates the size of the image quite a lot.
<alexbligh> I am trying to get away from running anything in the image (chroot or otherwise).
<phillw> Hi, sorry about this, as I am sure I have asked before.. is the usage of xdg-open no longer suggested for 'quick-links' such as those on "Easy Install" https://help.ubuntu.com/community/RestrictedFormats
<mterry> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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: mterry
<genii-around> I want to modify the !wubi factoid but would like to double-check here for facts...   as I understand, wubi is no longer supported from 13.04 onwards, but I still see it for instance at http://releases.ubuntu.com/raring/wubi.exe  . So: Is it in fact dropped, or no longer in the iso image? Also, does the wubi.exe for Raring work or is it some carryover from previous versions?
<slangasek> genii-around: it was released with 13.04, but has been de-emphasized on the website due to the lack of support for Windows 8 / SecureBoot
<genii-around> slangasek: OK, thanks. Will it be in Saucy ?
<slangasek> genii-around: I expect it will be; there seem to be developers committed to keeping it in working order
<genii-around> OK. Thanks again
<phillw> hi slangasek sorry to attempt a kidnap, but is xdg-open no longer used?
<slangasek> phillw: can't say I know the answer to that; I've never used it directly
<slangasek> phillw: it's certainly still part of the ubuntu-desktop seed, so I don't know of any reason it would be "no longer used"
<phillw> slangasek: so, I should report a bug as to it not working?
<lifeless> phillw: of course
<phillw> I'll try it in FFox and Chomium.
<slangasek> phillw: if it's not working, then yes, that's a bug
<slangasek> whether the bug is resolved by fixing the tool or removing it, is for the developers to decide
<phillw> slangasek: It seems to be a chromium bug, Firefox does not report it. as ubuntu are considering using chromium I will report it against that. As ever, thanks for the input :)
<TheLordOfTime> slangasek:  are you able to confirm that 'ubuntu-bug' is correctly checking versions of packages?  also, can you dig around on the saucy archive and confirm that the version of "chromium-browser" in saucy is 25.0.1364.160-0ubuntu3 ?
<TheLordOfTime> slangasek:  phillw tried `ubuntu-bug chromium-browser`and it said they were using a third-party package.
<cjwatson> Doesn't require any privilege to dig around.  $ rmadison -s saucy chromium-browser
<cjwatson> chromium-browser | 25.0.1364.160-0ubuntu3 | saucy/universe | source, amd64, armhf, i386
<cjwatson> (I'm not going to look at ubuntu-bug at the moment though, end-of-day)
<TheLordOfTime> cjwatson:  no, but it needs access to the internet beyond what I can do via SSH-to-my-system-from-my-phone
<TheLordOfTime> okay, that's what i thought, if ubuntu-bug had randomly broken, i'd be appalled and probably be the first to complain :P
<shakaran> Hi, I notice that apport detects crashes in 13.10, but after send the report it nevers open the browser in launchpad. How I can trace/fix this wrong behaviour?
<TheLordOfTime> i'm not as familiar with bug triage for "Update software to X.Y.Z" bugs, should this be Wishlist / Triaged, or at least "wishlist"?  https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1183086
<ubottu> Launchpad bug 1183086 in chromium-browser (Ubuntu) "Please update to 27.0.1453.93" [Undecided,Confirmed]
<TheLordOfTime> actually, regarding that bug there... has anyone tested the version of that in debian unstable on 13.04?
<TheLordOfTime> according to packages.qa.debian.org, unstable has 27.0.1453.93-1 in unstable.
<TheLordOfTime> s/13.04/13.10/
 * TheLordOfTime groans at his fail.
 * ScottK looks around for the LART.
<stgraber> slangasek: hey, so I ended up being TIL on nfs-utils after sponsoring a small patch last cycle. I have done the merge here but can't easily test it and that's a new upstream version with quite a bunch of changes on the Debian side.
<slangasek> stgraber: can you throw it up as a UDD mp for me to look at later?  Probably not until Monday evening - I won't get to it today and I'll be away from home all weekend
<stgraber> slangasek: sure
<shakaran> If there are some eclipse ubuntu maintainer here, just bumping this https://bugs.launchpad.net/eclipse-ubuntu/+bug/1183998
<ubottu> Launchpad bug 1183998 in Eclipse for Ubuntu "Please kindly update Eclipse to 4.2" [Undecided,New]
<stgraber> slangasek: Launchpad encountered an internal error during the following operation: generating the diff for a merge proposal.  It was logged with id OOPS-69c17ff685621f498e8fd63388bec9ff.  Sorry for the inconvenience.
<stgraber> slangasek: got that from LP after I sent the MP, so looks like you won't have a diff, sorry
<slangasek> stgraber: heh, that's fine; I was going to pull it down and review+build+install anyway
<stgraber> slangasek: oh, I see the problem, LP assumed I wanted to merge my branch into lp:debian/nfs-utils, will retarget the MP, that may end up fixing the diff as a side effect
<mterry> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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:
<slangasek> stgraber: ok, cool
<infinity> Man, I wish compiz would crash more today, it's really exciting...
<phillw> infinity: I can try in VM if there are any cases you wish testing
<slangasek> infinity: bug #1181717? or another?
<ubottu> bug 1181717 in unity (Ubuntu) "compiz crashed with SIGSEGV in g_object_unref()" [Critical,Confirmed] https://launchpad.net/bugs/1181717
<infinity> slangasek: That'd be the one.
<slangasek> infinity: this looks suspiciously like a gobject/gint casting failure; are you on amd64 too?
<infinity> slangasek: I am, yeah.
<infinity> Bug #1181324 is driving me nuts too, but only in that "gah, apport, stop yelling at me" way, whereas the compiz one is actually preventing me from working. :P
<ubottu> bug 1181324 in notify-osd (Ubuntu) "notify-osd crashed with SIGSEGV in bubble_get_id()" [Medium,Confirmed] https://launchpad.net/bugs/1181324
<infinity> Well, the second one's preventing me from watching movies after work which is, arguably, almost as important for my sanity.
<slangasek> right
<infinity> Also vaguely related, anyone know how to get my indicator panel back after a total unity explosion, or am I going to have to log out?
 * infinity sucks it up and starts closing windows to log out.
<slangasek> well, in my total explosions, compiz has died and left me with no control via X, so I've switched to vt1 and respawned it; that lets compiz run but doesn't have the right dbus environment for the rest
<jcastro> infinity: `setsid unity` ftw
<jcastro> always works for me
<infinity> slangasek: Ctrl-Alt-T still worked enough for me to re-run unity.
<slangasek> hmm
<slangasek> so maybe Ctrl-Alt-T is also not giving the right environment?
<slangasek> (such bugs have occurred before)
<infinity> Possibly.
<infinity> I find my lack of panels disturbing, at any rate.
<infinity> It's creepy having a blank bar up there with no clock.
<slangasek> ah, I haven't had that particular failure
<slangasek> when it fails for me, I get no window decorations and no bar at all
<infinity> That's what I had initially.
<infinity> Then ctrl-alt-t and ran a new unity.
<infinity> And now no menus or indicators.
<infinity> Entirely possible that I failed to run unity in some sort of "I like having stuff" mode.
<slangasek> right, I mean even after restarting compiz, I have window management (because I can click on a terminal), but no decorations
<infinity> But also short on patience and will likely just reboot soon. :P
<infinity> slangasek: Are you running compiz or unity?  I'd expect a raw compiz to land you about there (management, but no pretty).
<slangasek> infinity: ah, I was running it as 'compiz', which DTRT when launched from within the X session
<infinity> Anyhoo.  Advanced recovery of broken window managers is so 1998.  I think I'll just hope for a bug fix instead.
<slangasek> so for my part, I can't see what package changed on my system recently that would correspond to this
<infinity> slangasek: glib?
<slangasek> seems unlikely
<slangasek> given that nothing else is falling over
<infinity> I've had nautilus crashing too.
<slangasek> according to https://errors.ubuntu.com/problem/10d5e9a86a0f811a645c6fd60ca2dc94bf3c0462, this crash was seen as far back as Apr 27
<infinity> slangasek: Hrm.  So could just be "new" to me because I rarely log out and/or reboot.
<slangasek> right - it first showed up for me on May 19, my last reboot before that was May 17; so I'm trying to see what I upgraded in between that might be to blame
<infinity> I have no idea when it first happened for me. :/
<infinity> Does errors have a "look up everything I submitted" thing?
<slangasek> I know when it first happened for me, because I filed a bug report immediately ;)
<slangasek> infinity: if you know your UUID it might be queriable
<slangasek> bdmurray: ^^ ?
<psusi> cjwatson, in grub2, deviceiter.c seems to be in an ubuntu patch, restore_mkdevicemap.patch, which has no DEP3 header.. could you help me understand what this patch is for, and why deviceiter.c isn't part of upstream grub2?
<slangasek> interesting, the first crash report from April 27 has a GNOME prerelease ppa enabled
<cjwatson> psusi: Upstream deliberately removed device.map and all its evil works, but I had to glue it back in for a while to keep things like grub-pc.postinst and (IIRC) grub-installer working.  I'd like to remove it but those scripts need to be refactored in terms of ... something else first.
<infinity> I'm liking the "I don't reboot often" argument less, given that last(1) shows I rebooted on May 3, 7, and 17.
<infinity> And I always fully update before I reboot.
<cjwatson> The version of deviceiter.c we're carrying is basically the last one before upstream removed it.
<cjwatson> (And it's a Debian patch, not an Ubuntu one.)
<psusi> cjwatson, ohh... I know we prefer not to have device.map anymore, but I didn't realize upstream had removed all support for it... I'm specifically looking at the part of it now that identifies dmraid devices.. it needs a fix.. but if upstream doesn't have this file at all, how would it identify dmraid devices?  I thought that this code was used to dynamically identify devices, with or without a device.map
<cjwatson> psusi: There are other interfaces in GRUB that deal with finding devices without the particular form of interface in deviceiter.c
<cjwatson> Which is "enumerate all devices we recognise that are provided by the OS"
<psusi> so this other mechanism needs enhanced to detect dmraid disks for upstream to do so, and so we can drop that patch eh?  where is this other mechanism?
<cjwatson> That isn't needed at boot time, and even most OS-side tools in GRUB only need to be able to come up with a stable way to refer to things
<sarnold> infinity,slangasek, I believe this should do it: http://errors.ubuntu.com/user/`printf $(sudo cat /sys/class/dmi/id/product_uuid)|sha512sum`
<sarnold> (though it finds nothing for me, which I find hard to believe. :)
<cjwatson> Well, there's no other mechanism to enumerate all OS devices recognised by GRUB that I'm aware of
<infinity> slangasek: So, the first three I checked all have an updated glib.  Going to keep poking...
<cjwatson> We'd have to invent something that's less horrible than device.map was
<cjwatson> And maybe refactor on top of things like blkid or other similar facilities, I don't know
<cjwatson> It's not something I've given much thought to because that patch hasn't required very much maintenance
<infinity> sarnold: Yeah, nothing for me either, so that seems like it's not right. ;)
<sarnold> Darn. :)
<slangasek> infinity: hmmm; I upgraded libglib on 15 May, so that's not a perfect fit for the timeline here
<cjwatson> For the meantime the right answer is just to amend the Debian patch as needed
<cjwatson> Happy to take patches to the DM-RAID code there as long as somebody explains why they're correct :-)
<infinity> slangasek: But when did you restart compiz?
<slangasek> infinity: no later than the 17th when I rebooted
<slangasek> which is 2 days before my first bug hit
<infinity> slangasek: Kay.  Well, I can't seem to find a single crash that doesn't involve glib 2.37 ... Could be a red herring, but it seems damning.
<infinity> slangasek: And the graph takes a steep climb when that got uploaded to the archive.
<infinity> slangasek: You could just have been lucky until your first hit?  It's not like it crashes every 20 seconds.
<slangasek> infinity: right.  So, downgrade libglib and see?
<cjwatson> Ubiquity needed a fix recently for a reference counting bug
<cjwatson> Which started crashing in its testsuite, although it was definitely (in my assessment) ubiquity's problem and had basically always been wrong
<cjwatson> This is ubiquity 2.15.3
<cjwatson> So it's possible glib2.0 had a refleak fix which has exposed bugs in other things too
<infinity> This doesn't sound implausible at all.
<infinity> Given the name of the symbol with the segv. :P
<slangasek> cjwatson: hmm.  The stack trace does look like a 32-bit "pointer" on a 64-bit system, though
<cjwatson> Quite
<infinity> slangasek: It's crashing on i386 too.
<slangasek> ah
<cjwatson> slangasek: Could be an artifact of memory having previously been cleaned up, though
 * slangasek nods
<cjwatson> I don't know, haven't looked at this crash in detail
<cjwatson> But IIRC the Ubiquity one looked a bit like that at first glance too
<infinity> Do we have a retraced version of this backtrace anywhere?
<slangasek> the one on the bug report is retraced
<infinity> Ahh, in the bug.
<infinity> Yeah.
<infinity> Oh, but no symbols for libunityshell.so, that sort of renders that useless.
<slangasek> infinity: ?  https://launchpadlibrarian.net/140437248/Stacktrace.txt
<infinity> Silly me, I was looking at the thread stack trace...
<infinity> Or, no, I was just looking at an earlier one in the log.
<psusi> cjwatson, yea... remember how I changed dmraid in 12.04 to use kpartx to activate the partitions since it supported dmraid?  it sets the uuid of the partition to "partN-DMRAID-uuid" and parted-probe is looking for it to start with "DMRAID-" still...
<psusi> supported gpt rather
<cjwatson> explain> not on IRC at local-midnight :-)
<psusi> err, not parted-probe, grub-probe... pfft... how many mistakes can I cram into once line? ;)
<cjwatson> Sounds easy enough to fix though
<psusi> yea, guess I'll just change it to strstr
<psusi> instead of strncmp
<cjwatson> In my about-to-sleep state that sounds OK
<psusi> just burns me that installs to fakeraids have been broken since 12.04 and I'm just now figuring this out
<sarnold> psusi: is that related to this? https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1171945
<ubottu> Launchpad bug 1171945 in mdadm (Ubuntu) "Nested RAID levels aren't started after reboot" [Undecided,Confirmed]
<cjwatson> Glad you looked at that, since I'd probably not have got there
<psusi> sarnold, no, this has to do with dmraid/fakeraid, not mdadm
<psusi> is there a release manager around that can open the precise task for me on bug #1183915?
<ubottu> bug 1183915 in grub-installer (Ubuntu) "grub-probe confused by dmraid" [Critical,Triaged] https://launchpad.net/bugs/1183915
<cjwatson> psusi: done, and reassigned to grub2
<sarnold> psusi: aha, thanks. :)
#ubuntu-devel 2013-05-25
<psusi> ok... it seems the grub2 bzr repo is fscked... getting a bunch of dpkg-source errors about can not represent change, binary file contents changed just trying to bzr bd a clean branch of lp:ubuntu/grub2
<georgelappies> hi guys and gals
<georgelappies> just want to know if there is a fix / workaround for the non anti aliased fonts when running anything compiled with Qt5 on Ubuntu?
<georgelappies> seems kind of weird that the fonts have these issues as Qt5 is suppose to be the design platform for Ubuntu now ;)
<Kaleo> georgelappies: http://blog.qt.digia.com/blog/2012/08/08/native-looking-text-in-qml-2/
<georgelappies> thanks Kaleo much appreciated
<NikTh>  I want to thank all of you guys for your time and effort to solve a newbie's problems (mine). Fortunately I achieved my goal to upload a custom-kernel in a PPA of mine and it is a separate version (it not replace the official Ubuntu kernel).
<NikTh> https://launchpad.net/~nick-athens30/+archive/precise-optimized if you want to test. For the record, the secret here is the ABI . If you completely change this, then apt will recognize this kernel as a separate package. linux-image-3.2.0-440-generic :)
#ubuntu-devel 2014-05-19
<playdough> How do I get dpkg to not delay ldconfig on a package?  I think it has something to do with triggers, but I'm not sure how to generate my package.
<playdough> I put LDCONFIG_NOTRIGGER into a custom postinst, but the standard debhelper doesn't do this.
<playdough> All I have is a .install and let debhelper do the rest.  But when I install the package the ld.so.cache doesn't contain my library.
<RAOF> playdough: Why are you putting LDCONFIG_NOTRIGGER in?
<playdough> In order to force ldconfig to run.  Without it, ldconfig defers but never runs.
<playdough> Do I need an 'activate ldconfig' in a trigger file in my package?
<playdough> Wait.
<playdough> I think I may have tracked it down.
<playdough> Seems that our components group removed the ldconfig trigger from our internal libc package.
<playdough> I presume that when a package calls ldconfig it automatically activates the ldconfig trigger, no?
<pitti> Good morning
<pitti> Unit193: ah, thanks for finding out! mind filing a bug against initramfs-tools then?
<RAOF> playdough: I think that's right, yes.
<playdough> Ok.  That makes sense.  Removing the 'interest ldconfig' from libc-bin is causing all packages that invoke ldconfig to be ignored.
<Mirv> xnox: (qt without x) no, I don't have a straight answer to how to do that. it would probably need a lot of experimentating with qtbase-opensource-src's debian/rules, to switch from -xcb & -qpa xcb to something else (for arm) and trying builds without X deps
<zbenjamin> ted: did there anything change in application launching? Its not possible anymore to start applications from QtC.
<shadeslayer> bdmurray: ping, re https://errors.ubuntu.com/problem/1a794f4f0b1fa61aa9916353ae643de6085125fc in kde-workspace, upstream thinks its https://bugs.kde.org/show_bug.cgi?id=334152 , but has no fix since they can't reproduce the issue
<ubottu> KDE bug 334152 in activities "dangeling allActivitiesGroup pointer in useractions.cpp" [Crash,Confirmed]
<ted> stgraber, Hmm, is there an sqlite file in ~/.cache/url-dispatcher/ ?
<ted> stgraber, Hmm, I bet it's because there's no click packages.
<stgraber> ted: yeah, there's a sqlite db in there
<ted> stgraber, It's probably just getting built after 60 sec when we do the refresh.
<stgraber> ted: though both tables are empty
<ted> stgraber, That could be if nothing using custom URLs is installed.
<stgraber> ted: any way I can force that refresh somehow? as I have no way to get out of that unity8 session, I've put it on a 20s timeout then it VT switches back to my X session :)
<stgraber> ted: could be though I have the ubuntu-system-settings app in the dash and that one won't start...
<ted> stgraber, It's a couple Upstart jobs. There's url-dispatcher-refresh that signals url-dispatcher-update
<ted> stgraber, You can force a url-dispatcher-update
<ted> stgraber, Is it a new session each time? I'm curious if URL dispatcher is breaking itself, but my only theory there would be if the sqlite file didn't exist.
<ted> stgraber, On a second login, that should be fixed.
<stgraber> ted: yeah, it's a new session every time (I wipe .cache .local and .config)
<stgraber> ted: I'll add a manual url-dispatcher-update run to my script
<ted> stgraber, Hmm, I don't see anything obviously wrong :-/
<stgraber> ted: so my guess is that there's simply nothing doing an initial url-dispatcher-update run on first start, so you need to wait 60s before it works. As my session never lasts 60s, then it always fails for me.
<ted> stgraber, Yeah, that was my theory. But it looks like the service calls the create code correctly, so it should be fine.
<ted> stgraber, It wouldn't do custom URLs, but the application launching is hard coded.
<ted> stgraber, I think that error is loading the system settings custom URLs, which would effect the indicators.
<ted> stgraber, But it doesn't make sense for the white screen apps.
 * ogra_ sees utopic-changes and waits for doko to upload "burn" next 
<doko> that's called gcc
<ogra_> haha
<pitti> xnox: o, I just noticed your autopilot-gtk upload; I'm working on that too ATM, it needs some more adjustmends
<xnox> pitti: yeah,
<pitti> xnox: I'm also attempting to move it to py3, but I keep running into errors like http://paste.ubuntu.com/7488613/ ; no idea about that yet (nor has thomi)
<xnox> pitti: i was too hasty with it.
<xnox> pitti: we don't need autopilot-gtk in python3.
<pitti> so perhaps I'll propose my py2 fix first, and stash the py3 change, similar to bug 1320211
<ubottu> bug 1320211 in ubuntu-system-settings-online-accounts (Ubuntu) "port tests to python3" [Low,New] https://launchpad.net/bugs/1320211
<pitti> xnox: well, not "need", but we want to get rid of -legacy ASAP, I figure?
<xnox> pitti: we will never get rid of legacy.
<xnox> pitti: unity7 will be stuck using it, until we migrate away from unity7.
<xnox> (due to python2 tests of unity7 using crazy pyrex python2 modules to interface with compiz or some such)
<xnox> (4 deprecated technologies in one sentence =) )
<pitti> xnox: ok, I have the package build and autopkgtest work with -legacy now
<xnox> \o/
<pitti> (https://code.launchpad.net/~pitti/autopilot-gtk/update-tests/)
<xnox> upload =)
<pitti> xnox: well, MP :)
<pitti> giving the py3 port ten more minutes before I get frustrated too much :)
<xnox> pitti: i figured the r73, failed at figuring out r74 =) looks cool.
<pitti> xnox: yeah, sorry for the double work on r73; I didn't expect you (or someone else) to jump at this
<xnox> pitti: it's only blocking like gcc-4.9 from migrating =)
<doko> gcc-4.9 is blocked by the ppc64el ftbfs
<pitti> yeah, and blocking my sandbox-run fix, that's how I noticed
<pitti> xnox: https://code.launchpad.net/~pitti/autopilot-gtk/update-tests/+merge/220075 FYI
<pitti> xnox: oh, I just noticed your https://code.launchpad.net/~xnox/autopilot-gtk/fix-ftbfs/+merge/220045 -- yay collisions :/
<xnox> pitti: well, mine one can be rejected, but you do want to cherrypick the upload commit, maybe. just a tag.
 * xnox should really stop uploading crap that will just be stuck in proposed anyway.
<pitti> xnox: hm, that would look a bit weird in that MP (we don't usually add tags and debian changelogs to MPs)
<xnox> it does work.
<pitti> or we could just remove the -proposed upload
<xnox> pitti: true, won't be able to reuse the version number though.
<seb128> bdmurray, ev: something weird is happening on e.u.c daily's view again it seems
<seb128> the top entry has 48 reports
<seb128> that seems too low to be realistic
<bdmurray> seb128: some javascript was updated recently so maybe try a full refresh?
<seb128> bdmurray, what do you mean "full refresh"? that's happening in a new browser instance and consistently since this morning
<seb128> bdmurray, e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=day
<bdmurray> seb128: okay, I'm looking into it
<seb128> bdmurray, thanks
<bdmurray> seb128: its an issue with writing crash reports to the database
<bladernr_> Hey, who is responsible for spinning the netboot images? (Specifically the ones that appear at ports.ubuntu.com)??
<cjwatson> bladernr_: They happen as part of debian-installer package uploads.
<bladernr_> ahhh, is there any way to build on on our own?
<cjwatson> You can build debian-installer yourself.
<cjwatson> Just feed it to sbuild or whatever, or run "make -C build rebuild_netboot"
<mapreri> pitti: hi! I subscribe you to the bug #1319433, it's a really minor issue I introduced setting a wrong Replaces: field :)
<ubottu> bug 1319433 in xscreensaver (Ubuntu) "package xscreensaver-data 5.15-3ubuntu1 failed to install/upgrade: trying to overwrite '/usr/lib/xscreensaver/xlyap', which is also in package xscreensaver-data-extra 5.15-3ubuntu1" [Undecided,New] https://launchpad.net/bugs/1319433
<killer> Hey , I m tryinng to package an app in debian format , but I m getting an error on running "fakeroot dpkgpackage -F" .Here is the rules file http://pastebin.com/20996iy8 .
<geser> wgrant: Hi, could you sponsor bug #1321014 when you have a spare minute? Thanks.
<ubottu> bug 1321014 in snappy (Ubuntu) "Get rid of ancient timestamps in snappy 1.1.2-1ubuntu1" [Undecided,New] https://launchpad.net/bugs/1321014
<suudy> I'm trying to get plymouth working on our custom embedded system (i915 based) and am having trouble getting any output.
<suudy> plymouthd is running (plymouth --ping says it is alive), but the screen is blank.  The debug log doesn't show any errors.
#ubuntu-devel 2014-05-20
<luv> pitti: yo! can you please give me a shout when online? It's regarding https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1063617 (I see you raised it originally)
<ubottu> Launchpad bug 1063617 in compiz (Ubuntu) "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,Confirmed]
<luv> I already found two bugs in the compizconfig related to it. Doing more tests now. I will post a patch later this week.
* wgrant changed the topic of #ubuntu-devel to: Launchpad offline 06:00 - 06:30 UTC | Trusty Final released! | Archive: Open | 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:
<zyga> hello
<zyga> I have a .crash file, how can I add it to a launchpad bug report so that the various useful bots do their thing?
<zyga> I don't have access to the original machine anymore
<TheMuso> zyga: Perhaps unpack the crash file and upload the components as separate files manually?
<infinity> zyga: You can pass a .crash file as an argument to ubuntu-bug(1).
<wgrant> Or apport-collect, if the bug already exists.
<pitti> Good morning
<pitti> mapreri: right, that sounds urgent, will upload
<pitti> luv: *shout* :)
<zyga> thanks
<zyga> It looks like Qt5 crash on some deep internals
<zyga> hmm
<zyga> apport-collect rejects any action as I'm not the one who filed the bug
<zyga> TheMuso: can the .crash file be unpacked with any tool or is that a manual process?
<TheMuso> zyga: apport-unpack
<zyga> thanks!
<RAOF> Oh, arse. No autopkgtest for Debian experimental, I guess.
<zyga> so if I got that unpacked now, how can I get apport retracer to recover symbols and everything?
<RAOF> Also, boo, argyll is orphaned.
<zyga> though I already see symbols I'd like to see more details
<RAOF> zyga: Install apport-retrace, and it'll download the debugging symbols for you and give you a gdb session on the core.
<zyga> thanks
<zyga> RAOF: hmm, it borks on the bug (1318584) not having standard description format
<zyga> RAOF: would it help if I were to upload all the unpacked crash files to the bug report?
<zyga> (as attachments)
<pitti> infinity: hey Adam
<infinity> pitti: Yes dear?
<pitti> infinity: could you put http://people.canonical.com/~pitti/tmp/eglibc.faster-autopkgtest.debdiff into eglibc's VCS?
<pitti> infinity: that'd be lovely, honey
 * pitti will do the same for the kernel now, which should shave off some 30 to 45 minutes from the test
<infinity> pitti: I can do that, sure.
* wgrant changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open | 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:
<pitti> apw: I have an updated autopkgtest for linux which makes the thing go 30 to 45 mins faster: http://people.canonical.com/~pitti/tmp/linux-autopkgtest/
<pitti> apw: I tried a debdiff, but debclean seems to have eaten my debian/changelog entry, so this just has the updated debian/tests dir and a proposed changelog entry
<mitya57> Mirv: When can I go ahead with qtwebkit update?
<infinity> pitti: The changelog entry goes in debian.master/changelog, not debian/changelog.
<infinity> pitti: Because the kernel is super special.
<zyga> ara: hey
<ara> zyga, good morning
<infinity> pitti: Does @builddeps@ work for Debian too?
<hyperair> huh this is weird
<hyperair> raring is EOL?
<hyperair> launchpad was rejecting my uploads to raring
<hyperair> in a PPA
<hyperair> but quantal went through
<hyperair> O_o
<hyperair> i don't recall quantal being an LTS release
<Unit193> That's where they changed down to 9 months, Quantal just went EOL now too.
<hyperair> oh right
<infinity> hyperair: quantal will start rejecting soon.
<hyperair> okay
<infinity> hyperair: It was officially EOL on the 16th, but I haven't closed it in LP yet for reasons.
<hyperair> i see
<infinity> pitti: Taking your silence as a "yes" and committing. :P
<Mirv> dbarth: mitya57 ^ asked about when he can upload qtwebkit 5.2 to utopic. can you think of a timeline at the moment when enough has migrated to oxide?
<pitti> infinity: sorry, was OTP (meeting with the guys in Malta)
<pitti> infinity: yes, autopkgtest has been in sync for ages, @builddeps@ works everywhere (also in ci.d.n)
<infinity> pitti: Kay, cool.  Committed upstream, then.  We'll filter that down to Ubuntu after the next experimental upload and merge (which should be this week).
<pitti> infinity: nice, thanks (it's not urgent)
<pitti> the kernel seems to hit the copy timeouts way more often than eglibc
<infinity> pitti: Yeah, I'm torn about all those tests.  I like the rebuild tests for glibc/kernel/gcc/binutils because I'm intensely paranoid about any one of those breaking the others, but they're also crappy tests to be triggered by anything BUT the toolchain.
<infinity> pitti: We were discussing in Austin that we'd really like a test stanza called "Triggers-By" or something, where these rebuild tests could be limited to specific packages instead of all rdeps.
<pitti> yeah; at the moment the test doesn't know why it was triggered
<pitti> passing that will get a lot easier in the AMQP based system
<infinity> pitti: Which also has the added bonus that this wouldn't have to work by accident (ie: there's no reason any of these packages actually are rdeps of each other, since they're all build-essential, it's just a fluke that there happen to be enough versioned deps to make it work)
<pitti> but not with our shoestring/rsync/jenkins machine
<pitti> infinity: yeah, I think we introduced some technically unnecessary linux-libc-dev build dep (or similar) to trigger the reverse dep check
<infinity> pitti: Oh, erk, I see the timeout you're talking about is why the current eglibc/amd64 failed. :/
<infinity> pitti: How likely is that to fail again if I retry?
<pitti> infinity: I already retried an hour or so ago
<infinity> I suppose I should just skiptest the thing(s) waiting on it, since I can read the log and see that it's fine.
<pitti> infinity: rather unlikely
<infinity> pitti: Oh, or you could retry. :P
<infinity> Nothing's waiting on it but the kernel, and that build was fine, so I think I'll skiptest the kernel for now.
<pitti> 1 hour 18 mins ago, to be precise (run #19)
<pitti> the full run takes ~ 4 hours
<infinity> Yeah, skipping.  I want to see the britney results before I sleep. :P
<pitti> infinity: yes, it's indeed the copying between VM and host which occasionally kills it (there's a timeout of 1 hour, and if the boxes are busy that might take that lnog)
<pitti> and 9p is really crappy :(
<infinity> I guess something like NFS is out of the question?
<pitti> infinity: I'm afraid so; it has a lot of assumptions on the VM (working and unchanged networking, daemons running) and would also need root on the host side, doesn't it?
<pitti> not sure if one can run an NFS server as user
<infinity> pitti: Oh, yeah, you want root on the host to make it go, I suppose.
<pitti> -ECANTHAVEROOT
<pitti> if I had root on the host I could use nbd
<pitti> and just mount the qemu imae
<pitti> image
<pitti> infinity: so at the moment 9p is still the bit which needs almost zero assumptions on the testbed and is still reasonably fast for most things
<pitti> i. e. I'd like to be able to run autopkgtests against someone's production VM image (all in snapshotting mode of course), or the Ubuntu live system, or what not
<michagogo> 10:21:11 <infinity> hyperair: It was officially EOL on the 16th, but I haven't closed it in LP yet for reasons. <--- How long do you expect that to be the case? Long enough to sneak in a fix for bug #1314616 ?
<ubottu> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,New] https://launchpad.net/bugs/1314616
<infinity> michagogo: Is there any point?  it's EOL anyway.
<infinity> michagogo: I assume the same bug existed in raring, and we're not fixing that either.
<hyperair> michagogo: you can always upload to precise and have people in the intermediate releases use the precise PPA
<michagogo> infinity: is it known (are there metrics or something) on how many users don't upgrade?
<infinity> michagogo: If users don't upgrade, there's not much we can do for them.
<michagogo> Actually, guessing not because I don't think I've noticed an option for it
<michagogo> infinity: sure, but it would be interesting to know if there is actually a significant set of users running old unsupported releases
<infinity> michagogo: There are people still running all sorts of weird old releases, yeap.
<infinity> michagogo: I hear from time to time of people running maverick, natty, and oneiric, at least.  But, like I said, not much we can do for people who ignore EOL notices and don't seem to care.
<michagogo> infinity: I'm sure. I was more wondering, how many?
<apw> pitti, like the sounds of that
<pitti> apw: is the above enough, or do you need it in a different format?
<apw> pitti, that is sufficient indeed thanks.  your changelog woes are our layered debian thing, debian.<branch>/changelog ftw
<zyga> anyone interested in what is apparently a Qt5 bug?
<zyga> crash on 2nd monitor disconnect/reconnect
<doko> infinity, before you merge eglibc the next time, please remove the systemtap b-d for ppc64el, nice surprises like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
<ubottu> gcc.gnu.org bug 61231 in target "[4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu" [Normal,Unconfirmed]
<apw> pitti, ok applied, will be in the next utopic upload
<pitti> apw: very nice, thank you!
<zyga> cjwatson: do you know of any bugs on upstart leaking memory?
<zyga>  3102 zyga      20   0 3129116 2,852g   1404 S  13,7 18,6 198:29.19 init
<zyga> 3GB for upstart?
<apw> zyga, what release is that ...
<zyga> jodh: ^^
<cjwatson> zyga: -> jodh
<apw> jodh, ^
<zyga> apw: utopic
<zyga> one day uptime
<cjwatson> zyga: (I haven't heard of such a thing though)
<cjwatson> zyga: Oh, there's bug 1235649
<ubottu> bug 1235649 in unity (Ubuntu Saucy) "uevent spam causes libdbus client code in session upstart to consume massive amounts of memory on Ubuntu Touch" [Undecided,Confirmed] https://launchpad.net/bugs/1235649
<cjwatson> But that should be fixed in the packages
<zyga> seems like something new then
<apw> zyga, its not systemic, i have a uptopic here with 7 days uptime and both system and user init are under 10M
<zyga> oh
<zyga> I have media-hub-server crashing all the time
<zyga> like a few times a second
<zyga> perhaps that's why
<zyga> some process-exit leak?
<zyga> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1321204 and https://bugs.launchpad.net/ubuntu/+source/media-hub/+bug/1321203
<ubottu> Launchpad bug 1321204 in upstart (Ubuntu) "upstart (session) consumes almost 3GB of memory after 24 hours of uptime" [Undecided,New]
<ubottu> Launchpad bug 1321203 in media-hub (Ubuntu) "media-hub-server constantly crashes" [Undecided,New]
<ogra_> cjwatson, that was graphics driver specific ... only happened on the old galaxy nexus due to the driver calling vsync several times a second
 * ogra_ wonders if media-hub is actually supposed to be on desktop at all yet
<ogra_> zyga, you should talk to jhodapp (he's at the sprint so should be around in i.e. #ubuntu-touch)
<zyga> ogra_: thanks
<dbarth> Mirv: sorry (meetings)
<dbarth> Mirv: that's about updating qtwebkit for bugfixes? i'm not sure i have the right context
<jodh> apw: ack - awaiting zyga's response to my questions on the bug.
<Mirv> dbarth: yes, updating qtwebkit for other users besides phone. we did try 5.2 qtwebkit already before, and the only problem we had was OpenGL games. but it's even safer if we're satisfied with the amount of Oxide migrations done, so I'm wondering if we could give mitya57 some idea when the 5.2 could be allowed to go in.
<pmcgowan> cjwatson, hi can you approve my reply to ubuntu-devel list
<cjwatson> pmcgowan: done
<pitti> mbiebl: *sniff* Bug#747662: Removed package(s) from unstable :)
<pitti> (hal)
<pitti> and it only took like 5 years :)
<mlankhorst> infinity: ping?
<luv> pitti: hi .... you saw my message?
<pitti> 07:58:17      pitti | luv: *shout* :)
<pitti> luv: hi :) yes, I did, ^
<luv> haha :-)
<luv> should get my znc settings sorted out :-)
<luv> anyway, when I test on my other 14.04 box and I can confirm it fixes the issue (for me), I will attach patch to the issue. Or is here more to do?
<pitti> luv: that sounds good; the compiz devs can then turn it into a merge proposal etc.
<pitti> luv: I still get the issue occasionally, although I don't notice that much because my "start session" script has a bunch of gsettings calls to fix stuff
<luv> cheers
<pitti> seb128: are you aware that your e-d-s upload a week ago is stuck? friend's test started failing a week ago
<pitti>     Soup.MemoryUse.COPY, data, len(data))
<pitti> TypeError: set_request() takes exactly 4 arguments (5 given)
<pitti> seb128: could be because of your e-d-s upload or perhaps a change in soup?
<pitti> seb128: ah, https://launchpad.net/ubuntu/+source/libsoup2.4/2.46.0-2ubuntu1 landed on May 12, so probably it's that what broke friends
<mlankhorst> can someone review the NEW queue of precise? there's a xorg-lts-trusty stack there waiting to be accepted :-)
<michagogo> infinity: btw, which version is in quantal?
<michagogo> (it's gone from the packages page...)
<cjwatson> Still in +publishinghistory
<cjwatson> Top right
<michagogo> infinity: never mind, found it on https://launchpad.net/ubuntu/+source/bitcoin
<seb128> pitti, no, I was not aware, some days I wish we had email notifications for such things, thanks!
<seb128> pitti, likely libsoup yes
<seb128> pitti, I can try to have a look in a bit
<pitti> seb128: sorry that the pitti notificator has quite some lag
<pitti> seb128: at least it now expects one parameter less, so just pick which one to drop :-P
<ogra_> you need to work on that, seriously ...
<seb128> lol
<ogra_> also localized notifications please :)
<pitti> ogra_: richtig!
<pitti> seb128: le paquet "amis" est malade
<stgraber> :)
<seb128> heh
<mlankhorst> o.O
<pitti> le nouveau version de potage Ã  le cassÃ©
<mlankhorst> french is still not the default language pack, pitti!
<stgraber> I'm sure you could get google translate to give you "vos amis sont malades", that'd be slightly confusing ;)
<seb128> pitti, version est fÃ©minin
<pitti> seb128: ah, merci :)
<seb128> de rien ;-)
<pitti> mlankhorst: seb128 thinks otherwise
<mlankhorst> yeah we patch his copy of ubuntu
<ogra_> i'm wondering if someone has an explanation for the pm-utils/powermgmt-base dropping in http://people.canonical.com/~ogra/touch-image-stats/29.changes ... i went through all packages in that change-set, nothing dropped a dependency on these two ... there was no seed change either
<ogra_> (and since it is touch, there are no recommends in use, i can see no reason why they would/could be dropped)
<zyga> hmm, qtbase-opensource-src seems to FTBFS on utopic
<zyga> I was going to file a bug on that, adding libboost-regex-dev fixed it for me (on utopic)
<zyga> I tried to reproduce the failure in sbuild but I got a test failure instead
<zyga> wtf?
<zyga> can anyone more experienced than me just run a test build of qtbase-opensource-src on utopic and tell me if I'm seeing things?
<ogra_> zyga, there was an upload a few mins ago ... you could just watch it ;)
<brendand> zyga, what do you see?
<zyga> brendand: I saw
<zyga> FAIL!  : tst_qstandardpaths::testRuntimeDirectory() '!runtimeDir.isEmpty()' returned FALSE. () Loc: [tst_qstandardpaths.cpp(414)]
<zyga> ogra_: oh, thanks
 * zyga looks at the changelog
<zyga> brendand: and before I was seeing a missing linkage dependency on some test tool
<mterry> pitti, hello!  Do you know if it's possible to fake having a sim that needs to be unlocked for my mako device?
<pitti> mterry: yes, it is
<mterry> yay!
<pitti> mterry: for that you need to start ofono-phonesim with a different xml
 * pitti looks
<pancakes9> hey guys, I'm a new contributor
<pitti> - Modify default.xml: Set PINNAME from "READY" to "SIM PIN", set SC from 0 to 1, run phonesim with that
<pitti> - can be unlocked with /usr/share/ofono/scripts/enter-pin pin XXXX
<pitti> mterry: ^
<pancakes9> Am I in the right channel for asking for help on how to get started?
<pitti> mterry: you should talk to Wellark, I think he already set this up for some app
<mterry> pitti, thank you so much!  I'll try it out and bug Wellark if needed  :)(
<pitti> mterry: oh, and obviously PINVALUE (defaults to 2468, but you can change it of course)
<ogra_> pancakes9, probably #ubuntu-motu is better
<pancakes9> ogra_: thanks
<lool> would someone mind giving a quick look at: http://paste.ubuntu.com/7492987/ ?  sicne it's fakeroot I'd like another pair of eyes on it; I've tested that it fixes the issue and have done a test build with it (hello-debhelper)
<pitti> sil2100: do you know who landed unity-scopes-api? it apparently broke the unity-scopes-click test
<pitti> sil2100: with the autolanding we don't have proper uploaders and thus the usual autopkgtest notification mails don't work
<pitti> sil2100: i. e. unity-scopes-api is held back in -proposed due to that
<pitti> and the new unity8 too
<seb128> Mirv, ^
<seb128> ogra_, ^
<ogra_> pitti, Mirv
<seb128> (they were just discussing unity8 in ci-eng)
<pitti> Mirv: hello :) so please consider you notified
<Mirv> I did not land tha tone
<Mirv> so the scopes were landed by mhr3
<seb128> Mirv, but you were asking about unity8 not migrating
<Mirv> and I landed unity8 separately
<ogra_> oh, that was sil2100 actually
<pitti> jibel: seems I must gradually abolish my first "retry the test" reflex, except for the linux and eglibc timeouts I haven't seen an infrastructure failure since the apt-get race fix \o/
<ogra_> (-scopes-api)
<Mirv> seb128: yes, it seems we have the culprit then
<pitti> sil2100, Mirv: you guys know about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ? (in case you wonder where your landings are stuck)
<didrocks> pitti: you have sil2100 as the guy publishing it :)
<Mirv> pitti: yes, I was just not first assuming it's a real error since there have been various autopkgtest problems earlier last week and so
<didrocks> but we'll need to come to the discussion in Malta about showing off the guy clicking the package publishing or the lander :)
<pitti> Mirv: right, my usual first assumption is "broken infrastructure" too due to long training, so I still review every single failure :)
<Mirv> so is there an option of rejecting the scopes-api so that unity8 can pass?
<pitti> and then play pitti-notification-bot
<pitti> Mirv: we can remove bad packages from -proposed
<pitti> that might lead to bzr branches getting out of sync, though
<cjwatson> pitti: Autolandings should now have an at least somewhat useful sponsored field, FYI
<Mirv> yes I've noticed a lot of magic happening "automatically" (by you or colin)
<pitti> although you only really merge after it propagated, right?
<cjwatson> So it should be possible for autopkgtest to scrape that out
<pitti> hmm, https://launchpad.net/ubuntu/+source/unity-scopes-api/0.4.6+14.10.20140519-0ubuntu1 still only shows "buntu daily release <ps-jenkins@lists.canonical.com>
<pitti> oh, from https://launchpad.net/ubuntu/utopic/+source/unity-scopes-api/0.4.6+14.10.20140519-0ubuntu1
<Mirv> pitti: yes the merge & clean is only done after it's in release pocket
<pitti> Copied from ubuntu utopic in Landing PPA 011 by Åukasz Zemczak
<sil2100> I'm back
<sil2100> pitti: thanks for the info! uh!
<seb128> mhr3, hey
<pitti> Mirv: so yes, we can (and often have) remove stuff from -proposed when it introduced regressions; the version number will be "burned" then, and potentially the status needs to be updated in MPs/landings/etc.
<seb128> pitti, do you have a link to the test errors for mhr3?
<pitti> hey sil2100
<pitti> it's linked from excuses
<seb128> pitti, Mirv, sil2100: let's see if we can sort it out rather than deleting
<pitti> https://jenkins.qa.ubuntu.com/job/utopic-adt-unity-scope-click/40/ARCH=i386,label=adt/console
<seb128> mhr3, ^
<seb128> pitti, danke
<pitti> although there seems to be more than one problem there
<cjwatson> Mirv: Well.  I try to reduce the amount of stuff running from cron.cjwatson where I can ;-)
<pitti> Failed to get D-Bus connection (Cannot autolaunch D-Bus without X11 $DISPLAY)
<pitti> -> missing xvfb-run?
<pitti> the "g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
<pitti> and several test failures
 * sil2100 still reads the logs for the failure
<mhr3> the click failures are hardly caused by -api
<pitti> sil2100: that autopkgtest just builds the package, so it's FTBFS
<sil2100> pitti: that is strange, as it built fine in the PPA
<sil2100> Otherwise it wouldn't be publishable
<sil2100> hmm
<pitti> sil2100: was unity-scope-click built against the new unity-scopes-api?
<pitti> sil2100: by the time of the upload to Ubuntu it seems the last build happened against a previous scopes-api
<sil2100> Ah, crap, indeed, it was just scopes-api and scopes-shell
<pitti> anyway
<pitti> I'm really happy that this britney/adt stuff works fairly reliably now
<sil2100> Miss-checked that one, strange stuff
<pitti> turning "OMGwebroketheimage" into "let's take time and fix it properly without rush"
<dobey> hmm
<sil2100> Let me poke upstream about that one first thing
<sil2100> pitti: thanks for letting us know about this! The unity-scope guys already got informed and know of a possible fix
<pitti> nice!
<mhr3> pitti, so in this case there was an issue in -click's tests, and that now prevents -api to be published, not sure if such a failure should be automatically considered something fatal
<pitti> mhr3: we consider it fatal if a package's tests succeeded, and started failing if one of its dependencies got updated
<pitti> then we hold back that dependency
<pitti> there are certainly situations where it fails for a different reason, but the probability is quite high that this dependency update was the culprit
<pitti> mhr3: so if clicks' tests now fail due to something different, the release team can override that to let -api pass
<ScottK> pitti: seems to me the larger issue is non-devlopers having upload access to the archive via autolanding.
<ogra_> ScottK, only after a core-dev reviewed thee packaging changes
<ScottK> So?
<ogra_> (and an upstream dev had to cross review the upstream changes first)
<ogra_> thats not much different to sponsoring
<ScottK> Except for no Ubuntu devs look at it.
<mhr3> pitti, well, no, the system is right that the updated -api caused the -click's tests to fail, but they were doing something wrong in the first place
<seb128> mhr3, that still points to an issue somewhere (the tests in that case), and you can't know the reason is advance, so blocking is the right thing to do
<mhr3> pitti, it just feels that library developers are suddenly responsible for all rdeps
<seb128> mhr3, they are to make sure they don't create any bugs in their rdeps yes
<ogra_> ScottK, hmm ? you mean a core-dev isnt an ubuntu dev ? the landing cant go in unless a core-dev had nodded it off ... the only diifference to actual sponsoring is that the landing is done in piecemeal
<pitti> mhr3: of course not, if the -click test is wrong then the -click author should fix it
<pitti> but we can't just let in any uplaod which breaks a dependency, then the whole thing woudl be pointless
<ogra_> ScottK, so the core-dev never sees the full picture ... only the packaging changes ... which can cause issues like above
<mhr3> pitti, sure, but until that happens, others are blocked from using the new lib
<ScottK> oct
<pitti> mhr3: yes, intentionally (if it causes a regression or API change then it should not land yet)
<ScottK> Oops
<mhr3> pitti, don't get me wrong, it's good that we get notified about it, i'm just questioning the concept of auto-block
<pitti> mhr3: NB, I'm not saying that this did cause an API change, but the failure/holding back in -proposed would look exactly like that
<ogra_> nov :)
<pitti> mhr3: what would be the alternative?
<pitti> mhr3: it gets blocked, we investigate it, we might decide it's wrong and override it; or it's right and we need to fix something
<mhr3> pitti, guess it would have to be assessed on a case-by-case basis
<pitti> right, it is
<mhr3> alright, so there is the ignore button somewhere? :)
<cjwatson> mhr3: We fail safe and can assess and override case-by-case.  I don't see the problem
<mhr3> good to know
<pitti> mhr3: yes, as I said the release team can override it (it's a bzr commit)
<mhr3> k, then all is fine i guess
<cjwatson> Though generally in this kind of case I'd still prefer to see the rdep passing, to make sure that a test suite problem isn't masking something else
<ScottK> ogra: For sponsorship, an Ubuntu dev has the whole upload. For uploads with no packaging changes, who reviews that?
<ogra_> ScottK, upstream
<ogra_> the owning team of the upstream branch
<ScottK> Right. As I said, non-Ubuntu developers have upload rights.
<ScottK> Which violates the trust model of the distro.
<ogra_> well, with a lot more hurdles to take than dputting :) they are not actually uploading to the archive
<ogra_> and the change goes through the landing team first (which consist of devs and non devs admittedly)
<dobey> mhr3, pitti, cjwatson: well, it's clear why the test is failing, and the failure isn't masking an issue in the runtime click scope code. i think it's fine to "ignore" the failure in the click scope autopkgtest and push the scopes-api landing through, in this case, as long as click-scope is the only thing with broken tests
<ogra_> after all such a landing gets a significant amount more review than a core-dev doing a dput ... i wouldnt see the trust model violated but rather improved by this
<dobey> mhr3, pitti, cjwatson: so are we going to push scopes-api landing through despite the click-scope failure (which is a bug i can fix today), or do i need to propose a branch now and get click-scope in the same silo?
<cjwatson> dobey: Is there a branch somewhere that fixes the bug?
<sergiusens> cjwatson: is there an ETA for adding the click 14.10 framework?
<cjwatson> If it's fixable today, I'd honestly be more comfortable if we did that
<cjwatson> sergiusens: no
<sergiusens> cjwatson: there are breaking changes in the clicks, reason why I ask
<cjwatson> sergiusens: do you mean breaking changes in the platform?
<sergiusens> cjwatson: yes, in the content-hub
<cjwatson> ok, so that would be a good reason to do it
<cjwatson> lool: ^- any objection to me adding ubuntu-sdk-14.10-dev1 et al?
<dobey> cjwatson: nearly; i think fixing it directly in click scope trunk will result in a conflict with a branch that we landed in our devel yesterday, so i'd prefer to avoid that and merge into devel then merge devel into trunk (which has more changes than just this fix).
<sergiusens> cjwatson: does beuno need to do anything for this?
<cjwatson> sergiusens: I'm afraid I don't know
<mhr3> dobey, the fix is pretty tiny, no? if it can be done in <15minutes let's just do it
<dobey> sergiusens: yes i think the store db has to be updated with the new frameworks
<mhr3> dobey, then even the conflict will be tiny :)
<dobey> mhr3: yes the fix is tiny
<cjwatson> dobey: we should get the test failure fixed before landing further changes, IMO
<dobey> mhr3: i just switched away from my workspace where i have the code open, back to irce, and saw you discussing it with pitit here
<dobey> mhr3: so i didn't want to waste time making an MP and all, if it was just going to get ignored for the moment :)
<mhr3> dobey, it won't be ignored, the silo is waiting for it
<ogra_> ... and unity8 ... and the anticipated image build ...
<lool> cjwatson: not at all, I had it locally actually but waited for the new security permission implementation to land
<dobey> mhr3: https://code.launchpad.net/~dobey/unity-scope-click/fix-query-tests/+merge/220280 should fix it
<sergiusens> dobey: so there's no need to update anything in the click scope for a new framework
<mhr3> sil2100, got the fix, can you reconf 011?
<cjwatson> lool: ah, I don't know whether jdstrand is ready for it
<sil2100> mhr3: on it
<dobey> sergiusens: not in the scope itself, no. we read the frameworks from the system. the server db needs updated though, so people can actually upload clicks that use the new framework, iirc
<lool> cjwatson: ah actually motivation for the change is to pick up an ABI breakage, so discussing this here
<lool> ABI addition is ok, but not ABI breakage
<sil2100> mhr3: reconfigured
<sil2100> mhr3: you can build o/
<mhr3> sil2100, enough to build click itself?
<sil2100> mhr3: yes, I guess mentionin only u-s-c is what we would like
<cjwatson> mhr3: Hm?  I already have another silo containing click itself
<mhr3> cjwatson, sorry, i'm talking about click scope
<cjwatson> So you mean "enough to build unity-scope-click itself"?
<mhr3> yes
<cjwatson> OK
<lool> cjwatson: bottom line is that we're reverting the content-hub and corresponding browser changes to revert the ABI breakage
<cjwatson> OK
<cjwatson> mvo_: your click change to disable apps when their framework goes away works beautifully on my device
<cjwatson> I'm sure you knew that, but just for the record :)
<lool> cjwatson: mind looking at the debdiff I've put in LP #1290069 ?
<ubottu> Launchpad bug 1290069 in fakeroot (Ubuntu) "Bad identification of getopt in /usr/bin/fakeroot-sysv with some translations" [Undecided,In progress] https://launchpad.net/bugs/1290069
<cjwatson> lool: Maybe a bit later this afternoon
<cjwatson> (meetings etc.)
<lool> ok
<lool> pitti: would you by change have a minute to look at the debdiff in LP #1290069 ?
<ubottu> Launchpad bug 1290069 in fakeroot (Ubuntu) "Bad identification of getopt in /usr/bin/fakeroot-sysv with some translations" [Undecided,In progress] https://launchpad.net/bugs/1290069
<beuno> sergiusens, cjwatson, yes, I need to add it to the store so we can accept apps. Just say when.
<mvo_> cjwatson: \o/ thanks for confirming
<tarpman> luv: did you see the recent comments on bug 1063617? even if your patch isn't fully tested yet, might be worth posting your WIP to the bug (btw thanks for working on it!)
<ubottu> bug 1063617 in Compiz "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,In progress] https://launchpad.net/bugs/1063617
<luv> tarpman: cool ... I will post my findings and the patch this evening to save the guy the countless hours in gdb :-)
<tarpman> luv: thanks!
<luv> no probs :-)
<luv> just got so annoyed (and it has been in for almost two years! :-( ) so I just had to fix it
<Elv1313> Hi, can someone upload the patch for bug 1316612?
<ubottu> bug 1316612 in sflphone (Ubuntu) "SFLPhone-KDE will freeze if an Akonadi request deadlock" [Undecided,Confirmed] https://launchpad.net/bugs/1316612
<Elv1313> it is already confirmed and tested by 2 users, it probably affect ~40% of all sflphone-kde users, so I it would be nice if the process could be speeded up a little
<Riddell> Elv1313: I'm about to leave but if you e-mail me I can look at it tomorrow
<rbasak> Elv1313: you want to get that into the sponsorship queue. Attaching a debdiff suitable for applying to Utopic should do this automatically for you.
<rbasak> I was about to say that you could try poking a patch pilot on here when one appears in the channel topic, but it sounds like Riddell will help.
<Elv1313> Riddell: ok
<pitti> lool: sorry, was out for errands; looks good to me (and also upstreamable)
<lool> pitti: thanks
<Elv1313> rbasak: Thanks, pulling "bzr branch lp:sflphone" only give me the tranlations, is there a repository where I can pull/push patches or "debian/" scrips changes?
<rbasak> Elv1313: try "bzr branch lp:ubuntu/sflphone".
<rbasak> Elv1313: I tend to use debdiffs directly without bzr. For that, "pull-lp-source sflphone" will give you the current Utopic unpacked source package.
<rbasak> Elv1313: you'll want to add the patch to debian/patches, with dep3 headers so that future developers can trace the origin.
<Elv1313> rbasak: is it possible to also add them to trusty?
<rbasak> Elv1313: when you're done, you can submit a bzr merge proposal on Launchpad, or just attach the debdiff to the bug. For the latter, I think a bot will come along and subscribe ~ubuntu-sponsors to the bug, or you can do that directly.
<rbasak> Elv1313: you can see the sponsorship queue at http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html...
<rbasak> Elv1313: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for the process for updating Trusty.
<rbasak> Elv1313: in general Utopic needs to be fixed first, and backported fixes need to be high-impact or otherwise meet the criteria defined higher up on that page.
<rbasak> Elv1313: HTH.
<Elv1313> rbasak: So far errors.ubuntu.com found ~15 segfault of critical asserts for the gnome (sflphone) client and 2 deadlocks for the kde client. We have patches for ~5 of them so far, but most are stuck in unconfirmed launchpad bug reports. I think crashes are critical enough to get backported.
<rbasak> Elv1313: that sounds reasonable. The SRU team usually makes the decision based on the bug description after upload.
<rbasak> Elv1313: so just be sure to justify it in the bug, and you should be OK. It's mainly the trade-off between the bug impact and the regression risk that matters.
<Elv1313> we will have a new release in time for Utopic, so there is little point to push those fixes into 14.10
<rbasak> The risk is that it won't make Utopic, and then Utopic will regress the fixes pushed back to Trusty. I think that's the reason that it's generally required to be fixed in Utopic first.
<rbasak> So I guess you can wait on the new release in Utopic before fixing Trusty, or fix Utopic with the patches now, or get an exception from the SRU team.
<Elv1313> ok, thanks
<sl33k_> I want to volunteer contributing code, triage bugs. Would I be able to help with less relevant experience?
<Elv1313> sl33k_: helping getting bug fixed faster if the most helpful thing there is
<rbasak> sl33k_: there are a ton of bugs with a "please provide a patch" type status. Help with these would be most welcome.
<Elv1313> sometime, simply getting in contact with an upstream dev is enough. They may not be aware fo the issue or it might already have been fixed, but never backported
<mapreri> pitti: thanks :) (even if I'm wondering which hours you work: I did not image you work during "office hours"...)
<xnox> mapreri: it is office hours =) just without timezone defined ;-)
<zyga> hmm, is python-virtualenv just broken now on utopic or did I mess up my system somehow?
<dobey> is there anyone i can beg to accept some SRU packages to their appropriate -proposed channels?
<zyga> http://pastebin.ubuntu.com/7494459/
<dobey> zyga: not a useful or definite answer, but i only want to reply with "yes" :)
<zyga> barry: ^^ ?
<zyga> dobey: well, less strict parsing may be needed ;)
<zyga> barry: is that wheel related by any chance?
<dobey> zyga: why are you running python3 code in a 2.7 virtualenv?
<zyga> dobey: I
<zyga> dobey: I'm running what used to work: virtualenv -p python3 /some/path
<zyga> dobey: worked from 12.04 till yesterday
<dobey> huh
<zyga> dobey: that's *the* way to get a useful python3 virtualenv AFAIK
<Unit193> pitti: On initramfs-tools?  I'd think busybox as zz-busybox runs before busybox.
<barry> zyga: not that i know of.  none of the wheels stuff has landed in debian yet (in progress).  it won't affect virtualenv anyway, just pyvenv
<Unit193> (I put a dep from the one on the other, fixed.)
<barry> zyga: seems to work for me
<zyga> barry: can you check if that's broken on your (utopic) box by any chance?
<zyga> hmmm
<dobey> sigh. why are simple SRUs so hard to do?
<zyga> dobey: I feel your pain
<barry> zyga: virtualenv -p python3 /tmp/pp
<barry> source /tmp/pp/bin/activate
<barry> pip install nose2
<barry> all seems happy
<zyga> barry: it crashes for me as linked above
<zyga> python-virtualenv changelog is old so nothing new landed lately
 * zyga has installed python-configparser lately though, let's see if removing it helps
<dobey> that could certainly result in what you are seeing
<zyga> dobey: yeah
<zyga> confirmed
<zyga> removing python-configparser fixes it
<dobey> is that some "let's backport the new python3 module to python2" thing?
<zyga> barry: yeah
<zyga> barry: can you install and check it happens on your copy too
<zyga> oh, it's probably being imported
<zyga> and the code doesn't fall back to 2.7 imports
<zyga> or equivalent stuff
<zyga> sounds plausible
<zyga> yeah, exactly
<zyga> damn :) I need that package and working virtualenv
<zyga> :-)
 * zyga wonders what to do
<dobey> why do you need that package?
<zyga> dobey: checkbox-support needs it to work on python2.7 which is a new requirement for us so we just have to have it :/
<zyga> dobey: (it's 3.2+ right now)
<zyga> dobey: well, 101 patches make it 2.7+ compatible though
<dobey> zyga: can't you just do the appropriate try/except in checkbox directly?
<zyga> https://code.launchpad.net/~zkrynicki/checkbox/fix-1319767/+merge/220318
<zyga> dobey: that's a virtualenv problem though
<zyga> dobey: oh, you mean to use the old import name
<zyga> hmm
<zyga> maybe
<dobey> yes, that's what we did in u1 stuff
<zyga> good idea, I will probably do just that
<dobey> i generally try to avoid those "py2.7 compat versions of py3 modules" things because they tend to cause more problems than not (like the one you're having now) :)
<zyga> still that package is broken
<zyga> dobey: well, I tend to avoid 2.7 entirely ;)
<zyga> they should always have different import name
<dobey> well i guess there's a reason it's not in corelib
<zyga> I mean, come on
<zyga> dobey: configparser?
<zyga> dobey: it is in python3
<dobey> well whatever package that is, yes
<zyga> dobey: corelib I assume that's python stdlib?
<zyga> (or am I mistaken and you meant something else)
<dobey> yeah i meant std lib
<dobey> configparser is in python2.7 and ConfigParser is in python3.
<dobey> so there shouldn't be any need to install a "python-configparser"
<dobey> especially one that breaks things
<zyga> ah, I understand your comment now then
<zyga> yeah, I didn't check, I just assumed it's not in 2.7 and there's a 3 backport
<zyga> I'll get rid of it
<dobey> python-configparser is a package that is the result of someone trying to be clever, but actually being stupid :)
<dobey> some of those are literally just someone ripping the code straight out of py3, adding a setup.py to install it in 2.7, and calling it a day. no tests or guarantee that it works or anything
<barry> zyga: sorry, got stuck on the phone
<zyga> barry: no worries, I think a debian bug is in order on python-configparser, I'll try to sort that out
<dobey> ugh, someone packaged it in debian? even worse :)
<barry> zyga: LP: #1156704
<ubottu> Launchpad bug 1156704 in python-virtualenv (Ubuntu) "Virtualenv breaks if python-configparser is installed" [Undecided,Confirmed] https://launchpad.net/bugs/1156704
<zyga> barry: it's quite old!
<barry> zyga: yeah.  i'll see if i can spend some time on it
<barry> it's been on my backburner for a while ;)
<dobey> rm /pool/p/python-configparser*
<dobey> problem solved!
<zyga> oh yeah
<zyga> please
<zyga> unless the backport has some new code that has merit
<barry> it would be for bilingual code
<dobey> not really
<zyga> barry: if the 3 rewrite and backport has any extra features, otherwise virtualenv, which is bi-lingual just chokes on the code
<dobey> bilingual code would do the right thing and "try: import ConfigParser except ImportError: import configparser as ConfigParser" or similar
<barry> actually, it looks like there are few revdeps on python-configparser, and configglue isn't one of them any more
<zyga> yeah, there are three
<dobey> taking the code from py3 stdlib and shoving it in py2 doesn't make code "bilingual"
<barry> zyga: so "apt-get purge python-configparser" ? :)
<dobey> yeah, i think i complained loudly about configglue doing that at some point
<zyga> barry: yeah, already did that
<barry> \o/
<mikey85> I was banned from like every Ubuntu because of ikonia throwing false statements at me
<mikey85> I have proof
<mikey85> http://irclogs.ubuntu.com/2014/05/20/%23ubuntu.txt
<sarnold> mikey85: try #ubuntu-irc or #ubuntu-ops
<mikey85> I've been banned in both
<sarnold> mikey85: it would be better to bring your own logs, because the irclogs don't include your hostmasks.
<mikey85> ikonia has been wreeking havoc on me
<Corey> mikey85: You're rapidly becoming a cross-channel problem. Please desist.
<mikey85> no corey
<mikey85> you guys have been accusing me falsely
<sarnold> mikey85: note though that even though it does appear someone was impersonating you, you did not appear to take advice well.
<Corey> mikey85: There's a process to appealing op decisions within Ubuntu; this isn't it.
<mikey85> But still, they can atleast hear me
<mikey85> she's going to get me banned on every Ubuntu chan and I can't let that happen
<Corey> mikey85: You're doing it to yourself at this point. Please desist.
<mikey85> corey leave me alone please
<sarnold> s/did not/do not/ ... sigh. thanks Corey.
<roasted> hello
#ubuntu-devel 2014-05-21
<mterry> Laney, did you drop the filtering_out_users patch from accountsservice on purpose?
 * Logan_ pokes siretart 
<Logan_> can we sync libav?
<Logan_> our only delta can be dropped
* wgrant changed the topic of #ubuntu-devel to: Launchpad offline 06:00 - 06:30 UTC | Trusty Final released! | Archive: Open | 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:
<pitti> Good morning
<pitti> mapreri: well, it's always office hours somewhere on the world :) (I'm in Germany)
<Unit193> Howdy.
<pitti> hey Unit193
<pitti> xnox: oh BTW, yesterday I figured out the trouble with the py3 AP porting; so once the next autopilot lands in utopic, I'll update shotwell, autopilot-gtk, and ubuntu-system-settings-online-accounts to python3
<pitti> xnox: I have the patches already more or less, they just need the autopilot3-sandbox-run
<Logan_> hey pitti :)
<pitti> hey Logan_, how are you?
<Logan_> doing well, you?
<pitti> quite fine, thanks
<pitti> apw: I did the same for linux-exynos5 and also restricted the test to armhf (it will always fail on x86); files are again on http://people.canonical.com/~pitti/tmp/linux-autopkgtest/
<tvoss> pitti, ping
* wgrant changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open | 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:
<Logan_> doko: FYI, you filed a bunch of dh-autoreconf bugs in Debian twice
<Logan_> I'm merging them as I come across them
<pitti> tvoss: sorry, missed your ping; hello
<tvoss> pitti, hey there :) sorry, forgot what I meant to ask you :)
<pitti> tvoss: heh - contentless pings FTL :/
<tvoss> pitti, fair
<geser> dholbach: Hi, re bug #1320612: it looks like your german locale slipped into the test suite. Based on the failure log I guess it could be fixed by setting the locale to "en_US" (like the previous test) but is it worth an additional Ubuntu delta?
<ubottu> bug 1320612 in python-babel (Ubuntu) "Merge python-babel 1.3+dfsg.1-3" [Undecided,Triaged] https://launchpad.net/bugs/1320612
<dholbach> geser, hum... wouldn't this affect users of a non-English Debian session as well?
<geser> only when running the test-suite I guess
<geser> of course I would forward this to Debian or upstream
<dholbach> geser, sure... I meant users of a non-English Debian session who are trying to run a build
<dholbach> geser, if you want, I can try to build it again locally with LC_ALL=C and see if that works
<dholbach> but it sounds like a bug to me to expect en_US in the testsuite
<geser> yes, I'll try to fix it and forward it to Debian. Should this block the merge for now?
<dholbach> geser, no, I'll do another test build now
<dholbach> thanks
<dholbach> geser, hum
<dholbach> geser, 2ubuntu1 builds fine, 3ubuntu1 won't build, even not with LC_ALL=C
<dholbach> ah of course - "Runs the unit test on build (Closes: #727616)" :)
<geser> dholbach: hmm, why does my pbuilder have no problem in building this package?
<dholbach> I have no idea
<geser> I'll try to reproduce this myself and fix the locale issue in the test suite
<dholbach> geser, it seems to be the LANG and LANGUAGE environment variables
<geser> dholbach: it's already fixed upstream: https://github.com/mitsuhiko/babel/commit/2eb475f835375c1b3b7fefcb7d8aad7047d7fda7
<dholbach> geser, great!
<Mirv> is there a way to get PPA builders spit out all the changed symbols instead of stopping at the first library?
<xnox> Mirv: i think that got implemented  in Debian, not sure if we have that merged yet.
<cjwatson> That wouldn't be a property of PPA builders; it's dh_shlibdeps or thereabouts
<Mirv> xnox: ok, well good to know
<Mirv> yeah, not related to PPA
<Mirv> I'll check dh_shlibdeps' current status
<cjwatson> Worst case you could pass some permissive -c option to dpkg-gensymbols and then apply logic to the output
<Laney> It's in dh_makeshlibs
<cjwatson> Er yeah that
<Laney> Looks like 9.20140227
<Laney> Which we should have in trusty and utopic, going by the versions
<xnox> Laney: only utopic, no? trusty is so 2013
<Laney> oh yes
<Laney> ha, I just saw the 0227 at the end
<Laney> s/0//
<Mirv> hmm, so it should actually already work but doesn't for me
<Mirv> unsurprisingly it was the pkg-kde's Qt developer asking for the feature
<cjwatson> lool: looks like that worked for fakeroot, btw
<cjwatson> err, echan, but whatever
<cjwatson> xnox: Could you merge php5?  php-geoip is waiting for it, and probably anything else that uses dh-php5.
<xnox> ack.
<cjwatson> ta
<Riddell> Elv1313: yo, still need me to look at sflphone?
<Riddell> Elv1313: I've uploaded to trusty and utopic, please add a test case to clearly describe how to test for the fix
<zbenjamin> cjwatson: ping, can we get a pkcon local_uninstall? I'm writing a debug helper script for the SDK that is going to take a click package, install it , run a hook from it, and uninstall it to leave a clean device
<zbenjamin> cjwatson: but i have no root priviledges at that point
<cjwatson> zbenjamin: https://lists.launchpad.net/ubuntu-appstore-developers/msg00553.html
<cjwatson> zbenjamin: "pkcon remove"
<zbenjamin> cjwatson: awesomeeee thanke :)
<cjwatson> Just note the bit at the end of that mail about the particular form of the argument you need to pass to pkcon remove
<zbenjamin> cjwatson: ok so thats packagename;packageversion; ? whats the all? the target arch?
<cjwatson> yes
<zbenjamin> cjwatson: so if i have a fat package, how would that look like? only armhf for a armhf device?
<cjwatson> IIRC it's not checked so you can just always shove "all" in that slot, I think
<zbenjamin> ah good i'll try that
<cjwatson> I think for a fat package it would strictly be "multi", but whatever
<zbenjamin> yeah i can put that in once we are there
<cjwatson> strictly it would match the filename, so com.ubuntu.test_1.3_all.click => all
<cjwatson> (well, even more strictly it would match what "dpkg-deb -f foo.click Architecture" says)
<pitti> vila, ev: writing tests for the debci worker is fun :) (creating 100 requests, 30 workers, killing two thirds of the workers, and making sure that all requests still arrive)
<ev> \o/
<ev> pitti: next step: test that chaos in production
<pitti> http://anonscm.debian.org/gitweb/?p=users/mpitt/debci.git;a=commitdiff;h=3c03eec
<dobey> who can i beg/bribe to accept some SRUs into their respective -proposed pockets?
<ev> whoa, ruby?
<pitti> ev: well, not quite the next step (still need to implement the swift up/download and the health monitor), but getting closer
<ev> heh, indeed
<pitti> ev: Antonio wrote some parts of it in ruby (most things are in sh), he's the ruby maintainer
<ev> ah
<pitti> ev: not that happy, but as long as it's mostly test helpers and RSS generators I can live with it
<ev> that's a shame :-P
<pitti> ev: but the implementation of the worker is absurdly simple, I really like that AMQP stuff (http://anonscm.debian.org/gitweb/?p=users/mpitt/debci.git;a=blob;f=bin/debci-worker)
<pitti> the actual core logic is like 3 lines, the rest is just prettyness
<ev> nice
<Elv1313> Riddell: Hi, thanks. what kind of test do you want? It is an integration problem (in Akonadi), so it is not really possible to create an unit test without re-creating the contact topology that cause the freeze
<Elv1313> Maybe I can ask the 2 users that had it to test the new package?
 * Laney wows at the number of tests python-defaults has triggered
<mterry> Laney, did you drop the filtering_out_users patch from accountsservice on purpose?
<Laney> mterry: it's upstream now, no?
<Riddell> Elv1313: a manual test is needed "install sflphone and akonadi, start sflphone, check e-mail, notice freeze, repeat with new version, freeze will not occur" that sort of thing
<Elv1313> ok
<zbenjamin> cjwatson: works perfectly
<vila> pitti: nice
<mterry> Laney, parts of it, but not the login.defs support
<vila> pitti: I'm not sure how you assert how many requests are processed when many are killed though
<pitti> vila: if I submit N requests I should get N results, as long as at least one worker is still running
<vila> pitti: oh, that's the one or two
<pitti> vila: i. e. if a worker dies in the middle of a test, the AMQP request should go back to the queue as it won't get ack'ed
<vila> pitti: so worse case you have duplicates ?
<pitti> vila: no, the 1 or 2 is how many result directories you get (as the dir gets created when the test starts)
<pitti> vila: right, worst case is you get two results, when it crashes after it wrote the "exitcode" file but before ack'ing the request
<pitti> vila: I can probably refine that a bit to remove an incomplete result directory (when there's no exit code), still on my list
<Elv1313> Riddell: done
<cjwatson> zbenjamin: great
<vila> pitti: ack
<vila> ev: that confirms that we either need to stop using prefetch_count=1 or have the worker commit suicide to fix bug #1320205
<ubottu> bug 1320205 in Ubuntu CI Engine "nacking a rabbit message is not enough to have another consumer get it" [High,Triaged] https://launchpad.net/bugs/1320205
<Riddell> Elv1313: lovely, now we just need a friendly archive admin to review and accept the trusty SRU, try batting your eyelids at ScottK
<Elv1313> thanks
<Laney> mterry: that wasn't part of the patch, this is new upstream behaviour
<Laney> is it causing a problem?
<mterry> Laney, no we used to support login.defs in our patch, but upstream doesn't.  So dropping the patch means dropping support for login.defs
<mterry> Laney, (to define a MIN_UID for considering which users are human)
<mterry> or UID_MIN, can't remember which way  :)
<Laney> sec, just got a phone call
<brendand> cjwatson, how is click chroot create supposed to be run?
<brendand> cjwatson, click chroot create -a i386 gives option errors
<brendand> cjwatson, not particularly helpful ones
<cjwatson> click chroot -f ubuntu-sdk-14.04 -a i386 create
<cjwatson> order matters (perhaps unhelpfully)
<cjwatson> that is, the subcommand name needs to come after the options to the chroot command
<cjwatson> (oh and the whole thing needs to run under sudo)
<Laney> mterry: okay, the patch added login.defs and went upstream
<Laney> mterry: we had that in the previous AS in ubuntu
<Laney> and now in this release they've dropped that support
<cjwatson> argh, python multiprocessing is basically the worst
<mterry> Laney, ah interesting...  do they say why?
<Laney> so yes indeed the minimum UID is specified in configure
<Laney> but I think it should be okay
<cjwatson> agonisingly confusing errors
<Laney> mterry: fragile and broken or wording to that effect
<Laney> if necessary we could bring it back as a configure option I guess
<mterry> Laney, why should it be OK?  The touch images use users at 1000 and 1001 and we were relying on that support to not show them in the greeter
<Laney> what were we doing?
<Laney> wait
<Laney> that has a different login.defs?
<mterry> Laney, on Ubuntu Touch images, we set UID_MIN in login.defs to 1002
<mterry> Laney, there are radio and system users at 1000 and 1001 used by android
<dobey> SRUs are such a pain to do :(
<Laney> bah
<Laney> mterry: okay I guess we can revert this then :/
<Laney> do you want to upload that?
<Laney> ba13b59c
<mterry> Laney, sure I can do that
<Laney> I'll see about making it configurable
<pkern> Also a UID_MAX of 60000 is funny, especially if it's compiled into the binary and not overridable.
<Laney> the new behaviour doesn't consider a maximum
<pkern> Yay.
<Laney> and under the old one login.defs was able to override it
<Laney> ho hum
<ev> vila: can you add that to the bug report? That pitti has confirmed this
<pitti> sorry, what did I confirm?
<vila> pitti: that killing a worker that is processing a message puts that message back onto the queue so another worker picks it up
<pitti> vila: yes, as long as it doesn't get ack'ed yet; isn't that the whole point of it?
<vila> pitti: yes, but we thought that *nacking* a message will have the same effect but it doesn't
<vila> pitti: the worker has to die
<pitti> vila: ah; it sounds like it should, but I haven't played around with that yet
<vila> pitti: all your workers are on the same host right ?
<pitti> vila: for the test suite, yes (not in production, of course)
<vila> pitti: yup, that was the question indeed
<pitti> ah, I figured out how to run rabbitmq-server in a test suite as my user
<pitti> vila: oh, does that matter?
<vila> pitti: not sure, but I can imagine that the behavior may be different when different hosts are involved
<pitti> vila: I hope not..
<vila> pitti: I mean, at least when thinking about failures, a host dieing with a single worker is not the same as a host dieing with multiple workers :)
<pitti> vila: ah, of course; I meant, it's hopefully transparent wrt. queue ack/nack handling
<vila> pitti: yes, me too
<xnox> slangasek: pitti: what is "fastboot" mode in the boot initscripts?! was that ever supported with mountall?
<pitti> xnox: I'm afraid I never heard of it
<pitti> xnox: I thought "fast boot" was "upstartification in lucid"
<slangasek> xnox: I don't know anything about fastboot as regards initscripts
<xnox> ack.
<xnox> pitti: slangasek: should the re-introduced scripts actually just be lsb-headers, source init-functions and otherwise empty?
<pitti> xnox: I don't think it hurts that much to just take the debian ones, to make merges easier; there's no other waste than a few kB of hard disk, is there?
 * pitti needs to run out now, cu tomorrow
<xnox> pitti: slangasek: pushed updates to sysvinit merge proposal. And responded to a bunch of comments.
<slangasek> xnox: I much prefer the re-introduced scripts be as close as possible to the Debian ones, for future merging
<xnox> slangasek: ok.
<xnox> is launchpad being sad, or is it me? (code hosting / branch scanning?!)
<roadmr> it was a bit slow about an hour ago, took about 10 minutes to produce a diff
<bdmurray> mvo: bug 1320683 is surely because of phased updates
<ubottu> bug 1320683 in update-manager (Ubuntu) "Update manager does not show all available updates" [Undecided,Confirmed] https://launchpad.net/bugs/1320683
<bdmurray> mvo: you can see the status of packages phasing at http://people.canonical.com/~ubuntu-archive/phased-updates.html
<sarnold> bdmurray: ah, thanks. I'd forgotten about that entirely.
<bdmurray> sarnold: no problem
<lamont> Riddell: you around by chance?
<lamont> or xnox
<xnox> lamont: hi!
<lamont> I have sflphone questions, and your name is on it
<xnox> lamont: only marginally =) go on =)
<lamont> it believes in binding to the IP address of the default gateway, rather than the IP address associated with the route to the server... I wish to fix that, and it's a rather large codebase... hoping for a pointer
<lamont> s/of/associated with/
<lamont> xnox: ^^
<lamont> or I an pester msp later
<xnox> lamont: wow. definitely beyond what i've done with sflphone.
<lamont> xnox: no worries
<mterry> pitti, do you know much about how the volume up/down events are handled in Ubuntu Touch?
<lamont> xnox: and figured out how to do it, though there is a bug
<lamont> xnox: gnome/src/config/accountconfigdialog.c line 1048... help me understand "CONFIG_LOCAL_INTERFACE" there?
<lamont> which is more of a dbus question thananything else
<xnox> lamont: that does look wrong.
<dobey> xnox: can you approve things to go into -proposed for SRUs?
<xnox> dobey: no. you want ~ubuntu-sru
<xnox> (loop up their team on launchpad to see who is in it)
<xnox> lamont: what is account_lookup?
 * xnox presume calling into gnome account settings api.
<dobey> infinity: can you accept some things to -proposed for me?
<xnox> lamont: and i guess you want to make sure CONFIG_PUBLISHED_SAMEAS_LOCAL is false.
<dobey> stgraber, slangasek: ^^ or one of you can accept stuff to -proposed for these SRUs for me?
<xnox> dobey: it's typically useful to mention which package you are after, and for which of the stable series....
<xnox> there 68 unapproved requests at the moment
<lamont> xnox: yeah it sure looks like it wants a bug
<dobey> ubuntuone-client and ubuntuone-storage-protocol for saucy and precise
<stgraber> anyway, I'm off till Monday and on a pretty sucky internet so I won't do any queue review until I'm back some place with better connectivity (that may very well be on Monday in Malta)
<dobey> stgraber: ok, thanks. didn't know you were away. enjoy
<xnox> lamont: so the full line is all withing sflphone configuration of the account (and it's properties).
<lamont> ok
<xnox> lamont: that's not really stock dbus api or anything, just a bunch of functions that sfphone wraps.
<infinity> dobey: I'll have a look.
<dobey> infinity: thanks
<lamont> xnox: what I want is for it to pick the IP address of the interface I override, and not the default-gateway interface
<xnox> lamont: right, that dbus call is defined in ./daemon/src/client/dbus/configurationmanager-introspec.xml
<xnox> lamont: which takes you to getAddrFromInterfaceName C++ method
<xnox> which is defined as
<xnox> return SipTransport::getInterfaceAddrFromName(interface);
<xnox> line 107 in ./daemon/src/sip/siptransport.cpp
<xnox> lamont: i think you'll need to fix that function ^
<xnox> cause that's where it computes the value it uses, in a cryptic way...
<xnox> lamont: does that help at all?!
<infinity> dobey: Why the en_US.UTF-8 requirement for tests on saucy?
<dobey> infinity: becasue some of the cert files have non-ascii names, and the default locale is that weird ANSI thing that only does ascii, which breaks python encode/decode stuff
<infinity> dobey: Ahh.  C.UTF-8 would probably do the trick without making you need a langpack build-dep.
<infinity> dobey: But I this works too.  *shrug*
<infinity> dobey: Was just curious.
<dobey> maybe. we were already doing the en_US.UTF-8 bit elsewhere though, so i just copied that
<infinity> TÃBÄ°TAK_UEKAE_KÃ¶k_Sertifika_Hizmet_SaÄlayÄ±cÄ±sÄ±_-_SÃ¼rÃ¼m_3.pem
<infinity> Wow.
<dobey> yeah
<infinity> Kay, explanation accepted. :)
<infinity> dobey: The only followup, then, is why not the same patch for precise, in case ca-certs gets updated there with similar consequences?
<dobey> i thought i did do the en_US thing on precise too
<lamont> xnox: that may help.  C++ may not.
<infinity> Not in this upload.  If you did, it was a previous one.
 * infinity looks.
<xnox> lamont: that function, is pure C by the looks of it thought.
<dobey> huh. well, i did it like a month ago, so i don't remember exactly
<dobey> if i didn't do it on precise, it was because the tests didn't fail when i did the test build, most likely
<infinity> Oh.  precise might not run a testsuite at all.
<dobey> oh or that
<infinity> It doesn't have the override with ./tun-tests
<dobey> precise is quite old, yeah
<infinity> So, yeah.
<infinity> Alrighty.  Acceptiferating.
<dobey> thanks
<infinity> dobey: Also, this isn't carte blanche to be annoying, but when you have deadlines like the U1 shutdown in 10 days, bugging people earlier wouldn't be a bad thing.
<dobey> infinity: i have been bugging :(
<infinity> dobey: Oh.  You should have bugged me.  And maybe included the "hey, there's a deadline" bit.  Oh well.
<infinity> dobey: As it stands now, I think I'm going to ask you guys to verify the crap out of those u1-client uploads as best you can, so we can phase them to 100% when we release, and hope they get out to most people ASAP.
<lamont> xnox: wondering if maybe that's getting called with DEFAULT_INTERFACE
<xnox> lamont: hm. not sure. if you file a bug CC / subscribe me on it. for me to have a look, when i'm bored on a connection flight.
<xnox> lamont: cause i'm deep in async upstart code at the moment and hope to get this done before EOW.
<infinity> dobey: And poke me personally when it's verified, I think the client one is worthy of an early release if you've tested it well.
<lamont> xnox: sure
<xnox> lamont: the argument that should be called, should be whatever was stored in the account key, no?!
<dobey> infinity: sure
<infinity> dobey: Oh, except https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/1306225/comments/3 isn't very promising...
<ubottu> Launchpad bug 1306225 in Ubuntu One Client "The user should be informed about the u1 file service shutdown" [Critical,In progress]
<dobey> infinity: thanks much
<infinity> dobey: Is there no way to get that working at runtime instead of shutdown?
<dobey> infinity: yeah, though at this point i'm thinking it's worth it to just release the update anyway, given how close june 1 is. the "not connecting" bit is going to be more important by the time we could get a new upload to fix the notification on precise (i have no idea why the notification is behaving that way on precise. it might be a much larger problem)
<dobey> trying to test on saucy right now. just waiting for the archive to get updated so apt will work
<lamont> ioctl(13, SIOCGIFADDR, {ifr_name="tun0", ifr_addr={AF_INET, inet_addr("10.172.126.2")}}) = 0
<lamont> hrmpf
<xnox> lamont: cheat =) debugging c++ with strace =)))))
<lamont> xnox: I was doing thatbefore I looked at the source
<lamont> because that's how I roll
<xnox> =)))))
<xnox> s/roll/troll/ ?!
<Riddell> lamont: Elv1313 is the sflphone man, try tracking him down if you have questions
<mdeslaur> mvo: can you confirm there's nothing to do with apt in bug 1016643?
<ubottu> bug 1016643 in apt (Ubuntu Quantal) "add-apt-repository downloads gpg key in an insecure fashion" [High,Triaged] https://launchpad.net/bugs/1016643
<mdeslaur> (/me is closing ancient bugs...)
<lamont> xnox: and now I can't getit to fail
<lamont> Riddell: thanks.  here or deban?
<lamont> debian
<Riddell> lamont: upstream
<lamont> amusingly, I can't actually reproduce the bug
<lamont> things do, in fact, seem to work as expected.
<dobey> turns out that setting your clock 2 weeks forward really screws up some things
<dobey> bah
<dobey> what a bother :(
<dobey> infinity: https://bugs.launchpad.net/ubuntuone-client/+bug/1306225/comments/5 doesn't look good :(
<ubottu> Launchpad bug 1306225 in Ubuntu One Client "The user should be informed about the u1 file service shutdown" [Critical,In progress]
<infinity> dobey: Is that something you can turn around a quick(ish) fix for?  I'm happy to be responsive and process that one quickly if you can.
<dobey> infinity: well, i haven't been able to do so in the ~15 minutes i've been poking at it (trying to get it to exit cleanly anyway). maybe i can if i just try to make it not ever connect, and leave the process running and acting normally like a disconnected client
<dobey> infinity: so i managed to make a patch that makes it not connect, but keep the process alive and working otherwise normally, for 13.10, but 12.04 code is a bit different so i'll have to make a different patch for it
<infinity> dobey: Alright.  Keep me in the loop.  I'm around most of the evening if you're working late, or tomorrow if not.
<infinity> (Need to run out soon to visit a post office and remind myself how to send paper through the air, though.  Weird backward-ass lawyer people)
<dobey> infinity: yeah. i need to go now. i'll probably need to finish this up in the morning, so ping me when you hop on-line tomorrow
#ubuntu-devel 2014-05-22
<pitti> Good morning
<pitti> xnox: thanks, will review today
<Unit193> Howdy.
<mardy> Chipaca: hi! The libraries for Online Accounts are libaccounts-qt > libaccounts-glib (for enumerating account)
<mardy> Chipaca: for performing the authentication, libsignon-qt5 and libsignon-glib
<Chipaca> mardy: hi! and those allow me to oauth-sign a url?
 * Chipaca looks it up
<mardy> Chipaca: the OAuth 1.0a signature? Nope, they just get you the token
<Chipaca> mardy: they give you the token? excellent
<Chipaca> (i can do the signing myself :) )
<mardy> Chipaca: however, if you are after UbuntuOne, I've some bad news
<Chipaca> mardy: tell me more
<Chipaca> mardy: specifically, i need the u1 token
<mardy> Chipaca: the U1 account plugin is not using Online Accounts for OAuth, it's just using it for storing the password
<mardy> Chipaca: maybe it also stores the token, I'm not sure
<mardy> Chipaca: you'd better talk to the U1 guys, to know what they store in the account
<Chipaca> the "password" should be a dict that includes the token, or a string in a known format
<Chipaca> mardy: will do
<mardy> Chipaca: yes, that's possible
<Chipaca> mardy: where can i find the api docs of libaccounts-glib?
<Chipaca> is this the google one that's on code.google.com?
<Chipaca> libaccounts-glib-doc
<michagogo> Chipaca, mardy: there's also the *tiny* little detail that U1 is going away next week...
<cjwatson> Only some parts of U1 are going away, not including the SSO parts
<michagogo> Ah, didn't know the Ubuntu SSO was considered part of U1
<darkxst> michagogo, SSO was moved into U1 a while ago
<cjwatson> michagogo: Well, my point is that account handling (SSO or not) doesn't go away just because file services are shutting down
<michagogo> cjwatson: of course
<michagogo> I just didn't know that SSO had been rebranded as part of U1
<michagogo> And I've been hearing about "U1 is going away", so...
<rbasak> Is /usr/share/distro-info/ubuntu.csv OK for other packages to read directly, or should they go via the distro-info command?
<rbasak> I ask because juju reads ubuntu.csv directly.
<pitti> Laney: thanks! Jenkins Fixed - utopic-adt-friends 20
<Laney> pitti: always a good mail to get ;)
<pitti> Laney: while I have you in the mood for autopkgtests: would you mind ignoring the "kazoo" test failure? (blocking python-defaults)
<pitti> it almost always fails on i386
<pitti> i. e. horribly flaky test
<pitti> I already retried it like 5 times
<Laney> pitti: could do, have you analysed it at all?
<pitti> http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-kazoo/ARCH=i386,label=adt/13/console
<pitti> Laney: not really; ^ gets a ton of "connection refused" errors
<Laney> okay
<Laney> well, looks like zul added them originally
<pitti> (no idea what kazoo actually is)
<Laney> perhaps he would like to take a look :)
<pitti> the test seems to be an ubuntu specifism
<pitti> it's not in debian
<Laney> will skip for now
<pitti> zul: that'd be nice, yes
<pitti> (and while you are at it, the flaky nut test :) )
 * Laney coughs
<siretart> infinity: (or anyone else from the release team): What do you guys think about starting the libav10 transition in utopic now? https://release.debian.org/transitions/html/libav10.html
<siretart> TBH, I don't think that many of the remaining packages will get actually fixed, but rather removed from testing for now
<siretart> visp and jitsi havve pending NMUs, and that's it
<siretart> Logan_: ^^
<zbenjamin> tedg: ping
<Chipaca> michagogo: U1 *files* is going away next week.
<michagogo> Chipaca: Thanks, I got that now.
<Chipaca> michagogo: ah, i see you've already been browbeat over it
<Chipaca> sorry to belabour
<cjwatson> I had been rather hoping to educate rather than browbeat :-)
<cjwatson> Maybe "clarify"
<michagogo> cjwatson: no worries :-)
<michagogo> Is U1 just cloud and logon?
<michagogo> Or, just logon now?
<michagogo> Or do other things also happen under the name?
<cjwatson> There's at least U1DB as well
<cjwatson> https://one.ubuntu.com/help/faq/what-is-happening-and-when/ mentions several continuing services, though not all of those are part of U1 (e.g. Launchpad and Landscape aren't)
 * michagogo googles U1DB and Ubuntu Pay
<mvo> pitti: hm, shouldn't apport-cli -c /var/crash/_usr_bin_unity8.1001.crash give me a url or something? it prints a "." and exists for me only
<davmor2> mvo: I've seen that too
<mvo> davmor2: I really want to report this crash :)
<davmor2> mvo: you can do it manually :)
<pitti> mvo: is that on trusty?
<mvo> pitti: utopic
<mvo> from today
<pitti> mvo: err, irrelevant, we didn't enable LP yet in utopic
<pitti> mvo: yes, we currently only report to errors.u.c. (which you don't really "see")
<pitti> mvo: if you want to enable LP bugs, comment out this in /etc/apport/crashdb.conf:
<pitti> 'problem_types': ['Bug', 'Package'],
<mvo> pitti: thanks! that helps. now it reports that the file is corrupted :/ (EOFError('Compressed file ended before the end-of-stream marker was reached',)). oh well
<davmor2> mvo: sadtrombone.com
<shadeslayer> jono: ping
<shadeslayer> jono: any news on the donations report?
<Chipaca> xnox: ping
<xnox> Chipaca: hi!
<Chipaca> xnox: hi! i'm looking at libnih, wondering how to go from lp:libnih to ./configure && make, and your name comes up a lot in debian/changelog :)
<jono> shadeslayer, mhall119 is releasing it
<xnox> Chipaca: lp:libnih is stale and no longer in use.
<Chipaca> xnox: oh! where is libnih living now?
<xnox> Chipaca: best bet to start from lp:ubuntu/libnih -> apt-get build-dep libnih; autoreconf -f -i; ./configure; make
<Chipaca> xnox: seriously it's only maintained in ubuntu:libnih?
<Chipaca> ok...
<shadeslayer> jono: cool :)
<xnox> Chipaca: libnih has multiple forks at the moment =) there is https://github.com/keybuk/libnih then there is mine work, and ubuntu & debian are diverged a bit.
<Chipaca> xnox: that sounds ideal :-/
<Chipaca> goes well with the lib's name, though
<xnox> Chipaca: it's very stable, thus needs no maintainance. there is only like ~8-10 patches difference between ubuntu and keybuk's upstream
<apachelogger> lol
<Chipaca> xnox: I might be about to introduce another patch :D
<xnox> Chipaca: best bet bzr branch lp:ubuntu/libnih; apt-get build-dep libnih; autoreconf -f -i; ./configure; make
<Chipaca> xnox: yup, done that, thanks
<xnox> Chipaca: well, i will most likely to be reviewing it for inclusion and i did forward all patches to keybuk.
<Chipaca> xnox: i was missing the -f -i
<Chipaca> xnox: how do i run the tests?
<xnox> Chipaca: make check
<Chipaca> ok
 * mvo wonders if it would be worth adding a HACKING file to libnih with the paste of this irc conversation
<xnox> Chipaca: the tests, are excessive =)
<xnox> mvo: it's all covered in upstart cookbook =)
<Laney> needs moar autogen.sh
<Chipaca> mvo: there is a HACKING file
<Chipaca> mvo: it is not illuminating :)
<xnox> Chipaca: illumination quick how-to to libnih is in http://people.canonical.com/~jhunt/presentations/uds-r/2012-10-31/upstart-development.pdf
<Chipaca> it is very good, mind you. Exactly what I need. Except for this conversation.
<mvo> xnox: maybe the HACKING file should point to the cookbook then :) ?
<xnox> Chipaca: and http://upstart.ubuntu.com/cookbook/#nih
<Chipaca> um. to be honest, if you point me to the upstart cookbook when all i want to use is a bit of libnih, i'll run away screaming
<xnox> Chipaca: i've also tried to publish docs at http://libnih.la/ but they are incomplete.
<xnox> Chipaca: best to read code comments, as all functions methods etc. are documented extensively.
<Chipaca> I found the libnih.la docs, they were good enough for my use :)
<xnox> =))))))))))))))))
<Chipaca> (wrapping libnih-dbus to use it from push)
<xnox> nice.
<xnox> I love that .la is country domain for Laos, they market it as ".la means local to Los Angeles"
<xnox> but i want to start the trend for library docs instead =)
<Laney> somalia is better :)
 * Laney looks for .dll
<Chipaca> this is for use from go, so .la ftw
<ogra_> heh
 * Chipaca runs away
<xnox> Laney: ha, somalia does look good!
<ogra_> we should have the next sprint there
<ogra_> :)
<xnox> ogra_: nah, Tokyo =))))) and get Sony to sponsor us =)
<ogra_> xnox, oh, i wouldnt mind that !!!
<hallyn> is there a definitive (per-release?) list of install preseed keys that work? i.e. passwd/make-user Boolean true\npasswd/username string ubuntu\n (plus pwd) seems to be ignored...
<cjwatson> hallyn: That's just bad syntax, not bad keys
<cjwatson> d-i passwd/make-user boolean true
<cjwatson> d-i passwd/username string ubuntu
<cjwatson> The installation guide has details on the useful settings
<hallyn> cjwatson: yes i have that
<hallyn> full preseed:  http://paste.ubuntu.com/7501590/
<cjwatson> To debug anything I'd need to see the installer syslog, preferably from an installation with DEBCONF_DEBUG=developer so that I get a full debconf trace
<hallyn> cjwatson: where do i set that?  kernel command line?
<cjwatson> yes
<hallyn> cjwatson: thanks, i'll get that at some point and if it's not obvious to me i'll get back to you.  hopefully it'll be obvious to me :)
<hallyn> actually i'll just restart this install.
<hallyn> logs will be in newly installed host under /var/log/intaller.log or somesuch?
<cjwatson> hallyn: /var/log/installer/syslog
<cjwatson> hallyn: (note that this is a trace in a similar way that strace is a trace, that is it will include confidential information such as passwords)
<hallyn> s'ok, password is usually 'none' or 'ubuntu' as these are firealled test installs :)
<hallyn> thanks cjwatson
<nobuto_> Could someone in SRU team take a look at bug 1309885 ?
<ubottu> bug 1309885 in Ubuntu Translations "Cannot enable IM inside Qt5 apps including webapp-container" [Undecided,New] https://launchpad.net/bugs/1309885
<nobuto_> ^ it looks like ready to be released to me, but it stalls in SRU process.
<hallyn> cjwatson: hm, http://paste.ubuntu.com/7501714/  what is GET vs METAGET
<cjwatson> man debconf-devel
<hallyn> thx
 * hallyn goes to manpages.ubuntu.com for that one
<cjwatson> hallyn: This seems to be a partial log and is missing some important parts
<cjwatson> So I can't debug it
<cjwatson> In particular it's missing the bit where the preseed file is applied
<hallyn> sorry thought that was the important parts, uploading the whole thing,
<hallyn> http://paste.ubuntu.com/7501768/
<jodh> bdmurray: dude, you *rock*! (bug 1068060)
<ubottu> bug 1068060 in Errors ""the past week" is missing from table period menu" [Medium,Fix committed] https://launchpad.net/bugs/1068060
<bdmurray> jodh: fix released actually ;-)
<xnox> doko: some of the gcc-4.9 build-failures are of the pattern of generating undefined references in c++ code. of strange nature, e.g. desctructor having undefined reference to it's class....
<xnox> http://paste.ubuntu.com/7502150/
<xnox> what's going on?
<ogra_> xnox, happy to have you in the diskspace warning meeting next week :)
<ogra_> if you want to
<xnox> ogra_: we have tried like 4 or 5 times to get "plymouth on mir" session no stop and notify user early in the boot that e.g. battery is critically low, or disk space is full.
<xnox> ogra_: but we have never managed to have that session.
<xnox> ogra_: any idea what's the bootsplash story is?
<ogra_> xnox, i think that plan is on ice for now
<xnox> (as in current state)
<xnox> ogra_: so, i cannot have any graphics as root & read-only ?
<ogra_> xnox, we will use the unity-system-compositor splash
<ogra_> which will land with the split greeter mterry is working on
<xnox> ogra_: can that start as root & read-only?!
<xnox> mterry: i guess ^
<ogra_> it runs as root but only after the container
<mterry> ogra_, no, the splash will land separately now
<ogra_> (a bit late, i know, but thats the current plan)
<ogra_> mterry, ugh
<ogra_> why is that ?
<mterry> ogra_, to reduce the amount of design signoff needed for the split landing
<ogra_> hmpf
<ogra_> we need it to work on low-battery mode and various other bits :
<ogra_> :(
<mterry> bbl
<ogra_> xnox, as for readonly ... yeah, it only needs to be able to create a socket in /tmp
<ogra_> xnox, for the low diskspace issue i think we should port what we have on desktop already (if thats not hard bound to nautilus or so) and have a popup if you are at something like 98% for $HOME though
<ogra_> that shouldnt need any splash screen implementation
<xnox> ogra_: sockets should not use /tmp
<ogra_> tell that to the Mir people :)
<xnox> nor predictable names.
<ogra_> not my socket
<ogra_> root@ubuntu-phablet:~# ls -l /tmp/mir_socket
<ogra_> srwxrwxrwx 1 root root 0 May 22 13:20 /tmp/mir_socket
<mdeslaur> gah!
<ogra_> should probably not be 666
<ogra_> :)
 * mdeslaur prepares tar and feathers
<ogra_> but please in #ubuntu-mir
<xnox> mdeslaur: thanks.... =)
<ogra_> i'm just the messenger
<xnox> mdeslaur: i think i had a bug filed saying that "linux abstract sockets" should be used instead.
<xnox> mdeslaur: e.g. like upstart.
<ogra_> i thinnk you even started a mail discussion, no ?
<ogra_> (unless i was subscribed to the bug i seem to remember that)
<xnox> mdeslaur: ogra_: https://code.launchpad.net/~afrantzis/mir/abstract-host-connection/+merge/216290 ?!
<ogra_> xnox, merged into mir/devel
<xnox> or maybe that's unrelated.
<ogra_> not trunk
<ogra_> they use staging branches
<ogra_> so it might land at some point when devel gets synced
<xnox> ogra_: https://bugs.launchpad.net/mir/+bug/1299101/comments/4
<ubottu> Launchpad bug 1299101 in mir (Ubuntu) "Nested platform is not testable" [High,Fix released]
<ogra_> mdeslaur, we need to go through the udev rules next week too ... since we just import the android permissions in there
<mdeslaur> ogra_: that would be good, yes
<mdeslaur> xnox: do you have a link to the bug you filed?
<xnox> mdeslaur: i don't see it fixed. THere was https://lists.launchpad.net/ubuntu-phone/msg06672.html and https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1285215 but it was worked around with removing stale file.
<ubottu> Launchpad bug 1285215 in Mir "Unity fails to start sometimes in CI resulting in screen unlock failure [what(): bind: Address already in use]" [Critical,Fix released]
<xnox> mdeslaur: cause mir itself doesn't remove stale file socket before trying to bind....
<xnox> mdeslaur: so i don't think there is any bug. Can you please file something critical?
<xnox> mdeslaur: cause clearly, my voice was not heard at the time.
<mdeslaur> jdstrand: since you have a phone to look at, could you please file a bug for /tmp/mir_socket?
 * ogra_ hopes that the mir team is at least there next week
<ogra_> kgunn, ^^ are you guys at the sprint next week ?
<jdstrand> I thought there was a bug about that
<kgunn> ogra_: we will be there....
<jdstrand> and that it was fixed
<kgunn> yes...thot it was fixed also
<ogra_> kgunn, awesome :)
<ogra_> kgunn, it is in the devel branch
<ogra_> likely not landed yet
<xnox> doko: actually it looks like a real under-linkage.
<kgunn> ogra_: true...
<kgunn> hmm...thot it got promoted
 * kgunn goes to dig
<ogra_> and we're not in a hurry :)
<ogra_> (semi TRAINCON-0 atm ... so dont sweat it ... )
<jdstrand> interestingly, the 1.1 apparmor policy doesn't allow access to /tmp/mir_socket
<jdstrand> this was bug #1236912
<ubottu> bug 1236912 in mir (Ubuntu) "please use XDG_RUNTIME_DIR instead of /tmp for mir_socket" [High,Fix released] https://launchpad.net/bugs/1236912
<jdstrand> apps seem to be functioning fine without it. I wonder if I should remove the rule for /{,var/}run/user/*/mir_socket
<jdstrand> kgunn: thoughts? ^
<kgunn> jdstrand: we do still use that for the system compositor and all our demo apps where the server runs as root
<jdstrand> but apps themselves don't actually need it?
<jdstrand> clearly not, but I'd like confirmation before I remove it
<jdstrand> kgunn: ^
<kgunn> ogra_: cmiiw, but looks like we released into utopic at r1573...see https://code.launchpad.net/~mir-team/mir/utopic r1185
<kgunn> and that branch above you mentioned was at r1568
<kgunn> on devel
<kgunn> jdstrand: right...apps running on unity8 in touch as mir clients, would not need /tmp/mir_socket
<ogra_> kgunn, hmm, i still see /tmp/mir_socket on image 43
<ogra_> kgunn, but mir 0.1.9 is installed
<kgunn> ogra_: see my converstation with jdstrand
<ogra_> was that only for the session Mir instead of unity-system-compositor ?
<kgunn> right
<ogra_> ah
 * ogra_ sees the backlog :)
<kgunn> and i do know that we fully clean up stale sockets for all "handle-able" shutdowns, sigstops etc...but crashes may be a diff matter
<jdstrand> ogra_: would native GL applications on Mir need it? eg, a gl game?
<jdstrand> sorry, kgunn ^
 * jdstrand has a note in the policy about that
<kgunn> jdstrand: only in test instance, like where we run our demo code...(hang on)
<ogra_> yeah ... i wouldnt be able to answer how native EGL apps would run with Mir
<ogra_> :)
<ogra_> i would expect actual native apps to link directly with libGLES or so though
<kgunn> jdstrand: see the "running mir natively" section of http://unity.ubuntu.com/mir/using_mir_on_pc.html
<ogra_> and not care about Mir at all
<kgunn> jdstrand: oh i think i get what you mean...
<kgunn> jdstrand: duh, yeah...so any "native mir" client will need to have a socket
<jdstrand> right
<kgunn> in the case of unity8 we're hiding that behind platform-api is my guess
<jdstrand> ok, so I'll keep that
<kgunn> all those sockets will be in some <something>/usr/ dir
<ogra_> kgunn, but if i i.e. port an android gamme that natively uses GLES to ubuntu, would i have to involve Mir at all ? thats handled on the lib level, no ?
<ogra_> (or SDL games )
<kgunn> ogra_: is your android port to Qt? or native mir ?
<jdstrand> kgunn: you said mir_socket was moved out of /tmp, did it go to XDG_RUNTIME_DIR like the bug suggests?
<ogra_> kgunn, well, something like openarena for example ... would that have to be integrated with Mir at all ?
<kgunn> jdstrand: for the session server yes...so there are 2 mir server, 1 is the "systemcompositor" which is at root, owned by the unity-system-compositor
<jdstrand> I can confirm the existence of /tmp/mir_socketand the non-existence of /run/user/32011/mir_socket on r43
<kgunn> the second server, is the unity8 owned server for the session
<kgunn> ogra_: so SDL is a layer that would "take care" of the socket in that case, and for openarena...that runs on X...so xmir layer takes care of that
<kgunn> ogra_: only in the instance where there is no abstraction layer between the app and the mir client api would there need to be awareness of a mir socket
<jdstrand> an SDL game would still need the access since the lib would be in process
<ogra_> i think openarena directly uses GL/GLES calls even on X
<kgunn> ogra_: GL/GLES is kinda unrelated to the socket on mir...
<jdstrand> the developer may not have to know about it, but the process would
<kgunn> yes jdstrand right
<ogra_> <- not a GLES guy ... just curious
<kgunn> ogra_: no worries :)
<kgunn> i know..gfx guys are weird
<ogra_> haha
<jdstrand> kgunn: so, was this change supposed to be in r43? I have 0.1.9+14.10.20140430.1-0ubuntu1 installed but still see /tmp/mir_socket
<jdstrand> (this is on mako)
<ogra_> jdstrand, the change was only for the session socket
<jdstrand> but the session socket isn't in /run/user/32011 either
<ogra_> se in $XDG_RUNTIME_DIR, there is another socket
<jdstrand> or is it abstract now?
<ogra_> or at least should be
<jdstrand> nope
<jdstrand> not with r43 in the emulator
<ogra_> root@ubuntu-phablet:~# ls -l /run/user/32011/mir_socket
<ogra_> srwxrwxr-x 1 phablet phablet 0 May 22 13:20 /run/user/32011/mir_socket
<ogra_> thats what i have on 39
<ogra_> not really abstract
<jdstrand> no
<jdstrand> weird, I don't have it on the emulator
<ogra_> i wonder why you wouldnt have it on the emulator
<ogra_> rsalveti, ??
<kgunn> jdstrand: ogra_ ...feeling like i may not be doing the greatest in answering, can we move to #ubuntu-mir ?
 * rsalveti reading
<ogra_> probably because it uses GLES forwarding ... not sure why that would affect the session socket though
<rsalveti> ogra_: you should have it on the emulator as well
<rsalveti> make sure it's the same image
<rsalveti> ogra_: and the gl game shouldn't need to know mir, libsdl would need to talk mir though
<rsalveti> let me download latest image on the emulator and check
<jdstrand> oh, haha
<jdstrand> rsalveti: nm
<jdstrand> unity8 wasn't running here
<jdstrand> ok, so session socket missing mystery solved
<ogra_> rsalveti, well, i'm on 39 looking at flo
<ogra_> lets move to the mir channel though
<ogra_> rsalveti, right, thats what i thought, GL/GLES games just link directly and bypass the display-server
<ogra_> thats the amount of hlaf knowledge i collected over the years :)
<ogra_> (why dont we have an openarena click package yet btw ? :P)
<rsalveti> right, but we need to change libsdl to support mir
<rsalveti> not sure if that was done already
<ogra_> it was apparently
<ogra_> a while ago
<ogra_> there were even demos on G+
<ogra_> iirc bregma forwarded something
<ogra_> (proper upstreamed even)
<rsalveti> ogra_: cool, then it should be fine :-)
<dobey> infinity: hi. i need to bump the version again to replace the current package in -proposed right?
<bregma> just FYI, libSDL2 (not SDl 1.2) works on native Mir out of the box in Ubuntu 14.04 and later...  the lib needs to know what the native window system is to get an EGL context, so if it the app does its own GLX calls it won't work on Mir but if it relies on SDL, it'll be fine
<bregma> it needs the environment variable for the socket defined, just like X needs DISPLAY defined
<bregma> and if it's libSDL1.2, no joy anyway
<ogra_> yeah, we have a guy who wants to experiment with it ... slvn was the nick i think
<ogra_> he didnt get far because upstart-app-launch was broken though ... LD_LIBRARY_PATH didnt get set properly so he couldnt ship the lib
<ogra_> (that was fixed today ... looking forward to see some SDL fancyness in click apps)
<smoser> hey all. i'm just thinking what woudl be the easiest / most preferred way to block net-device-added events from bringing up networking until after cloud-init-local had run.
<smoser> those are emitted by udev, and consumed by network-interface.conf
<dobey> infinity: ping
<dobey> hmm :-/
<infinity> dobey: Sorry, I've been out sick all day.  Yes, you need to bump the version.
#ubuntu-devel 2014-05-23
<dobey> infinity: oh. hope you're feeling better. are you still around?
<infinity> dobey: Ish.
<dobey> infinity: just uploaded a new ubuntuone-client for saucy-proposed, and about to do the same for precise-proposed, if you could accept them?
<infinity> dobey: I will have a look, yeahp.
<dobey> infinity: and precise-proposed uploaded too. thanks much. i'll test as soon as they're built in -proposed
<infinity> dobey: Done and done.
<dobey> thanks!
 * dobey wonders how long it will take for them to show up in the archive
<dobey> sigh, i wonder if it's virtualbox that makes setting the time so difficult, or what
<infinity> dobey: "date -s ..."?
<infinity> dobey: Preferably in the VM, not in the host, if you value your sanity.
<dobey> sanity? what's that?
<dobey> in saucy i can set the date ok from the system settings
<dobey> but in the precise vm it keeps automatically changing back to the current date
<dobey> no idea why
<infinity> dobey: Some "use network time" tickbox being overexhuberant, perhaps?
<infinity> dobey: But setting it from a terminal should do fine, I'd think.
<dobey> maybe, but i unchecked it (you can't actually change the date with the radio button set to "automatic")
<dobey> nope, date -s doesn't help
<infinity> Your VM hates you...
<dobey> it set it for a few seconds, but by the time i typed the command to start u1 and connect, it had already changed back :(
<infinity> I'd suggest ntpd is running, but ntpd usually gives up if you're too far out of sync with reality.
<dobey> ps doesn't show any ntpd
<dobey> whee
<dobey> and i unplugged the network and it still gets reset
<dobey> so yeah, precise vm is hating me
<infinity> I can't imagine what would be resetting it.
<dobey> yeah, me either :(
<infinity> If in doubt, blame g-s-d?
<dobey> wfm
<infinity> Though killing g-s-d wouldn't be so helpful if what you're testing needs it. :P
<dobey> ok, so the notifications are still weird on precise (but i think tthat's a bigger bug in the code that we don't really have time to fix at this point)
<infinity> I wouldn't be aboe blaming indicator-datetime, or similar, either.  But I'm just grasping at straws, without staring at the VM in question.
<dobey> but the connecting post-june-1 fix is working right on precise
<infinity> s/aboe/above/
<infinity> dobey: If you're happy enough with the state of those packages, then, we'll just let 'em in.
<infinity> dobey: I don't want to delay any longer unless you think you can fix the weird notification thing in short order.
<dobey> infinity: i don't think we can fix it. i just now changed the bug to verification-done and added a comment to that effect. i think we should push the update out now
<infinity> dobey: Alrighty.  Doing.
<infinity> mdeslaur: Around?
<dobey> infinity: thanks a lot for your help with this.
<infinity> jdstrand: Or you?
<infinity> Oh, wait, I think the security team might be on European time...
<mdeslaur> infinity: what's up?
<infinity> mdeslaur: Any qualms about me pushing the above ubuntuone-client update to precise-security as well, overwriting what you have in the pocket?
<infinity> mdeslaur: I think it'd be monumentally confusing to the 2 people who run security-only without updates when the package explodes and stops working correctly on Jun 1. :)
<mdeslaur> infinity: no qualms at all, go right ahead
<infinity> mdeslaur: Ta.
<mdeslaur> does it need to be rebuilt with only -security though?
<infinity> Seems pretty unlikely, but maybe I should have double-checked before hitting enter.
 * infinity quickly goes to look at deps.
<infinity> mdeslaur: binary deps all looks safe.
<mdeslaur> infinity: cool
<dobey> hooray
<infinity> mdeslaur: Speaking of things that aren't technically security updates but screw with people who run security-only, I wonder if we should chat about tzdata sometime.
<mdeslaur> hrm, interesting
<mdeslaur> yeah, I guess that could go into -security too
<infinity> mdeslaur: I mean, the part where we've never had complaints either means no one actually runs security-only, or the people who do are all in regions with stable timezones. :)
<infinity> mdeslaur: Cause you tend to notice pretty quickly when tzdata is wrong for you.
<mdeslaur> I've always been really curious as to how many people actually do run -security only
<infinity> Me too.  I'm not even sure how we'd go about mocking pseudo-metrics for that, let alone good ones.
<infinity> Could start with maybe looking for desktop apps that are out of sync between security and updates and reporting crashes to errors.
<mdeslaur> when someone enables unattended updates during the server image install, that's security only, right?
<infinity> Not sure.
<Logan_> is the implicit conversion to pointer failure really necessary on amd64? it only inevitably causes a problem on ia64, and Debian only checked on ia64 buildds (but we fail builds on amd64 as well)
<infinity> Unattended-Upgrade::Allowed-Origins {
<infinity>         "${distro_id}:${distro_codename}-security";
<infinity> };
<mdeslaur> hrm, interesting
<infinity> mdeslaur: The default conffile comments out other pockets, so yeah, I guess.
<infinity> /etc/apt/apt.conf.d/50unattended-upgrades
<dobey> weird
<mdeslaur> I always thought it would be used more by server users than desktop users
<infinity> Logan_: Yes.
<dobey> my server has backports and updates in the list when i do "apt-get update"
<infinity> Logan_: It's actually worse on amd64 than ia64, in that it's a guaranteed runtime explosion on ia64, and it's nondeterministic "wheeee!" on amd64.
<mdeslaur> dobey: when done manually, yes
<Logan_> infinity: I see - but then why doesn't Debian do it?
<mdeslaur> dobey: when done automatically by unattended-updates, no
<infinity> Logan_: Plus, it's always a bug.  And a bad one.  Even on 32-bit arches, it usually points to a bad bug elsewhere (like an implicit declaration).
<dobey> mdeslaur: oh, that's kind of weird
<infinity> Logan_: Debian failed for it on ia64 because LaMont ran those buildds.  Guess who wrote the code that fails it on our buildds? :)
<Logan_> I see :P
<infinity> Logan_: Anyhow, I'm the one at "fault" for extending the check to all 64-bit arches, but with good reason.
<infinity> Logan_: I'm tempted to extend the check to all implicit declarations as well, as they cause more interestingly subtle bugs.
<Logan_> what's weird is that I just synced over your delta for jmagick because I didn't get any references to "implicitly" in my pbuilder log, but it happened on the build
<Logan_> any idea why that's the case?
<Logan_> *buildd
<Logan_> I'll obviously reinstate your changes, but I don't get why I didn't get those warnings in my local build
<infinity> Logan_: What arch was your local build on?
<Logan_> amd64
<infinity> Also, wow, this code is a mess.  I must have been very tempted to rewrite half of it last time I was in there.
<Logan_> should I use sbuild instead or something? or would that not make a difference?
<infinity> Logan_: I don't see why it would make a difference.  I'm doing a test build here.
<Logan_> infinity: oh wait - is the line "Function `getByteArrayFieldValue' implicitly converted to pointer at magick_MagickImage.c:3454" injected into the log?
<Logan_> because it occurs right beneath a warning in the buildd log
<Logan_> and that's what I grepped for in my local build log
<infinity> Ahh, yes, that's inserted. :)
<Logan_> grrr :P
<Logan_> rewriting history
 * Logan_ begrudgingly reintroduces the delta
<infinity> Logan_: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/lpbuildd/check_implicit_pointer_functions.py
<infinity> Logan_: That's responsible for the insertion.
<Logan_> ah, I see
<Logan_> I think I'll also forward your patch to Debian once I upload this, unless you want to
<infinity> It's already there.
<Logan_> tbh, it should be upstream
<Logan_> oh
<infinity> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727776
<ubottu> Debian bug 727776 in jmagick "jmagick implictly declares getByteArrayFieldValue due to missing prototype" [Important,Open]
<Logan_> alright, reupped with the patch
<Logan_> thanks as always :P
<infinity> Reading that build log just makes me cry.
<infinity> How do people never actually check the output of their compilers?
<Logan_> I like all of the deprecated functions
<infinity> That's to be expected, as the thing they're building against moves on...
<infinity> But all the type mismatches have probably been there since day 1.
<infinity> I don't think that's an underlying API moving.
<infinity> That's just lazy programming.
<Logan_> erm
<Logan_> one of the functions they use, DestroyImages, has been deprecated in ImageMagick since 2002
<infinity> Hahahaha.
<infinity> Okay, some lazy there too then. :)
<infinity> If we turned on -Wall -Wextra -Werror, we could probably reduce the archive size by 90%.
<infinity> So tempting.
<Logan_> we're not supposed to babysit upstream :P
<Logan_> as nice as it would be to remove warnings from all packages in the archive, it ain't gonna happen with our limited devs
<infinity> I know.  It's a pipe dream I'll never realize.
<infinity> So, I'll go back to nursing my flu instead.
<pitti> Good morning
<michagogo> dobey, infinity: Yeah, Virtualbox does mess with the clock
<michagogo> I think it keeps the VM's hardware clock synced with the host or something
<michagogo> Which is annoying if you need to mess with the clock inside the VM
<michagogo> But I think there's a way to turn it off -- if not in the GUI, then with vboxmanage
<infinity> michagogo: That's completely broken behaviour...
<infinity> Of course, the best way to avoid it is to use kvm or Xen. :P
<michagogo> Heh, starting to google for "virtualbox disable..." first suggestion is "time sync"
<RAOF> infinity: You'll be in Malta next week, right?
<infinity> RAOF: Aye.
<infinity> siretart: I'm rejecting the libav binaries from the queue, so we don't half-start the transition on 4/6 arches.
<infinity> siretart: If you need help figure out the arm64/ppc64el build failures (in both cases, it looks like perhaps bad assumptions about the compatibility of vector assembly), ask.
<RAOF> infinity: Rad. It might be time to get to that AA training.
<infinity> RAOF: Yeah.  I'm trying to get arges to be a limited-scope AA just to be able to back me up for kernel SRU stuff (which requires AA because reasons), so maybe the three of us should spend some quality time together.
<slangasek> cjwatson, xnox: I got a ucf prompt on upgrade from trusty->utopic for /etc/kernel-img.conf.  Does d-i or ubiquity set this up for us on install, or was this my own doing?
<infinity> slangasek: d-i creates it, I believe, but what on earth thinks it owns it all of a sudden?
<slangasek> infinity: "kernel-common", because Manoj woke up
<RAOF> And by ârequires AA because reasonsâ what you mean is âneeds to be a member of ~ubuntu-archive because LP permissionsâ, as *I'm* a member of ~ubuntu-archive for the same reasons.
<infinity> slangasek: Ah-ha.  So, yeah, it was completely unowned in Ubuntu until then.
<infinity> RAOF: Yeah, that. ;)
<infinity> RAOF: But if we have people we "shouldn't" have in ~ubuntu-archive, I also want to make sure they're prepared to flex those permissions sanely when needed.
<infinity> (Or to remove them)
<infinity> (Or to get notes from their mothers promising they won't touch anything)
<RAOF> That's what I've done :)
<RAOF> People ask for things not-SRU-related, and I say âsorry, no can doâ âº
<infinity> slangasek: Did kernel-common always "own" it, and we only just recently pulled it in as a dep of something else?
<infinity> slangasek: I don't have it installed here...
<slangasek> infinity: no, from the changelog kernel-common is a new package; I had kernel-package installed for $reasons, and on upgrade it pulled in the new kernel-common
<infinity> slangasek: Indeed, new in sid and utopic.
<infinity> slangasek: So, that's entirely Manoj's fail.  He can't just take over a config file like that.  Go forth and smack him.
<slangasek> infinity: so I think we want to fix kernel-common to /actually/ install a file that matches what the installer does, or else launch the new package out of an airlock if we don't want it in utopic
<slangasek> infinity: is this a bug also in Debian?
<infinity> slangasek: Yeahp.
<slangasek> infinity: you want to do the smacking? :)
<infinity> slangasek: kernel-img.conf has the same semantics there, both its use in kernel postsints, and its unowned (until now) status.
<infinity> slangasek: You discovered it, smack on.
<slangasek> infinity: you seem to have a better handle on the details, surely the smack would be more effective from you :)
<infinity> slangasek: I tried.  Can't tab complete his name in #debian-devel.  I give up.
<slangasek> infinity: relatedly, why do we still create /vmlinuz and /initrd.img links by default?  That's silly
<infinity> slangasek: You mean why do we not default to link_in_boot=yes, or why have the links at all?
<slangasek> infinity: if we're going to have them at all, they should be in /boot, not somewhere that may be a separate filesystem; and the bootloader no longer uses them on x86 so we should probably not have them at all
<infinity> slangasek: Except for the 7 people who still use lilo, yeah, no one else uses them, I imagine.
<infinity> slangasek: But absolutely agreed that if we have them, they should be in boot (and I always alter my config to do so).
<slangasek> me too
<infinity> Anyhow, looks like the kernel-common thing was an overzealous reply to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626216
<ubottu> Debian bug 626216 in kernel-package "Manpage should live in a different package" [Minor,Fixed]
<infinity> I'm thinking just putting the manpage in linux-base and keeping the rest alone would have been saner. :P
<StevenK> I have do_symlinks = no, and yet /vmlinuz is a symlink to latest kernel
<infinity> StevenK: That's because it's do_symlink
<StevenK> Hah
<StevenK> I also don't have a kernel-img.conf manual page, which is helpful
<infinity> Oh, hrm.  No.  It's do_symlink in the code, but do_symlinks in the config file.  Whee.
<StevenK> Hahaha
<StevenK> infinity: Is this where I say "You're welcome." and back away slowly? :-P
<LocutusOfBorg1> Hi, can I ask somebody of the buildd team to retry a build failed?
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/wxwidgets3.0
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/wxwidgets3.0/3.0.0-3/+build/6030586
<LocutusOfBorg1> don't know, "compiler segmentation fault" doko_ do you have any idea?
<LocutusOfBorg1> maybe just a retry is enough
<infinity> LocutusOfBorg1: Retried, but I bet it fails again.
<LocutusOfBorg1> thanks infinity I hope not :p
<LocutusOfBorg1> I would like to upload some packages that use wx3.0 on debian
<LocutusOfBorg1> I don't want to see them in proposed until somebody retries/processes them, and I need at least the wx -3 release
<LocutusOfBorg1> because of the new package
<infinity> pitti: Your patches to do rebuilds with dpkg-buildpackage for linux/glibc fail because there's no fakeroot.  That needs to be in the deps.
 * infinity wonders if this is worth killing his sid build to fix...
<apw> infinity, pitti, yeah the rebuild fixes for linux fail for lack of fakeroot as well
<infinity> apw: Yeah, that's where I noticed the bug, and am now fixing it in glibc. ;)
<apw> infinity, so ... why isn't that build-essential
<apw> ie ... already installed
<infinity> apw: Because it's not.  gain-root is buildd-specific.
<infinity> apw: http://paste.ubuntu.com/7504510/
<infinity> apw: That's what I'm applying to glibc, something similar should do for the kernel.
<LocutusOfBorg1> :( g++: internal compiler error: Segmentation fault (program cc1plus)
<LocutusOfBorg1> Please submit a full bug report,
<apw> infinity, oh, i see ... unexpected but ok ... will get that applied to the kernel, not sure i want to upload for it though, uggg
<infinity> LocutusOfBorg1: File a bug on gcc-4.8 and poke doko about it.
<infinity> apw: Don't bother uploading for it, just queue it up.
<apw> infinity, also is there anything i can _test_ these changes on do you know
<infinity> apw: I'll just be naughty and ignore the -2.6 tests, if the other tests pass.
<apw> infinity, thanks :)
<infinity> apw: There's a magic wiki page somewhere about how to do adt at home.  I always lose it...
<infinity> apw: http://packaging.ubuntu.com/html/auto-pkg-test.html
<apw> infinity, also does the error line in p-m make sense to you, the version it reports for linux
<infinity> apw: The version there is completely bogus, yes.
<infinity> jibel: What's up with that?
<apw> jibel, http://paste.ubuntu.com/7504521/ is what it was saying
<apw> jibel, everything is right there in the sense there is a regression, but it is not in that version of linux
<LocutusOfBorg1> ok wilco
<LocutusOfBorg1> does anybody knows why cppcheck is still in proposed queue? https://launchpad.net/ubuntu/+source/cppcheck
<infinity> LocutusOfBorg1: Causes two packages to become uninstallable.
<infinity> Or, rather, the tinyxml2 transition does.
<infinity> Why is there a library in those metapackages? :/
 * infinity fixes...
<LocutusOfBorg1> thanks :)
<LocutusOfBorg1> doko_, ----> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1322485
<ubottu> Launchpad bug 1322485 in gcc-4.8 (Ubuntu) "wxwidgets3.0 arm64 fails to build with gcc 4.8" [Undecided,New]
<jibel> apw, infinity looking
<infinity> jibel: It's not actually causing a problem currently, but the reporting having the wrong version is definitely confusing. :P
<jibel> infinity, right, and in the logs of britney it's the correct version "Collected autopkgtest status for linux_3.15.0-2.6/linux_3.15.0-2.6: FAIL" I'll investigate further after the sprint today
<zyga> hey
<zyga> mvo: running update-manager on utopic today I've noticed that checkboxes next to package names are cropped (about 30% on the left)
<mvo> zyga: I can reproduce this, thanks! this smells like iz gtk bug because I don't think we changed update-manager in utopc much. just a internal change fo the meta-index stuff, nothing in the UI
<zyga> mvo: yeah, I suspect that as well
<zyga> mvo: want a bug report for that?
 * zyga wonders how to file that bug ;)
<zyga> if I use ubuntu-bug it will say packages are outdated
<mvo> zyga: lets discuss in malta, then I can nudge seb128 diretly to fix it :P
<zyga> if I update I cannot show the bug ;0
<mvo> zyga: hihi
<zyga> heh, sure :)
<zyga> mvo: I'm not in malta btw
<zyga> mvo: are you guys still there?
<mvo> zyga: aha, ok. I will fly there sunday
<zyga> oh, I heard some folks are there for a week or so
<zyga> nice place to sprint!
<mvo> zyga: I never went there, I'm curious about it
<infinity> mvo: 'iz gtk bug'... Haven't seen that in a while. :)
<Laney> I don't see that problem btw and gtk hasn't really changed in utopic yet
<mvo> infinity: soon it will be "iz qt bug" :P
<mvo> Laney: oh? hm, hm
<Laney> well, unless I don't know what I'm looking for :)
<Laney> it looks like http://ubuntuone.com/0ZlmWracPK89WzWSAUMAdf
<mvo> Laney: the gtk treeview  paints the "triangles" wrong and cuts parts of the text. once a expander is clicked (or theme is changed) it is ok again. simple resize is not sufficient
<mvo> Laney: http://ctrlv.in/335583
<infinity> Laney: Getting the most out of that service before June 1? :P
<jtaylor> if a package does not work at all as it does not support the software version in trusty, but a new upstream version does, can one SRU the new upstream?
<jtaylor> (subversion 1.8 and eclipse subversion plugin are the packages in question)
<infinity> jtaylor: If that's literally the only way to fix it, perhaps.
<Laney> infinity: Old habits die hard :P
<infinity> jtaylor: I assume it's the plugin you're talking about, not updating SVN itself?
<xnox> infinity: tinyxml library is used by gallery-app click.
<jtaylor> yes
<jtaylor> technically its a java library the plugin uses
<infinity> jtaylor: How scary is the delta, and can the necessary bits be backported?
<jtaylor> didn't look
<jtaylor> I'm wondering if can safe looking as there is zero regression potential
<jtaylor> it can't get worse than does not work at all
<infinity> xnox: Yeah, I saw the note in the seeds when I fixed it.  Gross that we're seeding libraries due to underrepresented (or unrepresentable) deps.
<xnox> infinity: hence it's in the touch seed, i've filed bug to either get tinyxml into the click itself, during click build. or move from tinyxml to qt.
<xnox> infinity: cause camera-app click to longer depends on tinyxml.
<infinity> jtaylor: Yeah, that's a pretty valid argument, I'd still like to see the proposed diff. :)
<jtaylor> svnclientadapter is the source
<infinity> You'd think 1.8 would work with 1.8...
<infinity> Silly people.
<jtaylor> I don't think the versions are coupled
<jtaylor> utopic has 1.10
<jtaylor> I'll check if a rebuild works first
<infinity> jtaylor: Is it svnclientadapter or libsvn-java that's the problem?
<jtaylor> (installing utopic in trusty works fine)
<jtaylor> the adapter
<jtaylor> its got a version == 1.7 check in it
<infinity> Are you getting this string? "Incompatible JavaHL library loaded.  Subversion 1.7.x required."
<jtaylor> yes
<jtaylor> the diff to utopic is not large
<jtaylor> but I don't see time well spent in backporting
<infinity> Theoretically, the package had a patch for that...
<infinity> Oh, no it didn't, I can't read.
<jtaylor> I'll file a bug that the package should have a stricter svn dependency
<infinity> But that one delta to src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java might fix it.
<jtaylor> yes, but is it really worthwhile testing if that is enough?
<pitti> infinity, apw: argh, sorry about that; thanks
<jtaylor> upstream tested utopic with 1.8
<jtaylor> so we should use that for trusty
<pitti> apw: right, I don't think you need to upload just for that -- new kernels come often enough anyway? :-)
<jtaylor> instead of trying to do a partial backport
<infinity> pitti: Should this be the right fix? http://anonscm.debian.org/viewvc/pkg-glibc?view=revision&revision=6105
<infinity> pitti: Identical commit was made to the kernel.
<infinity> jtaylor: Sure, bumping the version might be the saner thing to do, just want to explore options.
<infinity> jtaylor: It's certainly not an enormously scary diff.
<pitti> apw: BTW, http://people.canonical.com/~pitti/tmp/linux-autopkgtest/ are the updated tests for linux-exynos5 (now including fakeroot)
<pitti> apw: that also restricts the test to armhf, to avoid a failure on x86
<pitti> infinity: looks good; -rfakeroot should be the default these days though?
<infinity> pitti: It is, but if we're explicitly depending on a specific gainroot, I feel we should also explicitly call it.
<pitti> *nod*
<infinity> pitti: Why the need to restrict tests to armhf when the source only produces armhf binaries?   That seems like a test infra issue, not something that should be literring tests.
<infinity> pitti: It makes exactly zero sense to run tests on an arch the package doesn't build for.
<pitti> ah, I guess we could apply some debian/control parsing magic to find that out, yes
<infinity> pitti: Or just read the .dsc
<infinity> pitti: Oh, but you only work with unpacked trees?
<infinity> Anyhow, that package is also buggy and claims to build arch:all packages that it can't possibly.
<pitti> infinity: tree, .dsc, or (as in production) apt-get source
<infinity> I fixed that in linux-ppc long ago, I guess the stupid carried over. :P
<pitti> so debian/control it is
<infinity> pitti: Kay, apt-get source gets you a .dsc, which is much easier to parse than control in this case.
<infinity> But meh.
<infinity> First, control needs to be fixed to stop pretending it builds things it doesn't.
<infinity> apw: Where is the exynos5 git?
<cjwatson> xnox: does the click package in question actually link against tinyxml directly, or is it perhaps via libmediainfo?
<pitti> well, needs to work for anything, so debian/control it is; but the parsing isn't the problem really, it's figuring out from the Architecture: fields whether or not this applies
<cjwatson> xnox: (compare gallery-app.deb)
<apw> infinity, now why did i need to know that already this week
<infinity> pitti: Sure.  In this case, you'd (rightly) guess wrong, I think, since there are arch:all debs, but there shouldn't be.
<infinity> Oh, wait, the git is right there in the control.  I wonder if it's right.
<xnox> cjwatson: actually, i think you are right. I'll test that out.
<apw> infinity, i'd assume it is git://kernel.ubuntu.com/hwe/ubuntu-trusty-meta-exynos5.git
<apw> infinity, i'd assume it is git://kernel.ubuntu.com/hwe/ubuntu-trusty-exynos5.git
<infinity> apw: Yeah, that's what I'm cloning right now.
<infinity> apw: Do you have write access to that, or do I need to bug ike with a patch?
<apw> i should have, but will check
<apw> infinity, that repo is _ahead_ of the archive
<infinity> apw: That seems reasonable...
<infinity> zinc needs a go-faster button.
<apw> i do have write access to it indeed, though this out of sync fun makes life trixy
<cjwatson> xnox: objdump -p <ELF object> | grep NEEDED  should show it
<xnox> cjwatson: right. it has NEEDED libmediainfo.so.0, and no mentions of tinyxml.
<xnox> cjwatson: so infinity's seed change can go it & unblock that transition.
<infinity> xnox: It's already in...
<infinity> final: cppcheck,libmediainfo,tinyxml2,ubuntu-touch-meta
<infinity> SUCCESS (26/0)
<xnox> i wonder if i should be subscribed to -changes mailing list =)
<infinity> I had to do that update by hand, though.  Turns out ./update doesn't work so well when the thing you're seeding only exists in proposed...
<infinity> Quite annoying.
<cjwatson> it sounds like the correct seed change (given the intent) would actually have been to seed libmediainfo0 directly.
<infinity> Perhaps, yes.  I was just following the ABI change, this was before anyone did analysis into the why.
<infinity> libmediainfo0 appears to already be there anyway.
<infinity> So libtinyxml and libzen could both go away from the seed, I'd think.
<infinity> But I'll leave that to someone who knows more about this stack.
<infinity> pitti: So, the bug where exynos5 claims to build packages it doesn't will be fixed in the next upload, at which point a parsing of debian/control or .dsc will return nothing but armhf.
<infinity> pitti: Which, to me, seems much saner than arch-restricting the test in the source, but YMMV.
<infinity> pitti: OTOH, I'm not sure there's value in that test in that source anyway.  The point of the glibc/linux/binutils/gcc rebuilt test circle is just to make sure no part of the toolchain breaks another part.  I'm not sure there's much extra value in making sure every out-of-tree kernel builds.
<cjwatson> hallyn: So I belatedly looked through your log from last night.  Your problem is that your preseed file isn't being read at all.  You either need to add file-preseed to your image (build/pkg-lists/netboot/common, probably), or (perhaps easier) given that you're embedding the preseed file in the initrd anyway, just embed it specifically as "/preseed.cfg", at which point it will be read automatically and you can drop the file= boot ...
<cjwatson> ... parameter.
<cjwatson> (We should perhaps add file-preseed to netboot images at some point, since it's in Debian's)
<siretart> infinity: yes, I could really use some help on those two ftbfs. for arm64, I guess it would be a matter of identifying the upstream commits in master that need to be backported. Please tell me and I see to include them for 10.2
<siretart> infinity: for ppc64, I have no idea what this is supposed to mean, nor what could be causing it: /usr/bin/ld: libavcodec/libavcodec.a(fft_altivec_s.o): ABI version 1 is not compatible with ABI version 2 output
<infinity> siretart: It means it's trying to link a big-endian and little-endian object together.
<infinity> siretart: Which probably means the Altivec bits are endian-specific.
<siretart> I guess we could disable altivec on ppc64 and neon on arm64
<infinity> siretart: Which should be fixed, but the easiest solution would be to disable altivec on ppc64el.
<siretart> do we have PPA where I could do the testbuilds, or can you take care of that?
<infinity> siretart: And I haven't looked at the neon code in question, but it's probably similarly buggy in assuming neon == armv7t2 or some such.
<infinity> siretart: I can do some test builds for you, though possibly not right this instant.
<siretart> no problem, take your time
<siretart> if we can push this transition before the beta, that'd be great
<infinity> siretart: That seems like a pretty doable goal.
<siretart> while the transition is not fully over, libav reached testing yesterday, and going with libav9 is imo a no-go for utopic
<infinity> siretart: So, with libav9, was it using altivec on ppc64el and neon on armv8?
<infinity> siretart: If so, we should perhaps figure out what broke in each case.
<infinity> siretart: But I'd suspect it never was before, and now it's detecting "correctly", which happens to be incorrectly for the code in question.
<siretart> that's entirely possible
<siretart> if you need help, you might want to talk to jannau on #libav-devel@freenode, he was doing most of the aarch64 work lately
<infinity> siretart: Well, I'd happily just turn off both SIMD options and sort it out later, my only concern is that fixing it later might change the ABI.
<siretart> --disable-neon in debian/confflags should do the trick then
<siretart> in that case they will use the plain C version
<siretart> I don't have ABI concerns here
<infinity> siretart: You don't have ABI concerns because you don't care if it breaks, or because you're positive the alternate SIMD implementations are opaquely hidden behind a stable ABI? :)
<xnox> infinity: cjwatson: should cross-pkg-config, allow cross-compiling against non-multiarched libraries?
<cjwatson> Err.  I'd be inclined to say probably, since the worst it can do is make errors more confusing
<xnox> cjwatson: ack, and it would unblock a lot of cross-compilation queries i'm getting in #ubuntu-unity, for leaf -dev packages that are not multiarched yet.
<cjwatson> I don't think it's vital, since there are other fixes possible, but it probably smooths the path
<infinity> How is it currently preventing it?
<xnox> infinity: commented out /usr/lib/pkgconfig from PKG_CONFIG_LIBDIR in /usr/share/pkg-config-crosswrapper
<Laney> It says "  # If you want to allow use of un-multiarched -dev packages for crossing
<Laney>   # (at the risk of finding build-arch stuff you didn't want, if not in a clean chroot)
<Laney>   # Uncomment the next line:
<Laney> "
<cjwatson> My opinion on the spur of the moment on IRC doesn't necessarily override reasoned argument that you might find in the history, of course
<infinity> xnox: Hrm.  Perhaps changing that to be keyed off an environment variable instead of encouraging people to edit the script? :P
<xnox> infinity: by default, it is keyed off environment.
<xnox> cjwatson: Laney: infinity: i'm thinking this might be a simple regression, cause package was forced synced.
<infinity> xnox: I can absolutely understand the reasoning.  The errors would be confusing to the "average" person if they had wrong-arch libs found because of that.
<infinity> xnox: Err, no, I mean that particular bit keyed off environment, not asking people to set the entire PKG_CONFIG_LIBDIR themselves.
<xnox> Well, previous edition of pkg-config-wrapper was a two-liner:
<xnox> triplet=`basename $0 | sed -e 's:-pkg-config::'`
<xnox> PKG_CONFIG_PATH=/usr/lib/${triplet}/pkgconfig:/usr/${triplet}/lib/pkgconfig pkg-config $@
<infinity> xnox: So, that was buggy in that it missed /usr/share, and it also missed the directory you're talking about.
 * xnox ponders what are the differences between PKG_CONFIG_LIBDIR & PKG_CONFIG_PATH
<xnox> infinity: we used to prepend multiarch paths, now we replace all paths with multiarch-only without original.
<xnox> which is regressing cross-buildability of a lot of touch stuff in ubuntu.
<infinity> xnox: That's not what your paste implied.
<Laney> I've already eaten this change for a few libraries, but letting people opt back in might be a good idea
<infinity> xnox: Anyhow, if we were including /usr/lib/pkgconfig before, and no one was complaining about it being confusing, go ahead and uncomment that line.  If you're positive that's how it used to work.  Your paste certainly doesn't imply what you said, though.
<infinity> Oh, I see.
<infinity> PKG_CONFIG_PATH behaves differently.
<infinity> Kay.
<infinity> xnox: Yeah, possibly just the path of least reistance to uncomment that line in Ubuntu, since that was the previous status quo, if no one was complaining about the occasional breakage.
<infinity> Curiously, the old way we did it would have never worked when crossing to i386.  Obviously not something many people do.
<siretart> infinity: we use linker scripts to hide internal symbols. applications have (or at least should not) no way to access those internals directly
<infinity> siretart: Some quick symbol dumps certainly look to agree with you.  So, yeah, if you want to just disable neon on arm64 and altivec on ppc64el, that would get you over the hump for now, though it would be really good to make sure we revisit both.
<siretart> absolutely, we should do that. In terms of priority, transitioning the archive seems more important and time-critical to me at this point, though
<siretart> infinity: if you have a look at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=debian/confflags, disabling neon for arm64 and altivec on powerpc should be straight forward, if you know what to look for (I would need a porter machine to look up what environment variables to test for)
<infinity> siretart: Kay.  I'll try to have a look at that after I've slept a bit.
<siretart> infinity: Thanks!
<ahasenack> hi, anyone know why the systemd-logind crash isn't fixed yet in trusty? It happens on every login since the release, seems very high priority
<mdeslaur> ahasenack: what crash is that? do you have a bug number?
<ahasenack> mdeslaur: just a crash report, that I upload everytime, but apport doesn't tell me what it did with it
<ahasenack> -rw-r-----  1 root whoopsie 145K Mai 23 09:00 _lib_systemd_systemd-logind.0.crash
<ahasenack> -rw-r--r--  1 root whoopsie    0 Mai 23 09:00 _lib_systemd_systemd-logind.0.upload
<ahasenack> well, I don't upload it everytime anymore, got tired of that :)
<ahasenack> but did upload it today
<mdeslaur> ahasenack: I don't see it being reported on errors.ubuntu.com by anyone, sorry
<mdeslaur> ahasenack: perhaps file an actual bug about it? does it happen in your guest account too6
<ahasenack> it was a fresh install
<ahasenack> but haven't tried the guest account
<ahasenack> I suspect most people suspend/resume
<ahasenack> it happens after a cold start, first login
<mdeslaur> ahasenack: I definitely haven't seen that, and there aren't any errors being reported about that
<mdeslaur> ahasenack: so please file a bug
<ahasenack> ok
<ahasenack> mdeslaur: do you know where my crash report went?
<ahasenack> I've got colleages who also tell me they clicked the report button in the crash dialog box dozens of times
<mdeslaur> ahasenack: is this it? bug 1309025
<ubottu> bug 1309025 in systemd (Ubuntu) "systemd-logind assert failure: cgmanager-client.c:6322: Assertion failed in cgmanager_list_children_sync: proxy != NULL" [Medium,Confirmed] https://launchpad.net/bugs/1309025
<ahasenack> mdeslaur: could be, let me look at my stacktrace from the crash file
<xnox> ahasenack: do you have cgroups-lite installed?
<ahasenack> xnox: yes
<xnox> ahasenack: uninstall it & reboot. check if that fixes it for you.
<xnox> ahasenack: you want cgmanager installed at the same time (if not otherwise installed)
<ahasenack> xnox: isn't that needed by lxc? cgroups-lite?
<ahasenack> Title: systemd-logind assert failure: cgmanager-client.c:4546: Assertion failed in cgmanager_get_value_sync: proxy != NULL
<xnox> ahasenack: no.
<ahasenack> that's the title from my crash report
<ahasenack> so yeah, looks like it's the same bug
<xnox> ahasenack: although i have cgroup-lite installed and everything works fine....
<xnox> hm...
<ahasenack> xnox: cgmanager is installed too already
<mdeslaur> xnox: I also have cgroup-lite installed
<ahasenack> xnox: can't remove cgroup-lite:
<ahasenack> The following packages will be REMOVED:
<ahasenack>   cgroup-lite* libvirt-bin*
<xnox> mdeslaur: hm, why does libvirt-bin & utah still use cgroup-lite?
<xnox> hallyn: jibel: can libvirt-bin & utah switch to use cgmanager instead of cgroup-lite
<xnox> ?
<lamont`> infinity: actually, dannf wrote the code to fail implicit-conversions... I just brought it over to ubuntu, and yes, it's a far worse (though less frequent ant therefore a total surprise in debugging) on amd64
<marga> infinity, ping? We've added more info to the weird libx32 bug (https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605)
<ubottu> Launchpad bug 1302605 in eglibc (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang" [Undecided,Confirmed]
<marga> infinity, we believe it's an issue related to auditd being enabled, and that it's the kernel who's at fault.
<marga> Uhm, seems infinity is sick and away... Is there anybody around here knowledgeable on both kernel issues and auditd that could give a hand?
<yoh> Hi guys, I wondered if there any recipe somewhere to replicate existing PPA environment locally? in particular to the given version of kernel.  PPA build (on 12.04) fails in a unique fashion and we need to troubleshoot it.
<geser> marga: even infinity sleeps now and then
<marga> geser, sure, I thought he was in more or less my timezone, but I might be wrong.
<ScottK> He did say he was sick yesterday.
<marga> His away message says so.
<geser> hmm, ok, he was active up till around 90 min ago and his last words were "after I've slept a bit."
<marga> Oh, ok.
<marga> geser, thanks for the info.
<leex> hi, my do-release-upgrade segfaults with this error message: http://paste.ubuntu.com/7505633/ while trying to upgrade 13.04 to 13.10 does anyone have an idea on how to fix it?
<ara> stgraber, salut! qt-base has been in the trusty unapproved queue for quite a bit of time now (https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=)
<ara> stgraber, and it will help solve an important bug (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1307701)
<ubottu> Launchpad bug 1307701 in qtbase-opensource-src (Ubuntu Trusty) "xserver mouse pointer emulation from touch breaks with QML app." [High,In progress]
<ara> stgraber, as SRU team member, could you please have a look, please?
<TJ-> leex: It suggests there is an illegal UTF8 character in one of the existing /etc/apt/sources.list.d/* files
<leex> TJ-: damn I had an .un~ file in there :/ maybe they should be ignored by the script, thanks!
<leex> TJ-: nevertheless, thanks a lot, upgrading works now :)
<ScottK> ara: The tools the SRU team use for SRU processing don't really work for CI train syncs so they tend to not get looked at as often.
<ara> ScottK, so, do I have to do anything differently to make sure it is looked at?
<ScottK> No. I'm sure it will get looked at.
<hallyn> cjwatson: d'oh, but som eof the questions i thought weren't being asked.  i think i've been copying it lately as the wrong filename now that you mention it, but in the past it has never taken the username preseeds while it didn't ask me for partitioning...  hm.  well i'll fix the filename and test next week.  hoefully i'll just feel silly and it'll work :)
<hallyn> xnox: do you mind opening a bug against libvirt?  i'm out until next tue.  i had originally wanted to do it during 14.04 cycle
<hallyn> i need to do that as well as test out the upstart patch.  but, dropping irc now - ttyl
<infinity> marga: I'm not quite asleep yet, but also in no shape to wrap my head around that bug either.
<marga> infinity, well, pkern just found a fix
<marga> infinity, it's 3 lines in one .S file :-/
<infinity> marga: Oh, handy.
<marga> infinity, he's updating the bug now, with the diff.
<infinity> marga: Lovely.  Who's to blame?
<marga> infinity, uhm... the interaction between x32 syscall masking and auditd
<marga> when running on x32, syscalls have an extra high bit, that needs to be removed before calling auditd, and this wasn't happening.
<infinity> apw: Can you have a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1302605
<ubottu> Launchpad bug 1302605 in linux (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang when using auditd" [Undecided,Confirmed]
<infinity> marga: Thanks to you (and pkern) for the debugging and patch.
<marga> infinity, :)
<infinity> marga: Does he intend to push that upstream himself?
<marga> infinity, upstream being kernel.org?
<infinity> marga: Yeah.
<apw> infinity, x32 ?
<infinity> apw: Yeah, check the last couple of comments.
<infinity> pkern: Oh, I guess you're here, I could ask you directly. :P
<marga> infinity, ok, he says he will try to do it
<apw> infinity, yeah that looks about right, do i need to do something, or are they interacting upstream about it
<infinity> apw: The last two lines of IRC backcroll seem to imply that pkern will attempt to upstream it, but if it passes muster for you guys, SAUCEing it and then replacing with an upstream commit might not be terrible.  Seems like the sort of thing that shouldn't blow up.
<apw> infinity, ok, will ahve a poke
<marga> apw, personally, given my experience with previous kernel.org patches coming from non kernel hackers, it would be nice if this could get applied early.
<infinity> apw: Which is why I also gave it a trusty task for you (probably broken in saucy too, but carefactor of zero there)
<pkern> infinity: I'll try. As you might now... Is there a primary x32 maintainer?
<infinity> pkern: Not sure on the kernel side.  x32 in general is HJ Lu's baby, but I have no idea if he's also doing kernel or just toolchain.
<pkern> I saw his name on the ABI documents at least.
<pkern> Ok.
<infinity> pkern: It might fall in hpa's lap.  Dunno.
<infinity> pkern: The patch looks pretty mind-numbingly obvious, so I don't imagine much push-back if you can actually get noticed and get it in the right person's patch queue.
<infinity> pkern: Anyhow, I think apw will be a gentleman and get it into the Ubuntu kernel for you guys soonish, but you should be the one submitting upstream for attribution and bragging rights.  We can swap the local patch for the upstream commit when it happens.
<apw> infinity, pkern, that indeed
<pkern> infinity: ACK, thanks!
<cjwatson> xnox: is lp:~xnox/ubuntu-test-cases/touch-emulator still maintained?
<cjwatson> xnox: just want to check if I'm working on the right basis for building autopkgtest stuff around it - if so, I have a patch to fix it up for python3 on the target
<xnox> cjwatson: i don't believe that's latest. There was work done by #ci folks around touch-emulator.
<xnox> cjwatson: i'd take patches / fixes for it.
<xnox> cjwatson: plars tells me latest is in https://code.launchpad.net/~doanac/ubuntu-test-cases/emulator-scripts
<cjwatson> Aha, right
<xnox> cjwatson: about to land (it's emulator/x86 focused)
<cjwatson> you have mail anyway
<xnox> cjwatson: ack. will review.
<cjwatson> looks like it's obsolete with that new branch
<xnox> IMAGE_OPT="--channel ubuntu-touch/utopic-proposed --arch=i386" USE_EMULATOR=1 xvfb-run -a -s "-screen 0 640x480x24" ./scripts/run-smoke -a friends-app
<xnox> is the new way of doing things.
<xnox> plars telling in #ci =)
<plars> hi
<plars> Having some issues on the emulator side though
 * cjwatson notes
<plars> I ran it yesterday a few times and saw the emulator crash
<cjwatson> I did manage to get xnox's scripts working today, but only one in three or so emulator runs actually starts up properly
<plars> trying it with larger tests (webbrowser for example), the device just disappeared at one point on me
<cjwatson> I had adb push hang at one point too
<zyga> hey, is there any reason why python3-dbg doesn't load any native modules? I cannot import lxml and other things like that
<zyga> barry: ^ any idea?
<zyga> I need to poke around a problematic python app with gdb
<zyga> and I want to have access to all the fancy py- macros in gdb
<stgraber> c
<stgraber> oops :)
<zyga> too much gdb
<zyga> ;)
<zyga> s/python/python3/
<xnox> stgraber: is your login name "c" and pasword "oops :)" ?! =)
<stgraber> xnox: sure is :)
 * ogra_ throws envious looks at stgraber ... 
<ogra_> i just read that you can get symmetrical 1GBit fiber in switzerland now
<ogra_> evil !
<zyga> ogra_: you make me sick,
<zyga> ogra_: that should be illegal ;)
<ogra_> ++
<ogra_> and they say thats the low end offer ! they plan even bigger setups
<zyga> ogra_: they must make up for the fact they have no sea ;)
<ogra_> lol
<xnox> zyga: they have lakes to make up for that ;-)
<barry> zyga: you need to install the -dbg packages for any extension modules
<zyga> barry: thanks
<zyga> barry: I reverted to using plain python3 and py-bt finally works :)
<zyga> it's godsend when a multi-threaded dbus service deadlocks
<barry> nice
<xnox> everything is nice about dbus, apart from writing bindings to dbus services or debugging it server side.....
<stgraber> ogra_: sort of, it's been possible to get gigabit or even 10gbit fiber for a few years now but not through mainstream ISPs and obviously retricted to tiny areas, now swisscom launched their fiber service which is covering quite a few more cities but it's still a long way from being the usual kind of speed
<ogra_> ah
<stgraber> ogra_: nowadays your standard internet over there is around 150/15 over cable, with the fast one being 250/25, both pretty reasonably priced
<stgraber> however, as I don't live there anymore (I just happen to be there this week before Malta) I don't get to enjoy it too often, my home connection in Montreal is just 30/10 vdsl (but very very stable, native ipv6, static IPs, ... so perfect for work)
<stgraber> well, I can get 250/25 over cable in Montreal, it's just that it'd come with a stupid 500GB quota and won't allow using it for home servers, so not really an option...
<ogra_> i could get 50/25 VDSL here ... if i only could get rid of my 2M SDSL line
<xnox> i have 120/10 in London. And I am disappoint. Fairly static IPs (~ it renews only about 2 times a year, or well never if you keep your router on), no IPv6 =(
<Laney> at least no CGNAT on virgin... yet...
<cjwatson> xnox: Is that ADSL?  You could probably get native IPv6 from A&A then
<xnox> cjwatson: that's cable. I have not had ADSL since 2010. (since there is no options but ADSL in Hull)
<xnox> cjwatson: A&A is pricey =)
<cjwatson> They actually improved their pricing a fair bit recently from my point of view, so I was going to look at them again after I got back from Malta
<stgraber> my current DSL provider also comes at a premium vs the usual ones, but that's what you have to pay to get good service and competent support when things go wrong. Otherwise you'll end up with the usual "did you update Windows?" kind of tech support and will be stuck without internet for a week...
<stgraber> (though with DSL, it's usually the phone provider that screws up and unfortunately you can't quite change that, unless you go cable and then it's even worse, at least in Canada)
<cjwatson> A&A take special pride in browbeating the phone provider into fixing things faster than anyone else, which is one reason I'm interested :)
<cjwatson> Anyway, EOW
<stgraber> :)
<stgraber> ok, have fun, see you on Sunday/Monday!
<rbasak> xnox: I'm with A&A. For the quality I get, I don't think 100GB/mo for Â£25 (+Â£10 line rental) is pricy.
<rbasak> It's sometimes a bit annoying to have to watch the bandwidth when doing some repeated test that uses cloud images though.
<rbasak> I tend to try and do that sort of thing somewhere online instead, rather than local.
<elmo> I agree, I don't think A&A is pricey either; I'll happily pay their prices for a competent ISP and the native v6 is a nice added bonus
<xnox> rbasak: i should find out how much bandwidth i waste, cause we stream television over the internet (via russian channels subscription)
<ryanneufeld> Can someone point me to a guide for building my own deb packages for trusty that doesn't include all the bazzar and launchpad stuff?
<apw> pkern, ok test kernels are posted in the bug, if you could let me know how they pan out.
<Henne91> Hey guys! I'm trying to create a patch to fix/workaround the following bug: https://bugs.launchpad.net/ubuntu/+source/indicator-keyboard/+bug/1240198
<ubottu> Launchpad bug 1240198 in indicator-keyboard (Ubuntu) "wrong keyboard layout active after booting into desktop, after upgrade to saucy" [High,Confirmed]
<Henne91> I've never done this before so I thought maybe somebody here can help me with this.
<Henne91> Basically it seems like it is necessary to create an additional config file for ibus to change its default behaviour.
<Henne91> I used Quilt to create the file as a patch.
<Henne91> Ok, just found the required infos in the docs. Nevermind! ;-) Thanks anyway.
<smoser> hey, is there any way of getting ddebs through a ppa ?
<dobey> smoser: you can request it be enabled for your ppa i think
<smoser> dobey, just as in a request to launchpad ?
<smoser> specifically i'm after this for cloud archive, which is built via a ppa and then copied elsewhere.
<dobey> smoser: as in asking an lp admin, yeah.
<dobey> smoser: ask, as in the asme way one would ask for arm support in a ppa
<smoser> dobey, thanks.
 * xnox stops doing random uploads and goes to pack
<Shock> hi
<Shock> I've made a patch for #1247584 and tested locally on my system. would anyone be willing to help me prepare the patch for inclusion in ubuntu?
<sarnold> Shock: oof, looks complicated. If you attach your patch to the bug, it'll kick off another bot that'll add some messages and perhaps prod other people into looking at the bug to sponser the patch.
<Shock> sarnold: thanks. would've liked to learn how to do it myself, though.
<sarnold> Shock: makes sense :) do you have sbuild set up on your machine yet? That'd be a handy next step, if not; that'll make it easier to test patches in the packaging
<Shock> sarnold: nope, I've been building the packages with dpkg-buildpackage
<sarnold> Shock: ah, fair enough. for occasional use that's just fine :)
<sarnold> Shock: what does 'what-patch' return for that package?
<Shock> quilt
<sarnold> Shock: nice. if you quilt push -a all the patches onto the queue, then you could use quilt import /path/to/patch to add your patch to the end of the file
<Shock> sarnold: I've been reading http://packaging.ubuntu.com/html/fixing-a-bug.html but I don't understand the relationship between all the parts
<Shock> sarnold: I've already built a package with the patch locally
<sarnold> Shock: nice! now you need a debdiff. this is the part that gets hard for me, because I use a different toolchain that automates this away from me :) hehe
<Shock> sarnold: I've installed devscripts
<sarnold> Shock: did you update the debian/changelog?
<sarnold> (add new version etc)
<Shock> sarnold: no
<sarnold> Shock: okay, dch -r will help you there :)
<Shock> sarnold: I dont know all the rules pertaining to the changelog/versioning so I've left it alone. the package I've built has the same version as the one in the archive
<sarnold> Shock: there's some version update examples here: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<Shock> sarnold: ok, I'm in the editor
<Shock> this is insane :) is it not possible to automate it somehow?
<sarnold> Shock: that's the handy tool I mentioned earlier :) I'm not sure if it would repay the setup costs for just dealing with a package once in a while, but it's really handy for dealing with five versions of four packages each week :)
<Shock> sarnold: I'm talking about stuff like "Please be careful. Security updates must have a version number higher than any version that was in the archive for that release. This means you must check the release pocket, theÂ proposedÂ pocket and theÂ updatesÂ pocket (seeÂ SecurityTeam/FAQ#RepositoriesÂ for details)."
<Shock> sarnold: it seems very error prone
<Shock> sarnold: in time, I plan to understand the relationships between pbuilder, dpkg-buildpackage, sbuild, schroot, debootstrap, etc
<Shock> sarnold: seems a lot to take in
<sarnold> Shock: the launchpad 'source package' page will have version numbers all handily collected in one place; check https://launchpad.net/ubuntu/+source/systemd for the numbers
<sarnold> Shock: (again, this is another step that is abstracted away a bit by the 'umt' tool I use, it'd be 'umt search system' -> http://paste.ubuntu.com/7507428/
<Shock> sarnold: if I understand correctly, my version should be 204-5ubuntu20.3
<sarnold> Shock: looks right to me
<Shock> sarnold: ok, I'm in the editor spawned by dch -r
<Shock> sarnold: at the top is the last official changelog entry
<sarnold> Shock: oh man. I'm sorry. I mis-remembered. :( quit out of that without saving..
<sarnold> Shock: dch -a  should do what you want
<Shock> sarnold: with my name under it :-/
<Shock> sarnold: I must've done something wrong because dch -a is somehow replacing the last changelog entry
<sarnold> Shock: it didn't make a new one for you?
<cjwatson> dch -i would be more usual for that.
<Shock> sarnold: no, I think this is because I've issued a debcommit at one point in order to comply with what dpkg-buildsource was asking
<cjwatson> dch -a explicitly asks to append to the current entry.
<sarnold> cjwatson: sigh. thanks. :)
<sarnold> neat though, that'll be handy to have.
<sarnold> Shock: twice wrong in one go. sorry. sigh.
<Shock> ok, dch -i left the last entry intact and created a new one for me. it doesn't have the version at the top like the last official entry
<Shock> sarnold: don't worry, this way I've learned the difference between dch -r, -a, and -i :)
<sarnold> Shock: haha :) me too, when before all I ever used was -r ..
<sarnold> (which worked in my workflow, 'umt changelog' does the dch -i with a calculated version number...)
<Shock> sarnold: I prefer to stay with the low level stuff until I understand how the plumbing works, then move to higher level stuff
<sarnold> Shock: *nod*
<Shock> sarnold: this is the top of the changelog in the editor: http://paste.ubuntu.com/7507454/
<sarnold> Shock: nice; could you also add (LP: #1247584) to the comment, so the bug will be closed when the package is uploaded?
<ubottu> Launchpad bug 1247584 in systemd (Ubuntu) "[keymap] Since upgrade to Ubuntu 13.10, udev doesn't map middle mouse button." [Undecided,Confirmed] https://launchpad.net/bugs/1247584
<Shock> sarnold: added! do I need to add a version line?
<sarnold> Shock: yes, I believe 'trusty-updates' for the release name
<Shock> sarnold: added "systemd (204-5ubuntu20.3) trusty-updates; urgency=medium", what now?
<Shock> parsechangelog/debian: warning:     debian/changelog(l3): found start of entry where expected start of change data
<Shock> LINE: systemd (204-5ubuntu20.3) trusty-updates; urgency=medium
<Shock> parsechangelog/debian: warning:     debian/changelog(l3): found eof where expected start of change data
<Shock> got that after saving
<sarnold> Shock: rebuild the package; find a pristine copy of 204-5ubuntu20.2 source package -- and use debdiff between the two .dsc files to generate a debdiff that you can attach to the bug and ask for a sponser
<Shock> sarnold: should I ignore the warning from dch?
<sarnold> Shock: I -think- your asterisk was one column too soon
<sarnold> the one on line 8 is under the second 's' in 'systemd', make sure yours lines up on the same column
<Shock> sarnold: it seems alligned with the other asterisks. dch added a line above my version line "systemd (204-5ubuntu20.3) UNRELEASED; urgency=medium"
<sarnold> Shock: ah, yeah, you only need one of those lines
<Shock> sarnold: I'll delete the one added by dch
<Shock> sarnold: I've run debdiff: http://paste.ubuntu.com/7507521/
<sarnold> Shock: you ought to be using the 20.3.dsc from your 'work' directory instead
<sarnold> (it'll be built once you rebuild the package with your new changelog entry in place)
<Shock> sarnold: I dont have a 20.3.dsc :-/
<Shock> oh
<Shock> is a source build sufficient?
<sarnold> it should be for a changelog-only change
<Shock> sarnold: it's telling me it detected local changes (to files I've not modified) and aborting. do you need pastebin with the errors?
<sarnold> Shock: try quilt pop -a and then rebuild?
<Shock> sarnold: debdiff worked but maybe using what it output would be giving the maintainer more work than attaching a simple diff :(
<sarnold> Shock: maybe, can you pastebin it?
<Shock> sure
<Shock> sarnold: http://paste.ubuntu.com/7507563/
<ScottK> sarnold: Actually trusty or trusty-proposed.
<sarnold> ScottK: oh! thanks
<sarnold> Shock: man that looks very nearly awesome. the patch headers for the 99-keyboard-test.patch are funny :) -- those should be replaced with something more useful
<infinity> Just trusty, please.
<Shock> sarnold: it told me "The information above should follow the Patch Tagging Guidelines" and I was like "eject! eject!" :) information overflow
<sarnold> Shock: hehe yeah I've had this tab open for nearly two years now :)  http://dep.debian.net/deps/dep3/
<infinity> The boilerplate it gives you should be enough to go by, usually.  Just fill in the blanks.
<Shock> sarnold: I'm gonna modify the debdiff directly. how do I check if it applies cleanly to the pristine package source?
<sarnold> Shock: unpack the sources in a clean tree, then run patch --dry-run -p1 < /path/to/debdiff -- ifit applies, then take off the --dry-run, re-apply, then re-run the build
<Shock> sarnold: there's a patch in the patches directory that creates a whole file (on which my patch depends on). how do I ensure my patch is run after the other one? does quilt take care of the ordering?
<infinity> Shock: ordering is based on the order in the series file.
<Shock> infinity: thanks, then I'll drop the numeric prefix from the patch file name
<Shock> sarnold: ok, I edited the debdiff, applied it and built the package
#ubuntu-devel 2014-05-24
<Shock> sarnold: thanks for all the help, I learned a lot tonight. I'll check back tomorrow. good night!
<Logan_> ari-tczew: why did you sync connman?
<Logan_> "feel free to take" doesn't mean "feel free to indiscriminately sync"
<ari-tczew> Logan_: that's yours own understanding, I didn't say that
<Logan_> okay, so explain why you dropped the entire delta
<ari-tczew> Logan_: because Debian has pulled in our changes
<ari-tczew> Logan_: what is it? inspection?
<ari-tczew> Logan_: I'm not spying your uploads even if they got in result FTBFS
<Logan_> now you're accusing me of spying on you?
<Logan_> I was the TIL for that package, and I deferred it to someone else because of the extensive changes that needed to be considered
<Logan_> then I see that it was synced in #ubuntu-release
<ari-tczew> Logan_: dunno, that was ~10 minutes ago
<Logan_> so you don't remember?
<ari-tczew> Logan_: I mean that was fresh upload
<ari-tczew> answer "dunno" is related to your "spying" topic
<Logan_> ari-tczew: did you consider the differences in the install files?
<infinity> ari-tczew: Unless the Debian changelog is awfully quiet about it, there's no way this has our entire delta.
<infinity> +    - Add upstart script.
<infinity> +    - Add apport hook and crashdb file.
<infinity> +    - Notify the user a reboot is required after updating connman.
<infinity> +    - Don't disable the service if NetworkManager or wicd are installed; we use
<infinity> +      Conflicts instead.
<infinity> +    - Recommend indicator-network.
<infinity> For instance...
<infinity> Plus the manpgage changes, etc.
<Logan_> all of those are actually in Debian, but there are things that were wiped out of the install file that probably shouldn't have
<infinity> Logan_: Really?  Kay, the debian changelog mentions none of them, I haven't actually looked at the source.
<Logan_> yeah, the changelog is very sparse in Debian and doesn't reflect everything
<dobey> infinity: hi! feeling better?
<infinity> dobey: Nope!
<dobey> infinity: you going to be able to travel?
<infinity> dobey: Yeah, I'll scoop myself on to the plane and medicate with vodka.
<dobey> heh
<Logan_> ari-tczew: if you want to keep your MOTU rights, I'd suggest that you become more cooperative and less nasty
<infinity> Logan_: You might also want to avoid making threats. ;)
<dobey> infinity: were you going to push the kernel from quantal-proposed out to -updates, btw?
<infinity> (WHY CAN'T WE ALL JUST GET ALONG?)
<infinity> dobey: Yeah, when that whole batch goes out.  Looks like it'll be Monday.
<Logan_> infinity: fair enough
<dobey> infinity: ah ok
<dobey> infinity: hope you feel better tomorrow, and i'll see you in amsterdam :)
<infinity> dobey: Do you have some particular interest in quantal, or just can't wait for LP to stop pretending it's a valid release?
<infinity> dobey: AMS?  Oh, are we on the same flight to Malta?
<dobey> infinity: someone came into #launchpad complaining about quantal being still "supported"
<dobey> infinity: yeah, seems about 6 of us are on the same flight from AMS->MLA
<infinity> dobey: Yeah, it's amazing how a simple string can annoy people so much.  I'd suggest sending them some white-out.
<dobey> infinity: i then discovered i have enough powers to twiddle that bit to make it "obsolete" but then colin mentioned you were going to push a kernel for it
<infinity> dobey: 6 of us?  Impressive.  I guess we'll split 2 cabs, or find a van.  And roshambo for the honor of paying/expensing.
<dobey> heh
<Logan_> Malta? what for?
<infinity> dobey: SRSLY?  You have that power?
<dobey> infinity: i guess all of ~registry does
<infinity> How wonderfully broken.
<infinity> Logan_: Canonical sprinty stuff.  Nowhere near as exciting and vacationy as it sounds.
<dobey> well, i should go back to getting ready for malta
<infinity> Logan_: I might gaze longingly at a beach from a hotel window for a few minutes.
<ScottK> Find a manager and make them expense the cab.
<ari-tczew> Logan_: yes, I considered. I thought just that it's OK if now connman got splitted off package connman-vpn.
<Logan_> ari-tczew: what about the /usr/lib stuff?
<Logan_> oh, I see, that's also in the VPN file
<Logan_> my apologies for assuming that something went wrong :P
<ari-tczew> Logan_: no problem. We all make mistakes.
<mlankhorst> so i dreamed that my sru was rejected because my house leaked when i was taking a shower, the fact it was already leaking didn't convince the sru admins :/ so i had to do a new upload to fix that or something, but I woke up
 * ScottK takes notes.
<Shock> good morning
<mqvist> Hi! I hope someone will be help me answer this question! I am writing a small utility that needs to control some parameters for a wireless network card. These parameters can be changed using "iw" and "iwconfig", but I thought I would rather do it directly through libiw. Unfortunately I can't find any documentation for the API. What is the best practice in this case? Is it "ok" to call iw as shell commands, or would that make my utility less
<mqvist>  portable to other platforms? (I need to run it on several different platforms)
<mqvist> I am writing this in c, btw
<sladen> mqvist: fetch the source for 'iw' and 'iwconfig', and see what they do
<sladen> mqvist: then you can do that directly
<xnox> mlankhorst: we may need to see you every week from now on....
<mlankhorst> lol
<Shock> sarnold: hi. now that I generated the debdiff, what do I do with it?
<xnox> Shock: attach it to the bug report & subscribe ubuntu-sponsors to the bug report.
<xnox> Shock: that will trigger it to appear in the sponsorship queue, for review & upload.
<Shock> xnox: thanks
#ubuntu-devel 2014-05-25
<lasindi> Anybody in here familiar with Unity's code? I am looking for the code determining how many pips to display next to a launcher icon. There's a bug where the number of pips isn't properly updated when a new window is opened, and I just wanted to see if it's an easy fix somewhere.
<mapreri> Trevinho: â(maybe)
<n4uah> Hii
<jj995> I just upgraded my ppa package version and it shows on launchpad, yet when I run "sudo apt-get update && sudo apt-get install my-package" it shows "my-package is already the newest version" -- is there a time delay in upgrades working?
#ubuntu-devel 2015-05-18
<TheMuso> c
<Unit193> d
<TheMuso> :)
<TheMuso> B/c
<TheMuso> gah there I go again. :
<pitti> Good morning
<Unit193> didrocks: There you are!  Did you by chance ever poke Debian with http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/xorg/wily/revision/189?
<didrocks> Unit193: IIRC, I did this when we introduced this all session stuff, but there was no traction on the debian side (it was covering too many components to have an widespread agreement)
<Unit193> Dang, that really stinks.  Thanks for trying though.  (Was recently looking at why it all wasn't working, had to ship that file another way.)
<didrocks> Unit193: I think they will see the value in that one day, maybe now would be better as we have multiple environments based on the same component (compared to the fact that it was only Unity at the timeâ¦)
<Unit193> It's also nicer in that you can easily ship different default config without clobbering or diverting.
<didrocks> indeed
<dholbach> good morning
<pitti> cjwatson, wgrant, infinity: I noticed that despite LP doing ddebs now, the buildds still create ddebs.txt indexes with the ddebs, and we additionally pull them in the old way
<wgrant> pitti: Yeah, I thought I'd disabled that, but apparently misremembered 2009 a little.
<pitti> do we still have any release where ddebs are *not* built using LP? in other words, can we retire the apaches and parsing ddebs.txt now, or do we still need that for anything?
<wgrant> pitti: It'll all go away soon when we upgrade sbuild.
<wgrant> (new sbuild will roll out to scalingstack this week, then we'll do a main test rebuild before rolling it out to non-virts)
<pitti> it just seems brittle to download them twice
<wgrant> Right, I'd disable the apache download path now and see if anyone whinges.
<pitti> ok
<pitti> cjwatson: why does ddeb_retriever.py call lpinfo.get_binary_publications() without the real_threshold arg?
<pitti> cjwatson: testing leftover?
<pitti> cjwatson: or on purpose? There's a loop afterwards to filter the recent ddebs manually
<pitti> wgrant: LP ddebs are on for RTM too?
<wgrant> pitti: Yep (I originally missed their primary archive, but Colin turned it on a week or two ago)
<rbasak> backportpackage currently doesn't call update-maintainer. Should it? https://wiki.ubuntu.com/DebianMaintainerField suggests to me that it should.
<rbasak> (for when preparing an Ubuntu upload)
<pitti> utlemming: can you please set up the /current symlink on http://cloud-images.ubuntu.com/wily/ ?
<infinity> rbasak: Not if it's a no-change backport, IMO.
<infinity> rbasak: Although, apparently my opinion doesn't mesh with the vote from 2006. :P
<infinity> rbasak: Anyhow, it's a spirit of law and letter of law thing.  We tend to never change Maintainer (in the source) on a rebuild, since the source didn't change except adding a changelog entry.  We always change maintainer on binaries, but that's not something that requires action from you.
<infinity> rbasak: So, in my mind, we're doing the right thing on a no-change backport by not changing the maintainer in the source too, but one could argue either way, based on the poor wording of the ballot options 9 years ago. :P
<rbasak> infinity: well I can't be bothered to patch backportpackage, so I'll do it your way :)
<smb> infinity, Today my Trusty install offered to try removing grub-efi-amd64-signed for some reason. Is that again a mess up on my part somehow?
<infinity> smb: Are you running with -proposed on?
<smb> Yes, do get things early on
<infinity> smb: Right, that's why probably, cause signed hadn't been uploaded to match.
<smb> infinity, Ok, thanks. Was suspecting that. So I just delay the update until later
<infinity> smb: Lemme fix that right now, since I can't sleep.
<smb> infinity, Thanks... though maybe you better tried counting penguins... or so...
<infinity> cyphermox: Fixed for you this time, but do remember to update grub2-signed after a grub2 upload.
<infinity> smb: Should be happy in 30m or so.
<smb> infinity, \o/ Thanks again
<cjwatson> pitti: The created_since_date argument to lpinfo.get_binary_publications is a leftover from an earlier query strategy and is currently unused.  I suppose we could go back to passing it, but I haven't tested the query with that included and it's easy enough to test later.  It means we fetch a few more publications than we need, but only up to the end of the current batch.
<cjwatson> pitti: It would probably be OK to add it, but test that the query still performs reasonably.
<pitti> cjwatson: ah, this looks like it would currently iterate over all builds, ever
<cjwatson> pitti: No
<pitti> and thus get slower over time?
<cjwatson> pitti: It's batched
<pitti> cjwatson: ah, then nevermind
<cjwatson> pitti: You get the first 75 until you ask for the next 75, etc.
<cjwatson> I *have* performance-tested the current set of queries :-)
<cjwatson> It might be a slight optimisation to let it cut the batch off a bit earlier, but I should confirm.
<pitti> cjwatson: ah, I'm not worried about that at all; I just wondered if this wouldn't traverse years of builds each time
<pitti> thanks for clarifying! I didn't take the dynamic nature of these lists into account
<infinity> smb: All built and published.  Once your mirror finishes its next update pulse, life should be back to normal.
<smb> :) Ok, well should be the main archive mirrored locally by apt-cacher-ng. But I probably give it a few minutes regardless
<cjwatson> pitti: OK, I've confirmed that the query has exactly the same plan either way (which makes sense, datecreated is in the index it's already using for ordering, but I wanted to make sure), so pushed a change to pass created_since_date.
<pitti> cjwatson: thanks! looks less confusing that way indeed
<cjwatson> pitti: (and deployed on germanium)
<pitti> cjwatson: FTR, I'm doing a run with rebuilding the db, at least some utopic ddebs got a wrong checksum
<pitti> in case you wonder why it's taking so long
<pitti> db5.1_dump seems fairly useless for actually changing values in the db
<pitti> and occasionally we should clean it up anyway, especially after dropping a release (lucid)
<infinity> pitti: Cleanups should happen properly if you do the same thing we do in LP.  But if you had a format break or whatever, a rebuild is necessary, yes.
<smb> infinity, ok, we have normality :)
<infinity> smb: \o/
<pitti> infinity: Colin and I actually tried that, and it stumbled over some DB corruption
<pitti> infinity: so, another reason for rebuilding it :)
<infinity> pitti: I would assume that means the DB was already broken.
<pitti> infinity: but in principle we have a config now for cleaning it up
<infinity> pitti: I meant, in the future, once they're known-good, doing the LP cleanup thing should be enough.
<pitti> infinity: exactly
<cjwatson> pitti: OK
<cjwatson> pitti,infinity: Well, although I fixed the DB format-level corruption, a cleanup also didn't actually reduce the size of the ddebs DBs much.
<cjwatson> So I decided not to spend much effort on that.
<pitti> cjwatson: I'm hoping that it does shrink now that lucid got removed
<infinity> cjwatson: A badly-corrupted bdb file can end up with a lot of dead space that can't be recovered.  It's possible it was just too far gone.
<infinity> With fresh caches, the a-f cleanup should DTRT.
<infinity> It certainly has been working on ftpmaster for years now.
<rbasak> infinity: so, these Docker backports. A couple of packages have had their source packages renamed (s/-dev$//) since Trusty. Previously I think jamespage renamed them back when backporting to Trusty. Is this necessary? I have 25 backports to track now, so it'd be a bit easier if I didn't have to manually rename anything.
<cjwatson> infinity: Could be, yes.
<rbasak> The binary package name (there's only one in each case) hasn't changed.
<infinity> rbasak: If it's something you're going to have to do again, scripting it would help.
<infinity> rbasak: But, generally, I'd say keeping with the same names as trusty for things that already exist is correct, and using new names for new packages is fine.
<rbasak> infinity: I'm already scripting 25 calls to backportpackage. I want to save myself the trouble of scripting the rename unless I have to do it.
<rbasak> infinity: OK. I'll do the renames.
<cjwatson> Unit193,infinity: So, as of germinate 2.20 (uploaded to unstable), germinate has git support.  Would it be worth my while preparing a history conversion of all the relevant things?
<cjwatson> The way I've structured it means that each flavour will get a separate repository (which makes sense for separate ownership/ACLs etc.) but each series will just be a branch within that repository.
<infinity> cjwatson: Wouldn't hurt my feelings if you did.  And that layout sounds correct to me.
<zyga> ogra_: hey, do you know (by any chance) why nexux 7 shuts down if left unused for a while (with full battery)
<ogra_> zyga, nope, havent touched any tablet in a yeah
<ogra_> *year
<zyga> ogra_: thanks
<ogra_> probably popey knows more, i know he still has a flo in use sometimes
<zyga> popey: ^^ any idea?
<popey> hmm?
<zyga> popey: (use case: charged flo, idle, leave on desk for a day, it will shut down, you can turn it back on again, has lots of power left)
<popey> not seen that, but my flo has been in a bag, switched off, for a few weeks
<zyga> my suspicion is some kernel crash that just turns the device off
<zyga> that doesn't happen if the device is plugged in to a computer
<infinity> zyga: If it doesn't happen when it's plugged in, it sounds more likely that it's going a bit nutty and thinking the battery is either not present or flat, just long enough to make it shut down.
<infinity> zyga: Which wouldn't happen when it's plugged in, since, well, no need for a bettery when on external power.
<infinity> Nor a battery...
<zyga> infinity: ah, perhaps I could log upower activity then
<ogra_> zyga, if it is plugged in it will always hold a wakelock
<ogra_> (read: it never really goes to sleep)
<ogra_> zyga, after it crashed immediately boot into recovery and check /proc/last_kmsg ... that holds dmesg of the last boot and probably reveals something
<zyga> ogra_: ah, thanks for the tip!
<mitya57> pitti: hi, can you please retry wily-adt-php-react-promise on amd64?
<pitti> mitya57: done
<mitya57> thanks!
<pitti> mitya57: FYI, it just exploded some more, CI is on it
<mitya57> Yes, I see that something got wrong
<pitti> mitya57: all good now
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<seb128> Riddell, hey, could you look at https://launchpad.net/bugs/1455990 ? seems like the Debian package doesn't specify the rsa key length, not sure why the Ubuntu one does (it's not mentioned in the changelog it seems)
<ubottu> Ubuntu bug 1455990 in quassel (Ubuntu) "quassel-core generates an insecure certificate upon installation" [Undecided,New]
<seb128> grrr launchpad keep timeouting, can't comment on that bug
<mitya57> pitti: Great, thanks again! A big list of packages including my sphinx-rtd-theme now migrated :)
<pitti> infinity: do you mind if I steal your sysvinit merge? this needs to happen in lockstep with merging util-linux, as some of the tools moved
<seb128> smoser, hey, are you still looking at https://code.launchpad.net/~niedbalski/ubuntu/vivid/curtin/fix-1263181/+merge/250163? you wrote that you would take another look but seems you didn't?
<seb128> kirkland, hey, do you think you could review https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940 ?
<ubottu> Ubuntu bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New]
<seb128> dholbach, do you feel strongly about the old changelog entries on https://bugs.launchpad.net/ubuntu/+source/openstack-pkg-tools/+bug/1455985 ?
<ubottu> Ubuntu bug 1455985 in openstack-pkg-tools (Ubuntu) "Merge openstack-pkg-tools 24 (main) from Debian unstable (main)" [Wishlist,Confirmed]
<dholbach> seb128, no, not very - I just thought they might be good to have
<seb128> dholbach, well, I usually just drop them as well on desktop merges, but I know some people seem to care that's why I'm asking
<seb128> I'm just going to upload if you don't say me to not :-)
<dholbach> seb128, I know you do - I remember ;-)
<dholbach> feel free to upload
<seb128> dholbach, in practice we could have synced the package and then needed a change again
<seb128> and we wouldn't have reapplied the old changelog entries doing that
<seb128> dholbach, k, doing that then
<seb128> slangasek, hey, could you review https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1314095 or recommend somebody know about pam who could? (that's a SRU request waiting in the sponsoring queue since february)
<ubottu> Ubuntu bug 1314095 in nss-pam-ldapd (Ubuntu) "Unity Lockscreen in 14.04 can't unlock when using LDAP account" [Undecided,Confirmed]
<seb128> cyphermox, hey, https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141 ... did you plan to upload the SRUs as well?
<ubottu> Ubuntu bug 1401141 in isc-dhcp (Ubuntu Vivid) "DHCP server does not work for IPoIB (Infiniband)" [Undecided,Confirmed]
<seb128> hallyn_, hey, about https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/1445036 ... do you plan to review the debdiff more/handle the update/sponsoring?
<ubottu> Ubuntu bug 1445036 in libcgroup (Ubuntu) "Please merge libcgroup 0.41-6 (universe) from Debian testing (main)" [Undecided,Confirmed]
<seb128> jdstrand, hey, could somebody from the security team review https://code.launchpad.net/~tiagosh/ubuntu/wily/telepathy-mission-control-5/allow-getprop-execution/+merge/259174 ?
<infinity> pitti: Go nuts.
<tseliot> pitti or anybody else who uses sbuild. Are you experiencing any problems when trying to create an sbuild chroot for wily? I am, so ideas are welcome, please: http://pastebin.ubuntu.com/11207968/
<tseliot> I'm using mk-sbuild
<tseliot> infinity: ^
<infinity> tseliot: That looks like you asked it to build a cross-compile chroot.
<infinity> tseliot: And it's not wrong, there aren't any amd64 cross-compilers.
<tseliot> infinity: oh, so it must be the --target parameter that's causing this
<tseliot> i.e. me using that parameter
<infinity> tseliot: Yeah, --target is for cross.  Don't use it for native chroots.
<tseliot> infinity: ok, it makes sense, thanks
<dobey> ick. libOpenCL.so is gone from ocl-icd-libopencl1 in vivid/wily, but it seems like ocl-icd-dev doesn't provide a symlink for it either. :-/
<infinity> One could argue that it should ignore target if target==arch, but it's easy enough to just not specify it.
<tseliot> right
<jdstrand> seb128: done
<seb128> jdstrand, thanks
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hallyn_> seb128: urgh, i' dlike to, but i don't know when i can get to it
<hallyn_> i've put it on my list, but if someone has time to get to it before that that'd probably be good
#ubuntu-devel 2015-05-19
<pitti> Good morning
<Unit193> Bye.
<highvoltage> hmm, odd how thunderbird in 14.04 says 'Welcome to daily!', would probably be nicer with the usual welcome to thunderbird message in an lts release.
<infinity> chrisccoulson: ^
<micahg> highvoltage: it's actually an upstream issue
<highvoltage> micahg: I believe it should be patched in Ubuntu since it will confuse users and may cause some alarm
<micahg> highvoltage: that would take much longer, I'll see if I can poke upstream
<micahg> it's not a code issue
<highvoltage> micahg: cool :)
<micahg> I poked, but not sure anyone is awake that this hour that can fix it
<micahg> mozilla 1166040
<ubottu> Mozilla bug 1166040 in General "31.7.0 start page not going to production start page. It goes to Daily page" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=1166040
<dholbach> good morning
<micahg> highvoltage: someone will be looking at it shortly, I'm sure Chris can follow up when he comes online
<seb128> hey dholbach
<highvoltage> micahg: great
<zyga> pitti: good morning
<zyga> pitti: I was using adt-run to test qtbase-opensource-src-5.4.1+dfsg yesterday
<zyga> pitti: and the only test that failed was
<zyga> FAIL!  : tst_qstandardpaths::testRuntimeDirectory() '!runtimeDir.isEmpty()' returned FALSE. () Loc: [tst_qstandardpaths.cpp(411)]
<zyga> pitti: does adt-run provide XDG_RUNTIME_DIR?
<pitti> zyga: no, as there is no login involved, thus no pam and logind
<pitti> so your test should probably set up a temp dir and set XDG_RUNTIME_DIR to it
<pitti> s/probably//
<zyga> pitti: well, it's just stock debian qt, I'm interested in patching it so I wanted to run tests on vainlla first
<zyga> I wonder if it passes in debian
<pitti> http://ci.debian.net/?q=qtbase-opensource-src
<pitti> no result -- does it even have tests in Debian?
<zyga> pitti: thanks!
<zyga> pitti: ha, good question, let's see
<zyga> pitti: ah, wait, those are not adt tests!
<zyga> pitti: (the build ran overnight so I didn't check the full log)
<zyga> pitti: just regular make check style tests
<pitti> ah, it as needs-build and these are build time tests?
<pitti> ack
<pitti> same thing in buildds, no login/pam
<zyga> hmmm
 * zyga wonders how it gets built then :)
<zyga> I built it in a vanilla sbuild for wily
<zyga> Mirv: hey, I started looking at the story we talked about during ODS
<zyga> Mirv: on building qt with prefix for /opt/something
<zyga> Mirv: would you be so kind to rebuild qtbase-opensource-src without any patches and tell me if it fails on build-time tests (see above for FAIL that I see)
<Mirv> zyga: you mean unit tests? yes it does fail, there was a huge work done originally to find out which tests pass on our builders. Debian doesn't have tests enabled in qtbase.
<Mirv> zyga: see the enable_tests.patch in packaging.
<zyga> Mirv: ah, that makes sense
<zyga> Mirv: so what happens, how do we build it?
<zyga> Mirv: if it fails here for me
<Mirv> zyga: so it's built by selectively disabling the failing tests
<zyga> Mirv: I still don't get it -- I buit the package straight from our archive
<zyga> Mirv: so why do I hit the failing test
<zyga> Mirv: is there something I'm missing?
<Mirv> zyga: oh, you built yourself, locally? well, on a desktop Ubuntu a different set of tests fail than on builders.. because of environment differences and assumptions Qt makes
<Mirv> zyga: the runtimedirectory sounds exactly like that
<Mirv> zyga: the easy way out is an empty override_dh_auto_test:[C
<Mirv> -[C
<zyga> Mirv: I buit it in sbuild
<zyga> Mirv: hmm
<zyga> Mirv: yeah, I can disable tests, no problem
<zyga> Mirv: I just wonder what else I might be missing from my environment
<zyga> dholbach: thanks for sending that email
<dholbach> anytime
<seb128> mardy, hey
<seb128> mardy, on my wily desktop I see saw warning, is that a known issue?
<seb128> "signond[12379]: ../../../../src/signond/signondaemon.cpp 390 init Failed to SUID root. Secure storage will not be available."
<mardy> seb128: oh, we should definitely remove that line... it's a leftover from MeeGo times (we don't run as root in Ubuntu)
<seb128> mardy, k, I was trying to look at https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1453549 ... I guess something changed on the facebook side
<ubottu> Ubuntu bug 1453549 in shotwell (Ubuntu) "Cannot publish to Facebook" [High,Incomplete]
<mardy> seb128: I'll have a look at it
<seb128> mardy, thanks
<LocutusOfBorg1> ginggs, hi, you there?
<LocutusOfBorg1> I opened a bug with debdiffs for vbox
<rbasak> cyphermox: FYI, I'm lining up another grub2 SRU for Trusty: bug 1443735. I'll wait for your upload of 2.02~beta2-9ubuntu1.2 to clear first.
<ubottu> bug 1443735 in grub2 (Ubuntu) "recordfail false positive causes headless servers to hang on boot by default" [High,Triaged] https://launchpad.net/bugs/1443735
<cyphermox> rbasak: ack
<cjwatson> apw: I filed bug 1456625 for the ability to set HEAD, which you requested a while ago; feel free to subscribe of course
<ubottu> bug 1456625 in turnip "Can't set default branch ("HEAD") on a Git repository" [High,In progress] https://launchpad.net/bugs/1456625
<apw> cjwatson, nice thanks, subbing
<barry> pitti: ping, re adt-build-lxc
<pitti> hey barry
<barry> pitti: hi.  i'm working on si adt failures.  two of my tests are isolation-container and i'm trying to build an lxc container for those tests on vivid.  should i be able to build a wily amd64 container on vivid?  it keeps failing for me
<pitti> barry: I haven't tested it in this direction (I'm running wily and have trusty/vivid/wily containers), but there's no significant difference between v and w really
<pitti> barry: what precisely fails for you?
<barry> pitti: http://paste.debian.net/180374/
<barry> pitti: yeah, i'm running wily on all but this one particular machine.  haven't upgraded it yet
<pitti> /var/cache/lxc/wily/partial-amd64/debootstrap/debootstrap.log ?
<pitti> barry: hm, I just landed a new util-linux, perhaps that broke stuff
<pitti> the main change was that some binaries moved from sysvinit-utils to util-linux
<pitti> barry: trying here..
<barry> pitti: cool
<barry> thx
<pitti> barry: I mean, what does /var/cache/lxc/wily/partial-amd64/debootstrap/debootstrap.log say?
<barry> pitti: yeah, that's the weird thing!  there's nothing in /var/cache/lxc/wily
<pitti> ah, so perhaps lxc-create cleaned that up
<barry> pitti: it'll be interesting to see if you can reproduce it.  i'm going afk to try this on my wily box
<pitti> barry: it's running (but it takes a while)
<pitti> barry: it'd really surprise me if that would depend on the host's release
<pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt doesn't look related (although I'll clean this up now)
<pitti> $ sudo http_proxy=http://localhost:3142 debootstrap wily /tmp/wily
<pitti> barry: ^ that reproduces it for me
<pitti> and is muuuuch faster than lxc-create (due to tmpfs)
<rbasak> pitti: is systemd-timesyncd supposed to be active by default now?
<pitti> (the http_proxy is just to use apt-cacher-ng)
<pitti> rbasak: yes, since vivid; unless you have ntpd, chrony, or another "big" ntp server installed
<rbasak> pitti: what's the logic it uses to decide whether to be active or not (eg. if ntp server is installed)?
<rbasak> pitti: I have an item to make NTP syncing default on server. I was planning to seed ntpd. Not sure whether that is necessary now.
<pitti> rbasak: see /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
<pitti> ConditionFileIsExecutable=!/usr/sbin/ntpd
<pitti> ConditionFileIsExecutable=!/usr/sbin/openntpd
<pitti> ConditionFileIsExecutable=!/usr/sbin/chronyd
<rbasak> pitti: and should we change the default to s/debian.pool.ntp.org/ubuntu.pool.ntp.org/?
<rbasak> pitti: I see - thanks.
<pitti> rbasak: ^ basically that; that's rather simplistic of course, it'd be better to use Conflicts=; but that's only possible once these three get systemd units
<rbasak> pitti: any opinion on ntpd by default? I guess systemd-timesyncd will suffice for the default server case then?
<pitti> rbasak: timesyncd is simple and efficient for desktops; my gut feeling is that it should be just right for most cases where you don't care about manually configuring stuff
<barry> pitti: by "reproduce" it means you're seeing the problem too?
<pitti> rbasak: and once you do, I feel that an admin would explicitly pick something to install anyway
<pitti> rbasak: but I don't have a strong opinion whether ntpd is a good default for a server, I'm not that familiar with it
<pitti> rbasak: as for changing the default NTP server -- I'm not sure, maybe
<pitti> barry: yes
<rbasak> pitti: that sounds about right to me. Thanks.
<barry> pitti: and the last dist-upgrade seems to have broken my wily machine's desktop.  i see the greeter and can log in but then never get to the desktop
<barry> which of course may just be unrelated
<rbasak> pitti: does timesyncd run all the time or is it one shot (i.e. is it ntp or ntpdate?)
<barry> pitti: i'm going to go try to fix that, but ping me if i can gather any more information from you, or if you want me to file a bug
<pitti> rbasak: hm, no idea about the broken dist-upgrade for you; I'll file a bug and investigate the broken debootstrap for now
<rbasak> s/rbasak/barry/ ^^
<pitti> rbasak: whoops, sorry :)
<barry> pitti: cool, thanks
<pitti> barry: filed bug 1456670
<ubottu> bug 1456670 in util-linux (Ubuntu) "debootstrap failure: insserv: Service mountdevsubfs has to be enabled to start service hwclock" [High,In progress] https://launchpad.net/bugs/1456670
<barry> pitti: thanks
<pitti> barry: I uploaded a new sysvinit which will hopefully fix this; I'm a bit stunnned about this, but there was only one change that really sticks out
<barry> pitti: interesting!  i'll try to keep watch and update/try again in a bit
 * barry now tries to verify that unity updates broke his wily desktop
<pitti> barry: now I'm scared to reboot :)
 * pitti does it anyway, the "unstable" experience!
<pitti> barry: hm, all hunky-dory here, same boring "never breaks" as always..
<barry> pitti: yeah, i'm having trouble narrowing it down.  *something* in the last dist-upgrade prevents my desktop coming up.  i thought i narrowed it down to unity but bisecting package installs (and installing just the unity related upgrades) doesn't seem to reproduce it.  fortunately this is a snapshotted disk so it's easy-ish (if tedious) to try each package by hand
<cjwatson> pitti: latest util-linux has broken debootstrap, http://paste.ubuntu.com/11227070/
<pitti> cjwatson: tracked in bug 1456670
<ubottu> bug 1456670 in sysvinit (Ubuntu) "debootstrap failure: insserv: Service mountdevsubfs has to be enabled to start service hwclock" [High,In progress] https://launchpad.net/bugs/1456670
<pitti> cjwatson: I uploaded https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-59.1ubuntu2 for now, which is the only change that looked substantial to debootstrap
<pitti> I'm not 100% sure that this will be the fix, but this is so utterly hard to test with local packages..
<cjwatson> pitti: oh, failure to read up on my part, sorry
<cjwatson> rcj: ^-
<rcj> cjwatson, thanks
<shadeslayer> rbasak: any news on the docker backport
<rbasak> shadeslayer: currently blocked on merging the apparmor delta.
<shadeslayer> oh ok
<shadeslayer> thanks
<rbasak> shadeslayer: I've stuck all the dependencies in a PPA now, so you might be able to build the Debian source package for 1.6.1 unmodified against it now.
<shadeslayer> rbasak: well, I wanted to use it locally on my machine :)
<shadeslayer> on vivid
<rbasak> shadeslayer: try sbuild with --extra-repository of my (racb) docker PPA on amd64 against Debian's 1.6.1. I think that may work.
<rbasak> You'll be using upstream's apparmor profile then, instead of the standard Ubuntu one. That's something I don't want to regress, hence I'm blocked - but I think it'll work. You'll just end up with upstream's preference instead of Ubuntu/AppArmor upstream's preference.
<shadeslayer> rbasak: roger :)
<hallyn_> jodh: infinity: xnox: so does anyone remember of a good reason why libnih is built without --enable-threading?
<hallyn_> it actually *only* makes __thread be #dfined to nothing when not set, so i can't see any possible safety advantage
<xnox> hallyn_: because i believe upstart detects that and uses threads.
<xnox> hallyn_: in practice i don't want any threads in upstart code when it is pid1
<xnox> hallyn_: now that it's no longer pid1 in ubuntu, i'm happy to change libnih to be better suited for normal userspace programs and not as critical as pid1.
<hallyn_> xnox: i dont' think libnih creates any threads with --enable-thrading.  it only marks some variables as __thread
<hallyn_> but in any case - cool, it woudl def be nice to have in wily
<hallyn_> also stgraber suggested adding a 'is-threading-enabled' check in libnih, so i may post a ptach for that
<hallyn_> (though it's easy to check by hand anyway, but a helper would be appropriate)
<hallyn_> (better yet would be enabling it on all releases :)
<hallyn_> xnox: where should upstream libnih patches go these days?
<xnox> hallyn_: so github.com/libnih/libnih is ubuntu-compatible thing with (hopefully) all ubuntu patches in place.
<xnox> hallyn_: i can add you to that, or i'm happy to transfer it to linuxcontainer umbrella.
<xnox> hallyn_: there is also keybuk/libnih which i tried to push things to from libnih/libnih but it has different license - gplv2 only.
<hallyn_> xnox: cool i just want to post a patch to add a 'bool nih_threaded()' helper.  i'll post it for github.com/libnih/libnih and then we can cherrypick itno wily if not rejected outright
<hallyn_> thanks
<xnox> ok.
<hallyn_> xnox: wait.  https://github.com/libnih/libnih no worky
<xnox> hallyn_: horum, looks like i only have docs there.
<xnox> there is https://github.com/keybuk/libnih
<xnox> oh
<xnox> https://github.com/xnox/libnih
<xnox> and well lp:ubuntu/libnih
<xnox> hallyn_: keybuk doesn't take fixes, and e.g. cgmanager will not work with keybuk's libnih
<hallyn_> heh.  can i bless https://github.com/xnox/libnih as 'upstream' ?
<xnox> hallyn_: submit there yes.
<hallyn_> alright will do.  thx, ttyl
<xnox> hallyn_: and as "upstream" i'll talk to "linuxcontainers" project to possibly include libnih/libnih org into their structure.
 * xnox runs away for a bit
<hallyn_> xnox: hah, sounds good.
<xnox> hallyn_: btw, maybe it makes sense in ubuntu to compile two variants, -mt and normal.
<hallyn_> xnox: i'm still not actually seeing where there can be any advantage to !--enable-threading.  The only thing it will do is break things at nih_err checking if the caller happens to use threads.
<hallyn_> but i'll start with the detection fn and go from there
<xnox> hallyn_: ok, cool.
<hzut> Hi - Please, let me know a good successor for emule?
<pitti> barry, cjwatson: hm, that didn't help, debootstrap is still failing; need to investigate more closely tomorrow
<barry> pitti: gotcha, thanks.  i finally narrowed down my wily problem to unity
<hzut> Hi - Please, let me know a good successor for emule?
<Unit193> I think you've mistaken this for a support channel, hzut?  I don't know what protocol they used, but there's gtk-gnutella.
<ahasenack> hi guys, I have an apt-get crash/coredump file, easily reproduced
<ahasenack> what package do I need to install so the core file has symbols?
<ahasenack> it was recorded in /var/crash
 * ahasenack installs apport-retrace
<ahasenack> pitti: around?
<soren> Is there some way in which I can disable authentication for just a single repository?
<soren> I have a tarball of packages + a Packages file. I trust it implicitly. I'd like to extract it locally, add that dir to my source.list and just trust it, but APT will complain it's not signed.
<tarpman> soren: deb [trusted=yes] file:/... ought to do it
<soren> Sweet!
<soren> Let me try it!
<tarpman> soren: personally I have http://paste.debian.net/180638/ saved as ~/bin/mkrepo ... pretty quick
<soren> I *could* do that, but I'd be distributing the key over the same channel, so it's not really any safer than just saying that I implicitly trust the repo.
<tarpman> :)
<soren> Besides, it's only for testing. Once things are validated, they'll be built and signed properly.
<soren> Doh, I can't test the trusted=yes thing, but looking at the docs, it certainly should work.
<soren> tarpman: Thanks!
<tarpman> np
#ubuntu-devel 2015-05-20
<pitti> Good morning
<pitti> ahasenack: hello; I'm around now
<infinity> rsalveti: That sure is a lot of undeclared build-deps.
<hallyn_> xnox: so one oddity i've found with threaded libnih: when any thread calls nih_error_init(), it onexit()s a fn that asserts context_stack != NULL - but context_stack is __thread
<hallyn_> while onexit is process-wide
<hallyn_> so if you fork, you get a NULl context_stack but still have the onexit'd fn;  so then you have to _exit() instead of exit()
<hallyn_> else, ugly assert error msgs
<hallyn_> I suppose it might also be an issue when the original process exits if the last exiting thread had context_stck == NULL...
<dholbach> good morning
<highvoltage> micahg: your upstream guys came through, thunderbird looks good again in trusty this morning
<seb128> hey dholbach!
<dholbach> salut seb128
<zyga> mvo: hey
<zyga> mvo: did you have a chance to look at tarmac lately?
<mvo> zyga: hey, I haven't, was on vacation and have not looked into this at all yet
<zyga> mvo: ok, thanks
 * Laney backports high fives micahg 
<Laney> dug out the ol' GPG key again ;-)
<rbasak> pitti: I just spotted bug 1447654 which reminds me of bug 1450053. A user reports that mysql doesn't start on boot unless he installs policykit-1. I wonder if this is a systemd related bug?
<ubottu> bug 1447654 in policykit-1 (Ubuntu) "installing policykit-1 hangs under systemd" [Medium,Confirmed] https://launchpad.net/bugs/1447654
<ubottu> bug 1450053 in mysql-5.6 (Ubuntu) "upgrade 14.04 to 15.04, mysql no longer starts on boot due to missing policykit-1" [High,New] https://launchpad.net/bugs/1450053
<pitti> rbasak: does mysql-5.6 actually have a .service, not just an init.d script?
<rbasak> pitti: yes it does have a .service
<pitti> we used to have some (cosmetical) bugs where systemctl enable foo.service failed with such an "no such file" error message if there was no actual .service
<rbasak> Yeah I've seen that bug.
<rbasak> I don't know if this is a separate issue or the fix or that would have fixed this.
<pitti> rbasak: so, I need to look into this more closely, I don't have an off-hand idea
<rbasak> Seems odd that installing policykit-1 fixed the issue.
<rbasak> pitti: OK, thanks. Shall I tag it for you?
<pitti> rbasak: might be a red herring -- a followup says that installing polkit didn't help
<rbasak> pitti: that was a different person.
<rbasak> "This issue affects me too, except that all the circumstances are different and it failed in a different way" -- well, that's a different bug then.
<pitti> yes, I know, but it still sounds like a red herring to me
<pitti> anyway, I'll try to reprodue
<rbasak> Thanks
<rbasak> I agree it's unclear. I'm getting bug reports about genuine issues in packaging in mysql 5.6 (new stuff), systemd-related issues, and users with screwed up databases getting failures. And they're all muddled up :(
<ricotz> diwic, hi :), any plans to fix those failures? https://launchpad.net/ubuntu/+source/pulseaudio/1:6.0-0ubuntu7
<diwic> ricotz, let me forward that to hwang4
<diwic> ricotz, I hope he'll fix today or tomorrow. Feel free to revert if it's urgent
<diwic> sorry
<ricotz> diwic, no, just curious since it sits there for a week already ;)
<diwic> ricotz, yeah, I missed that email in my inbox
<flexiondotorg> dholbach, Thanks for sponsoring :-)
<dholbach> no worries
<alkisg> xnox, would you mind if I chatted 5 minutes with you about another upstart bug related to LP #1343905?  I.e. I think that /etc/X11/Xsession.d/00upstart should go after 50x11-common_determine-startup in order to be able to locate the session from $STARTUP too, not only from $1
<ubottu> Launchpad bug 1343905 in upstart (Ubuntu Trusty) "Empty desktop in Xubuntu 14.04 on reboot after upgrading upstart package" [High,Fix released] https://launchpad.net/bugs/1343905
<alkisg> That part affects us on LTSP fat client desktops, they stopped being able to launch Unity in 14.04 because of that 00upstart script, and I'm trying to see if it'll be best to fix this in upstart or in ltsp
<alkisg> So basically what I'm proposing is, 00upstart to be renamed to 50x12-upstart, and        BASESESSION=${1% *} to become BASESESSION=${STARTUP% *}
<xnox> alkisg: that should not be necessory.
<xnox> alkisg: note that 00upstart really just saves variables for 99upstart to do stuff.
<alkisg> xnox: it's possible for xsession to be called without parameters
<alkisg> That then falls back to "defaults"
<alkisg> The defaults are processed in 50x11-common_determine-startup
<alkisg> From that script, $STARTUP is determined
<alkisg> *then* 00upstart should decide the SESSIONTYPE based on that
<xnox> I'd ask to poke stgraber - he did the user session upstart stuff and he knows LTSP.
<alkisg> Unfortunately he seems too busy to deal with ltsp the last 2 years
<xnox> doh, he is a busy man =)
<alkisg> We've  been trying to convince him to let us maintain ltsp in ubuntu instead, because it's been broken for too long
<xnox> alkisg: why are you calling it without any arguments thogh on ltsp? are you not using a login manager at all?
<alkisg> We're using LDM, the ltsp login manager
<xnox> right... and why doesn't that parse/set session to launch?
<alkisg> It's a valid scenario, see that script or the xsession manpage
<xnox> imho default should be XTerm =)
<alkisg> No, it's x-session-manager
<alkisg> There's an alternative for that
<alkisg> man Xsession mentions those
<alkisg> There's support in Xorg and in debian for that since decades, only 14.04 broke it
<alkisg> I can easily work around that in upstream ltsp, but it's wrong
<alkisg> It should be fixed in upstart instead
<alkisg> Even 00upstart reads x-session-manager
<alkisg> It just does so at the wrong point, 00 instead of 51
<alkisg> xnox: I've already tried the 2 changes that I"m proposing and they work fine: 0upstart to be renamed to 50x12-upstart, and        BASESESSION=${1% *} to become BASESESSION=${STARTUP% *}
<xnox> alkisg: the idea behind 00upstart is that we only kick in for blessed sessions
<xnox> alkisg: what is the value of $DESKTOP_SESSION and is it listed in /etc/upstart-xsessions for you?
<alkisg> xnox: right, all those in /etc/upstart-xsessions
<xnox> it is possible that it's out of date on 14.04
<alkisg> DESKTOP_SESSION is ubuntu
<xnox> (upstart-xsessions)
<xnox> ok.
<alkisg> xnox, I've already troubleshooted the issue
<alkisg> I do have the solution above ^...
<alkisg> My question essentially is, if you guys want to fix that in upstart, or should we workaround the upstart bug in the ltsp code instead...
<xnox> this is stuff is not upstart upstream, but in ubuntu packaging.
<alkisg> Ah, that's why you mentioned to file distro-specific bug reports in that other bug I mentioned
<alkisg> Ok, that's even easier then, isn't it?
<xnox> the problem is that we cannot use STARTUP, no
<alkisg> Why?
<xnox> your solution is not right.
<alkisg> Why?
<xnox> look at 99upstart
<xnox> we override STARTUP to become /sbin/upstart --user
<alkisg> Yes?
<alkisg> I know
<xnox> and everything should be launched from there.
<alkisg> Right
<xnox> as in by upstart
<alkisg> OK let me describe the problem better
<alkisg> You're using $1
<xnox> not by user scripts, defaults or the x-session-manager
<alkisg> Which is "gnome-session --session=ubuntu"
<alkisg> At 50x11, STARTUP also is "gnome-session --session=ubuntu"
<alkisg> So if 00upstart went to 50x12, it could use STARTUP instead of $1, both would have the same value
<xnox> 50x11 is a no-on
<alkisg> No change at all there
<alkisg> BUT
<xnox> it doesn't nothing when STARTUP is populated
<xnox> it does nothing that is.
<alkisg> It only determines what the user wants to launch
<xnox> 50x11 only processes when STARTUP is empty, and one cannot have an upstart session if it was empty...
<xnox> no, login manager should offer and consume user choices.
<alkisg> xnox, I already tried it and it works
<xnox> 50x11 doesn't process what user wants, it tries to do educated guess when not having any information what's so ever.
<alkisg> 50x11 processes the user and the system alternatives
<xnox> we cannot allow-user-xsession with upstart --user session, as we have no idea that it will work
<alkisg> Wait wait
<xnox> cause upstart --user will not process STARTUPFILE
<alkisg> In 00upstart you read x-session-manager, right?
<xnox> only conditionally
<xnox> but we do not read STARTUPFILE
<alkisg> OK, on what condition? if [ "$BASESESSION" = x-session-manager ]
<alkisg> Are you willing to do the same if "$1" is empty?
<xnox> yes.
<alkisg> If it's "default" ?
<xnox> no
<alkisg> man Xsession
<xnox> default should launch default.
<alkisg>        default
<alkisg>               produces the same behavior as if no session type argument had been given at all.
<xnox> but default is not in /etc/upstart-xsessions....
<alkisg> 50x11-common_determine-startup
<xnox> oh that's desktop_session, ignore that.
<alkisg> sorry ./20x11-common_process-args
 * xnox is confused how one would end up with DESKTOP_SESSION defined, yet without passing an argument.
<alkisg> One should be able to just launch Xsession and have it work, with the default gnome-session --session=ubuntu
<alkisg> That was only broken now, in 14.04
<alkisg> And it will hopefully stop being broken in 16.04 with systemd
<alkisg> So we're basically only talking about 14.04 now...
<xnox> yeah, i need to pull 14.04 with latest updates to check.
<xnox> in essence we try to make sure we never launch and override STARTUP by accident
<xnox> thus we operate in whitelist mode only.
<alkisg> If you prefer a patch inside 00upstart that essentially duplicates the work done by 50x11, ok, no problem
<alkisg> xnox, upstart never uses STARTUP anyway
<xnox> if DESTKOP_SESSION is correct and known to be upstart enabled
<xnox> we expect an agument for the session-manager as well
<alkisg> I'm just saying that if 50x11 does the work and sees that the user actually wants one of the upstart-supported sessions, then use the work of 50x11
<xnox> otherwise upstart session will be borked when launched in 99upstart
<alkisg> Don't just check $1
<xnox> we cannot modify 50x11 at all.
<alkisg> I'm not asking to
<xnox> (to be upstart aware)
<alkisg> I'm only asking the 2 changes I said, 00upstart to be renamed to 50x12-upstart, and        BASESESSION=${1% *} to become BASESESSION=${STARTUP% *} inside it
<xnox> no, we cannot do that.
<xnox> we will loose any variables set between 00-50
<alkisg> There are none
<xnox> which must be exported to upstart session.
<alkisg> 50 determines the session
<alkisg> You cannot set vars before the session is determined
<alkisg> And, you don't
<xnox> alkisg: sure there are! this is admin modifyable config scripts, and i'm sure admins have exported variables between 00-50 which they expect to be present for all sessions.
<alkisg> No script sets vars based on 00upstart, until after 50x
<xnox> 50x11 is not support in upstart user sessions
<alkisg> The admin is wrong then
<xnox> honestly show me your login manager, it looks broken.
<alkisg> Because 50x is where the session is determined
<xnox> because it suppose to parse
<xnox> valid sessions from
<xnox> one sec.
<xnox> 50x is not where the session is determined, let me check this
<alkisg> That's where the x-session-manager alternative is processed, where the user options are processed etc
<alkisg> That's the central point (hence the 50 number) where the session is determined
<xnox> so sessions in Ubuntu as a whole, that is all variants
<xnox> are define din /usr/share/xsessions/
<xnox> as *.desktop files
<alkisg> Yup
<xnox> all login managers must process that
<xnox> and launch as specified there.
<alkisg> Suppose you're not using a login manager
<xnox> and offer them to the user to choose from
<alkisg> You just want to run Xsession
<xnox> that's not supported
<xnox> you must use a login manager in ubuntu
<alkisg> It can be supported by that little change
<xnox> or exec in a compatible way
<xnox> no
<alkisg> And it was supported until 14.04
<xnox> there are admins that drop 10foo in to Xsession.d
<alkisg> (it was runniing, I mean)
<xnox> and we want to support it.
<xnox> i beleive 13.10 was were we stopped supporting that
<alkisg> You want to support broken configurations but not just running Xsession?
<xnox> when ehte upstart user ssions were started to be support.
<xnox> you can run Xsession
<xnox> but not managed by user upstart
<xnox> to have user upstart managed xsession it must be launched properly as per /usr/share/xsessions and ideally by a login manager
<xnox> if you don't want upstart, and plain xsession it will work.
<xnox> but e.g. unity DE is no longer support in such combination, as a few desktop things started to depend on user upstart session to be available.
<alkisg> Not all login managers do what you want
<xnox> do you see what i mean?
<alkisg> E.g. LDM doesn't do it
<alkisg> So we have to fix it because you want to support a possible broken configuration of some sysadmin?>
<xnox> if LDM doesn't parse /usr/share/xsessions and doesn't offer a user to launch xubuntu.desktop -> LDM is broken. Please open a bug against LDM package in Ubuntu.
<alkisg> It does parse them
<alkisg> And it launches them as mentioned in the Exec line
<xnox> alkisg: and does it do "Exec=" as specified in them?
<xnox> which should work then.
<xnox> for unity.
<alkisg> The problem is the "default"
<alkisg> What is the default session?
<xnox> i don't see a .desktop file with a default.
<alkisg> Xsession says "it's called default"
<xnox> in e.g. lightdm it has a setting what id default.
<alkisg> So for ages LDM and other DMs are using that
<xnox> if there is only one -> LDM should use that as default?
<xnox> honestly i hear the first time about default.desktop
<alkisg> If I find other DMs that use "default" or "empty", will it help in convincing you?
<alkisg> E.g. SDM, XDM, nodm, whatever?
<xnox> in Ubuntu we don't have default, as that's ambigious - on a Xubuntu build one only has /usr/share/xsessions/xubuntu.desktop
<alkisg> I never mentioned default.desktop
<xnox> we currently support a lot of xsessions.
<alkisg> I'm talking about the default session, as documented by Xsession
<xnox> please point me to ldm code which parses and execs /usr/share/xsession
<alkisg> OK, moment
<xnox> alkisg: note that unity is not the default xsession in Ubuntu =)
<xnox> we dont' provide one.
<alkisg> ubuntu is
<xnox> can i run ldm locally, without having the rest of LTSP stuff?
<xnox> (as in as a replacement for local lightdm?)
<cjwatson> zyga,mvo: If you mean tarmac for git, I'm reasonably sure it still needs a couple of small LP changes
<xnox> alkisg: send me ldm info and or links to xnox @ubuntu.com and i'll look into it.
<xnox> got to go.
<alkisg> xnox: it's not ldm specific
<zyga> cjwatson: yes, what kind of changes are you thinking about?
<alkisg> I can send you other DMs if you want...
<alkisg> xnox, should I file a bug report so that we talk there?
<xnox> alkisg: i need to see what ldm does, and check  if it is sensible.
<alkisg> Thanks a lot btw
<zyga> ev: hey
<xnox> alkisg: from what i can tell - supported login managers in ubuntu parse /usr/share/xsession/ubuntu.desktop correctly and launch it correctly. something is broken in LDM case.
<zyga> ev: would you have a moment to talk about CI
<xnox> either in parsing or launching or what not.
<xnox> and fiddling with xsession.d seems like the wrong place to band-aid it.
<alkisg> xnox, you can't use ldm locally, here's the relevant script: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/view/head:/rc.d/X50-dmrc-processing
<alkisg> xnox: the problem started when *upstart* fiddled with Xsession.d
<alkisg> That's what I'm trying to fix
<cjwatson> zyga: It doesn't have quite enough API to be able to operate on merge proposals for a given repository; needs some thought about what to do with linked bugs, although I suppose that could be treated as optional for the time being
<alkisg> It put 00upstart in the wrong place
<alkisg> I.e. before the xsession is determined
<zyga> cjwatson: yeah, I would treat that as optional for now, can you be more specific as to what is missing?
<zyga> cjwatson: I wanted to creat a proof-of-concept merger for git on launchpad
<alkisg> xnox: anyway, if you're willing to do that:
<alkisg> (12:32:35 Î¼Î¼) alkisg: Are you willing to do the same if "$1" is empty?
<alkisg> (12:32:41 Î¼Î¼) xnox: yes.
<alkisg> LTSP is fine then
<alkisg> Problem solved
<zyga> cjwatson: so I need to query for merge proposals for a repository (I can do branch filtering locally)
<cjwatson> zyga: git_repository.landing_candidates basically
<xnox> alkisg: think of upstart user session as supper-set and replacement for xsession. it doesn't support all xsessions ever possible.
<zyga> ah
<zyga> cjwatson: so that's not exposed yet, I see
<xnox> and thus it doesn't parse xsessions and bails out on unknown stuff.
<alkisg> xnox: we're not looking for other xsessions
<cjwatson> zyga: right, largely because the name is awful and we were trying to think of a better one
<zyga> cjwatson: is that being worked on now?
<zyga> :D
<cjwatson> zyga: but maybe we should just give up and export the bzr-ish name
<cjwatson> zyga: we want tarmac for Launchpad itself, so it's definitely on our radar :)
<zyga> cjwatson: I think exporting any name now is good, I suspect both people that use it won't mind
<alkisg> xnox: it only needs to support "default" and <empty>, as specified in the Xsession manpage
<zyga> cjwatson: have you thought about the way tarmac uses zbr?
<cjwatson> that's not quite how we deal with LP API compatibility
<zyga> cjwatson: as a checkout, with lock held?
<cjwatson> zyga: I don't much care, it clearly can't do that with git
<zyga> cjwatson: do you have an idea on how to translate that to a full clone that doesn't have the lock
<zyga> cjwatson: ok
<alkisg> xnox: if you're willing to add support for <empty> in 00upstart, it's fine for ltsp. As a programmer I think it's wrong, but as LTSP upstream I don't mind
<zyga> cjwatson: one more question, how do you talk to git from launchpad, any library to recommend?
<cjwatson> zyga: presumably it can just try and fail if it tries to push a non-fast-forward thing
<cjwatson> zyga: we use pygit2
<zyga> cjwatson: thanks
<cjwatson> zyga: it's not entirely packaged in Ubuntu, but the bits we use are in the LP PPA
<cjwatson> zyga: however, due to not being packaged, it might be better for tarmac just to call out to git
<cjwatson> zyga: the pygit2 API isn't very stable
<zyga> cjwatson: yeah, that is somewhat easier
<cjwatson> zyga: it's not like calling out to git involves slow Python process startup, unlike bzr
<xnox> alkisg: looking at what you posted default is LDM concept and it is suppose to "get_dmrc_key" Session... and if that is empty you bail....
<xnox> alkisg: which is a wrong thing to do.
<xnox> alkisg: first you need to check which sessions you have available e.g. ls /usr/share/xsessions/*.desktop and populate that as list of availble options
<xnox> (even over ssh)
<zyga> cjwatson: can you ping me (or tell me where to look) for when the missing api lands to production/
<xnox> and if user didn't choose any, choose one of the available ones.
<xnox> (e.g. no Session defined in .dmrc)
<pitti> apw, infinity: do you plan to merge initramfs-tools this cycle? I'm particularly interested in the bits that mount /usr from the initramfs, as that's a rather major delta that we have right now
<alkisg> xnox: if the user has something in his .dmrc, he's notified that it's a wrong selection before it falls back to the defaults
<alkisg> That's done by Xsession since ages
<alkisg> *something wrong
<xnox> alkisg: and your defaults should be one of the options from /usr/share/xsessions for ubuntu
<alkisg> xnox: if the user has specified a session?
<alkisg> Why?
<alkisg> Anyway, that's unrelated
<cjwatson> zyga: also, tarmac's use of bzr with locks and such is really just a written-out version of what the bzr client does; I don't think it's using a bound branch, so the lock is purely local to tarmac
<xnox> alkisg: if the user didn't specified any.
<alkisg> The user gets notified that he has selected a non-existing session
<alkisg> Ah then we just use ''
<zyga> cjwatson: it actually is
<xnox> alkisg: because on ubuntu all valid options for login manager are provided in /usr/share/xsessions only.
<alkisg> I.e. we let xsession do its job
<cjwatson> zyga: oh, well, shrug, same comment as above then
<zyga> cjwatson: but anyway, that just won't carry over to git world
<zyga> cjwatson: yeah
<xnox> alkisg: and the you shouldnt' use '', you should bail =)
<xnox> alkisg: you have nothing to login into.
<alkisg> xnox: yes, and Xsession is smart enough to select the one that is at /etc/alternatives/x-session-manager
<cjwatson> zyga: api> can do, just remembered that I also wanted to think about the way the source/target/prereq refs are exported on the branch_merge_proposal webservice object
<alkisg> xnox: suppose you have 3 sessions in xsessions/
<alkisg> Which one does your DM login to?
<alkisg> The one defined in alternatives
<alkisg> That's what Xsession does as well
<alkisg> Why is that an issue?
<xnox> alkisg: it gives me a drop down to choose from in alpahbetical order by pretty name.
<cjwatson> zyga: it's just about usable in principle by tarmac today but is a bit cumbersome, needs some thought
<alkisg> xnox: and which entry is preselected? Alphabetically?
<alkisg> No
<alkisg> Check the lightdm code
<xnox> alkisg: in lightdm greeter first one is pre-selected.
<alkisg> Really?!
<xnox> it's greeter specific, not lightdm core.
<zyga> cjwatson: my tarmac and lp api is too rusty to have an opinion on that yet, I need to poke it a little ot offer insight
<alkisg> What about lightdm-set-defaults previously,
<xnox> other greeter can do UI logic differently
<alkisg> and the lightdm.conf.d/users.conf now?
<zyga> cjwatson: are you familiar with the github API?
<zyga> cjwatson: can we learn something from that?
<cjwatson> zyga: we've looked at it and borrowed inspiration where appropriate
<xnox> it has config files to do specific things, e.g. on xubuntu builds we provide lgithdm setting to choose xubuntu as default.
<cjwatson> zyga: you're not telling me anything new by pointing me at it, at least ;-)
<xnox> because lightdm greeter behaves differently on ubuntu/xubuntu/lubuntu etc builds
<cjwatson> zyga: but it's necessary to fit the API into Launchpad's model as well, so it can't just be translated directly
<alkisg> xnox:lightdm provides this: [SeatDefaults] user-session=gnome-fallback
<zyga> cjwatson: I didn't expect anything less :)
<xnox> alkisg: to get upstart unity session you need to specify DESKTOP_SESSIOn
<zyga> cjwatson: ok, I'll look at the current API and get back to you
<Unit193> Considering, there's at least unity-greeter and lightdm-gtk-greeter for defaults?
<zyga> cjwatson: thanks!
<xnox> alkisg: in the case user doesn't choose it, LDM doesn't do it.
<alkisg> xnox: that's another issue, yes, otherwise it hangs
<alkisg> It doesn't bail, it just hangs
<xnox> alkisg: thus it is broken and doesn't laucnh ubuntu.desktop xsession correctly.
<alkisg> But OK we can do that
<cjwatson> zyga: sure.  I'd been planning to look at tarmac myself on the grounds that I was expecting to have to evolve the webservice a bit in parallel with working on it, but don't mind a slightly shorter to-do list ;-)
<alkisg> xnox: anyway, to sum up... are you williing to add support for empty parameter in 00upstart as you said?
<zyga> cjwatson: one thing I'd like to do with tarmac is to rip it in half later so that one can build a good web UI on top
<zyga> cjwatson: so that tarmac just runs somewhere in the back
<zyga> cjwatson: and people have live visibility into it
<cjwatson> I'll leave that up to you :)
<xnox> alkisg: DESKTOP_SESSION must be set though. and with empty parameter i don't see how that would be supported.
<alkisg> xnox: I'll push code to LDM to set DESKTOP_SESSION
<zyga> cjwatson: as for tarmac and launchpad itself, what do you require to run tests?
<cjwatson> from our point of view, well, right now what we have is pqm.launchpad.net which returns a mostly empty page unless it's actually in the process of merging something, practically anything would be an improvement
<zyga> cjwatson: what does tarmac do for you?
<zyga> (apart from merging)
<cjwatson> zyga: nothing
<alkisg> xnox: or, I can send you a patch that sets it in 00upstart if you prefer
<zyga> cjwatson: it doesn't run tests?
<cjwatson> zyga: right now we're just looking for a merge robot
<alkisg> That ^ would be saner
<cjwatson> zyga: we don't use tarmac today
<zyga> cjwatson: ah, ok, thanks
<xnox> alkisg: no.
<cjwatson> zyga: our tests are run separately by buildbot, post-merge
<alkisg> xnox: it would be best if we wouldn't have to rewrite all DMs to support the newest upstart scheme that will go away in 2 years... :-/
<xnox> alkisg: earlier you said DESKTOP_SESSION is set....
<cjwatson> zyga: (but pre-deployment)
<alkisg> xnox: that's what I'm working on now
<xnox> alkisg: DESKTOP_SESSION is a generic thing from freedesktop.org
<alkisg> xnox: so in my tries since this morning, I have a patch that sets it
<alkisg> OK, then I'll fix that in LDM
<xnox> alkisg: .... so there is nothing for me to test. i'm out.
<cjwatson> zyga: so we just need something where authenticated developers can send a merge instruction
<alkisg> xnox: the empty one?
<alkisg> Didn't you say you're willing to do that?
<cjwatson> zyga: (right now, it's signed e-mail to pqm, we'd be open to sensible alternatives, preferably CLI)
<cjwatson> zyga: but aiui tarmac just takes top-approved MPs?
<alkisg> xnox: thanks a lot for your time, I'll file the bug against upstart and work around it from the LTSP code
<zyga> cjwatson: it has some knobs to tweak, yeah but it looks at approved MRs in general
<xnox> alkisg: the bug is in LDM, it should (a) parse desktop sessions (b) use freedesktop DESKTOP_SESSION
<xnox> at the moment it does neither
<alkisg> xnox: I patched (b)
<alkisg> And it does (a)
<zyga> cjwatson: you can define how voting works in a limited way
<cjwatson> zyga: right, so that would probably be basically fine for us, as long as we can turn off any test running and such
<alkisg> xnox: we do present a list to the user, it's in another script called ldminfod
<xnox> alkisg: it doesn't do (a).
<xnox> alkisg: it only ever parses "foo.desktop" if user asked for "foo" but how would a user know that?
<alkisg> xnox: at that point in the script I sent you, the user has selected the combobox entry of ldm that ldminfod sent
<alkisg> Let me give you the link to ldminfod...
<alkisg> xnox: anyway please don't focus on ldm
<alkisg> I'm wasting your time that way
<alkisg> Please only mention that one thing:
<zyga> cjwatson: yeah, tests are opt-in, nothing happens by default
<alkisg> xnox: in 00upstart,     if [ "$BASESESSION" = x-session-manager ]; then
<alkisg> ==> are you willing to add a || -z $BASESESSION there?
<cjwatson> zyga: we might need to tweak its policy a bit, but meh, it has plugins.  I think the policy we probably want is "top-approved by a member of ~launchpad", which isn't something tarmac supports natively
<cjwatson> zyga: or maybe "top-approved plus at least one Approve vote by a member of ~launchpad"
<cjwatson> (latter probably more sensible)
<xnox> alkisg: no
<cjwatson> mind you, LP's own security on setting MPs to top-approved might be sufficient
<alkisg> xnox: ok, thanks a lot for your time, I'll work around that bug in ltsp.
<xnox> alkisg: parse all .desktop sessions, over user a choice, there is no choice "default" since there is no default.desktop file, execute it property with DESKTOP_SESSION set and Exec= line from the .desktop file, that's only way how each of the DEs support being started via xsession.d scripts in Ubuntu Project as a whole.
<xnox> and elsewhere in other freedesktop compliant DEs and other login managers (e.g. gdm, mate, etc.)
<xnox> ssdm and so on.
<alkisg> xnox: you have misunderstood a *LOT* of what I said and what we do. It might be due to english not being my native language
<alkisg> We do parse all .desktop sessions
<alkisg> I've said it a lot of times, I don't know why you're still saying that we don't
<alkisg> I never said that there's a "default" choice
<xnox> .... yet still have default) case in the script you pointed me to, which should never be executed.
<alkisg> I don't know why you're saying that
<alkisg> I don't want to set the Exec line though
<alkisg> It's against the standards
<xnox> there is no /usr/share/xsessions/*.desktop file in ubuntu with empty Exec line
<alkisg> I will put a script to work around the upstart bug, but not set the Exec line
<alkisg> check man Xsession
<xnox> yet you somehome "parse" them and provide empty "exec" line.
<alkisg> LDM wants to support the default Xsession in the sense of xorg
<xnox> alkisg: you suppose to get exec line from .desktop file.
<alkisg> Not in the sense of xnox
<alkisg> No
<alkisg> I'm not supposed to do that unless the user specified that
<xnox> alkisg: in the sense of xorg, there is no such sessions in ubuntu. We moved on to freedesktop specs from xorg.
<alkisg> Either from a menu, or from a config file
<xnox> alkisg: keep up with recent times.
<alkisg> For one -z line?
<alkisg> That's why we're arguing for 1 hour...
<alkisg> You can support running plain xsession with one -z
<alkisg> And you don't want that
<alkisg> OK, I don't mind
<alkisg> But I do want to support it in ltsp
 * alkisg is sad because he appreciates xnox a lot... hopefully he knows that :-/
<pitti> cjwatson, apw, Laney, utlemming, etc.: debootstrapping wily is fixed now, FTR
<cjwatson> Thanks
<Laney> good stuff
<pitti> cjwatson: I added a gross hack to /usr/share/debootstrap/functions to use local .debs
<pitti> I wonder why after all these years the debootstrap maintainers never needed that ;)
<cjwatson> Probably everyone just did the same local hack when they did and never worked out how to productionify it
<highvoltage> is it new that the ubuntu image builders do an upgrade instead of building the image from scratch? (was just surprised looking at today's build failure but I've also admittedly not kept track for the last release)
<cjwatson> They don't
<cjwatson> I mean, there's probably an upgrade in there due to live-build, but it's incidental
<highvoltage> yeah in today's failed build it was...
<highvoltage> 63 upgraded, 12 newly installed, 0 to remove and 0 not upgraded.
<cjwatson> highvoltage: That's just upgrading the buildd base image
<highvoltage> but good to know that it's just incidental
<cjwatson> highvoltage: It doesn't relate to the output live image
<cjwatson> highvoltage: You can see further down that there's still a debootstrap
<rbasak> slangasek: with your unixodbc maintainer hat on, please could you take a look at bug 1319701? In particular, I'm not sure your changelog message in bug comment #7 is true based on what upstream are saying in #5.
<ubottu> bug 1319701 in php5 (Ubuntu) "ODBC apps different SQLLEN sizes linked against same DM" [Undecided,Confirmed] https://launchpad.net/bugs/1319701
<strikov> I'm trying to install udev-dbgsym on trusty and this operation fails because udev 204-5ubuntu20.11 is available in -updates but only udev-dbgsym 204-5ubuntu20 (without .11 at the end) is available in ddebs. Is it expected? More details: http://pastebin.ubuntu.com/11243234/
<strikov> rbasak: Hi! Do you any thought on ^^^
<strikov> * Do you have any thoughts on ^^^
<cjwatson> strikov: The ddeb publishing mechanism was inherently unreliable for all builds that happened up to the end of last month.
<cjwatson> strikov: As of the end of last month, they're stored in Launchpad and we won't lose them; but if a ddeb built before that isn't on ddebs.ubuntu.com, it's lost.
<strikov> cjwatson: I see, thanks. So that's somewhat expected.
<cjwatson> It's not surprising, at least.
<rbasak> Thanks cjwatson. strikov: I didn't know anything about this really. Do you need any help from me? If you're doing what I think you're doing, can you rebuild systemd locally, update a cloud image locally with that build and then use the ddeb you produced locally if that reproduces the issue?
<strikov> rbasak: I think I'm fine. I wanted to know which ID_PATH has been generated for virtio devices before udev guys disabled this functionality. I finally found this value on precise. I wanted to do some gdbing on trusty but not it's not really needed. Thanks anyway!
<strikov> rbasak: ID_PATH looks like pci-0000:00:04.0-virtio-pci-virtio2 and helps you to identify the specific device in udev rule
<rbasak> I see. Makes sense.
<strikov> rbasak: Unfortunately this ID_PATH is not generated for virtio devices anymore. Point behind this decision is that order of virtio devices can be randomly shuffled on vm reboot hence we can't rely on ID_PATH value
<mgedmin> which package is responsible for creating /root/.profile?
<mgedmin> because https://bugs.launchpad.net/ubuntu/+source/xen-3.1/+bug/1167281 clearly shouldn't be assigned to xen
<ubottu> Ubuntu bug 1167281 in xen-3.1 (Ubuntu) ""stdin: is not a tty" due to "mesg n" instead of "tty -s && mesg n" in .profile" [Undecided,Confirmed]
<ogra_> pitti, did we forget to switch the anacron cron.d job to systemd ? https://lists.ubuntu.com/archives/ubuntu-users/2015-May/280909.html
<tjaalton>    Loaded: loaded (/lib/systemd/system/anacron.service; enabled; vendor preset: enabled)
<tjaalton> works fine for me
<seb128> mardy, thanks for looking at that fb integration issue!
<pitti> ogra_: the .service is there (as tjaalton said), there might be this "start -q anacron" somewhere still, though
<pitti> not in /etc/cron.d/anacron, that uses invoke-rc.d
<ogra_> i wonder how the user got to that state then
<ogra_> seems he has the old /etc/cron.d/anacron ...
<pitti> ah, the joys of old conffiles
<mardy> seb128: yw!
<mardy> seb128: I also commented here: https://bugzilla.gnome.org/show_bug.cgi?id=748991
<ubottu> Gnome bug 748991 in web-sharing "Error to publish on Facebook" [Major,New]
<geser> pitti: do you have an idea why https://launchpadlibrarian.net/205906374/buildlog_ubuntu-wily-amd64.cpl-plugin-amber_4.3.3%2Bdfsg-2_BUILDING.txt.gz failed during building the ddebs? does the package something wrong? (some more cpl-plugin-* fail with the same error)
<seb128> mardy, thanks
<pitti> geser: not off-hand; building locally
<pitti> geser: would you mind filing a bug against pkg-create-dbgsym for now? sounds like another special case with this funny override_dh_gencontrol-indep
<geser> pitti: done; bug #1457038
<ubottu> bug 1457038 in pkg-create-dbgsym (Ubuntu) "Builing the -dbgsym packages for cpl-plugin-* fails" [Undecided,New] https://launchpad.net/bugs/1457038
<pitti> geser: thanks
<micahg> Laney: yep, trying to move some things along
<slangasek> rbasak: Debian and Ubuntu were always using a 64-bit SQLLEN on 64-bit archs despite this not being the upstream ABI, because the upstream ABI was broken and there was no reason to keep compatibility with it
<rbasak> slangasek: I see, thanks.
<rbasak> slangasek: I don't really follow this bug at all though :(
<rbasak> Anyway, I guess it's not that important in the grand scheme of things.
<pitti> rbasak: ok, the mystery in bug 1450053 just became a lot smaller :)
<ubottu> bug 1450053 in mysql-5.6 (Ubuntu) "upgrade 14.04 to 15.04, mysql no longer starts on boot due to missing policykit-1" [High,Incomplete] https://launchpad.net/bugs/1450053
<slangasek> rbasak: what is "PDO ODBC"?
<slangasek> oh that php odbc nonsense
<slangasek> yeah so I don't know how that package was built to get 32-bit SQLLEN, but it's not unixodbc's fault ;)
<rbasak> Yeah. PHP ships two separate modules. odbc.so, and pdo_odbc.so.
<rbasak> I presume two different APIs or something from the perspective of a PHP user. Not really sure.
<rbasak> pitti: I'm still a little confused as to how that happened. mysql-5.6 in Trusty and Utopic is SysV only I think.
<pitti> rbasak: perhaps he has -5.5 installed? that's the most plausible explanation so far
<rbasak> I guess. It should have got upgraded though.
<micahg> hi pitti, you seem to be TIL on libgphoto2, was this a merge you were planning on doing?  There's at least one thing in dependency wait for it
<pitti> micahg: ah, can do; queueing for tomorrow
<micahg> great, thanks
<pitti> rbasak: ah, mariadb :)
<rbasak> pitti: ah. Thank you for working that bug.
#ubuntu-devel 2015-05-21
<pitti> Good morning
<tjaalton> Unknown release wily
<tjaalton> wth?
<tjaalton> trying to upload
<wgrant> tjaalton: What said that?
<tjaalton> dput
<tjaalton> -ng
<wgrant> Sounds like out of date distro-info-data or similar.
<tjaalton> yeah, upgrading
<pitti> infinity: hey! do you happen to remember historic reasons why "mount" is split from util-linux?
<pitti> infinity: just because of the any vs. linux-any arch:, or something else?
<infinity> pitti: No idea.  You'd have to ask lamont.  Or maybe whoever maintained it before lamont.
<pitti> infinity: thanks
<infinity> pitti: Given that they're both required/essential, it does seem a bit silly, but is it causing harm?
<pitti> infinity: ah was considering to merge them, as the split seems unnecessary, and it's making it easier to move stuff around like 'mountpoint' without having to NMU sysvinit again
<pitti> infinity: so it's more like a "can we clean this up?" question, not really harmful
<infinity> pitti: That statement didn't make much sense to me.  Oh, as in, moving mountpoint from X to Y and having to update a Breaks or Depends in sysvinit?
<pitti> right
<infinity> Yeah, mountpoint should be in util-linux, not mount.
<pitti> infinity: ah, don't get too confused by that; having to update the Breaks: was mostly just what triggered the question why they need to be split in the first place
<infinity> If I was actually participating in maintainership, I would have noticed that. :/
<pitti> right, that's what we need to fix, to get back mountpoint for !linux
<pitti> and while we're at it, he wondered if we shouldn't just move everythign, and make mount transitional (and then fix the ~ 5 rdepends over time)
<infinity> pitti: The split may indeed just be about linux and non-linux.  Or maybe something more subtle.  But it also seems to do no harm to have the split, so I'm a bit "meh" about rocking that boat.
<infinity> pitti: That said, while I have strong opinions about lots of things, I'm not sure it's worth listening to the opinion of someone who hasn't had time for util-linux in ages.
<zyga> hmm
<zyga> sone of the recent updates broke virtualenv -p python3 on wily
<zyga> http://pastebin.ubuntu.com/11260203/
<zyga> looks like it's in pip-1.5.6
 * mgedmin wonders when ubuntu will get a more modern pip version
<zyga> hmm
<zyga> didrocks, barry: ^^ (virtualenv broken on wily, you are the last two uploaders of pip, any ideas?)
<didrocks> zyga: was it broken on vivid?
<zyga> didrocks: nope
<zyga> didrocks: broke yesterday
<zyga> didrocks: or so
<zyga> didrocks: I'm on wily since day one, I don't rebuild my virtualenvs every day but I do do it often, so this broke very recently
<didrocks> zyga: maybe python 3.5?
<zyga> oh
<zyga> did we get it now ^_^
 * zyga looks
<didrocks> seems so, yesterday at midnight
<zyga> ah
<zyga> I don't have python3.5 in apt yet at all
<zyga> so probably not that
<zyga> or maybe package uploads are out of alignment and it will fix itself with 3.5
<zyga> didrocks: do you know if we build the wheel binaries out of the debianinzed packages or from original upstream wheels?
<didrocks> zyga: that's a question for doko_ I guess
<zyga> didrocks: thanks
<didrocks> yw, let's see once he's around
<lamont> pitti: I want to say it's just because of any vs linux-any
<mvo> pitti: hi, just a quick (and maybe silly) question - could autopkgtest for snappy also drive real beagleboneblack with the ssh driver? I would love to have working reboot tests for this as well and wonder how realistic this is
<lamont> which is much cleaner than the fugly mess it used to be
<pitti> mvo: yes, should work; I've seen people run tests on a real BB in Austin
<pitti> mvo: the one thing you need to do is to add the "--- ssh --reboot" parameter (or -r), to tell autopkgtest that it's safe to reboot the testbed (we can't assume this for everything)
<pitti> lamont: thanks
<mvo> pitti: nice, I will add that
<pitti> mvo: (details @ http://www.piware.de/2015/05/autopkgtest-3-14-now-twice-as-rebooty/)
<mvo> pitti: my other question is that I assume autopkgtest support "embeding", i.e. main autopkgtest builds the deb, runs the tests, installs the new debs into a snappy VM, then fires up a snappy VM using adt that contains the new debs and runs the selftest in the image with the new snappy)
<mvo> pitti: cool, thanks
<pitti> mvo: I don't understand that
<mvo> pitti: sorry
<pitti> mvo: how is that different from --dsc or --unbuilt-tree? that would build the debs,  install them on the testbed, and run the tests
<mvo> pitti: maybe its not and I'm thinking too complicated :)
<pitti> mvo: that's assuming --setup-commands 'mount -o remount,rw /' of course (IOW, cheating)
<pitti> mvo: but, consider that you likely can't build anything *on* snappy, you should do that outside in a proper sbuild or so
<mvo> pitti: yeah, thats the think, I build/test outside of the snappy image, then want to run the selftest in a snappy image that contains the newly build debs
<mvo> s/think/thing/
<pitti> mvo: so the usual approach would be sbuild -s newsnappy.dsc; adt-run newsnappy_amd64.changes --- ssh ...
<pitti> mvo: or, more explicitly, adt-run *.deb -B newsnappy.dsc --- ssh ...
<pitti> running a binary .changes is the same as running all debs in it plus the tests from the .dsc in it
<mvo> pitti: ok, thanks. I will see what I can do (after lunch :)
<ah> lamont: thanks for the background info w.r.t mount vs util-linux.
<cjwatson> doko: Can you have a look at what's up with gcc* on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150521-wily.html (still in progress)?  That's a test rebuild of main in scalingstack with modern sbuild.
<pitti> cjwatson: wohoo!
<doko> cjwatson, the gcc-4.9-* are replaced by gcc-4-9-cross, working on it
<cjwatson> If this works out OK we should be able to move all x86 builds into scalingstack in the next week or two.
<doko> the other one is a mismatch between an alternate b-d and what is actually used for building
<cjwatson> doko: gcc-5?
<cjwatson> doko: can you expand on that?
<barry> zyga, didrocks https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785787
<ubottu> Debian bug 785787 in python-distlib "[REGRESSION] python-distlib == 0.2.0-1 breaks virtualenv and tox" [Normal,Open]
<didrocks> here we go :)
<zyga> barry: thanks!
<doko> cjwatson, gnat-5 gets installed, but gcc is called. should be gnatgcc-5 or gcc-5
<cjwatson> doko: old sbuild would have done the same thing though, right?
<cjwatson> since that's the first in a list of alternates
<cjwatson> wgrant: shouldn't we be using --resolve-alternatives, though?  I had a mental note that we needed that for equivalence with old sbuild but missed it in review
<doko> yeah, wondering why it showed up now, because it built before. and there is only gnat-5 in main, not gnat-4.9
<cjwatson> wgrant: I suspect we'll see some things that are main Build-Depends: package-in-universe | package-in-main that now fail to build, but we'll see
<cjwatson> doko: seems to be installing roughly the same build-deps, just different versions
<cjwatson> doko: and lower parallelism because we're making different trade-offs in scalingstack, but I shouldn't have thought that would matter here
<cjwatson> -checking for x86_64-linux-gnu-gcc... gnatgcc
<cjwatson> +checking for x86_64-linux-gnu-gcc... gcc
<cjwatson> doko: aha
<cjwatson> cjwatson@pepo:~$ dpkg -c gnat-5_5.1.1-5ubuntu4_amd64.deb | grep bin/gnatgcc
<cjwatson> lrwxrwxrwx root/root         0 2015-05-13 16:41 ./usr/bin/gnatgcc -> gcc-5
<cjwatson> cjwatson@pepo:~$ dpkg -c gnat-5_5.1.1-6ubuntu1_amd64.deb | grep bin/gnatgcc
<cjwatson> lrwxrwxrwx root/root         0 2015-05-19 21:13 ./usr/bin/gnatgcc-5 -> gcc-5
<cjwatson> latter presumably more correct but do you perhaps need to take account of it in the build?
<doko> ahh, I see. I shouldn't rename gnatgcc to gnatgcc-5 then. the gnat packages conflict anyway
<doko> still waiting for feedback from ludovic brenta, he's very quiet recently
<cjwatson> you'll presumably need to handle the existing name in order to build a fix :-)
<doko> yep, or just using gcc-5
<doko> hmm, just loged out, and after re-login, the vpn is still active?
<xnox> yes... it's network manager
<doko> interesting
<xnox> doko: so stgraber runs VPNS in their own network namespace as a user-namespace container.... then the vpn is a user process as a whole.
<cjwatson> tedg: Does the dbus-test-runner failure on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150521-wily.html mean anything to you?
 * tedg clicks
<cjwatson> tedg: (this is a test rebuild of main in scalingstack with modern sbuild; the main purpose is just to shake out problems related specifically to those changes before we make all of Ubuntu x86 build that way)
<tedg> cjwatson, It looks like a timeout of shutting down dbus. Not sure why scalingstack or sbuild would effect that.
<tedg> cjwatson, The test harness makes sure the dbus connection closes, or it times out and errors.
<cjwatson> tedg: I can retry if you think that might help.  Is it possible that it just has an unnecessarily low timeout?
<tedg> cjwatson, Oddly, it's failing on the easiest test case :-)
<tedg> cjwatson, That would be my guess, but it would be kinda surprising.
<cjwatson> tedg: The entire build only took 1.5 minutes, so the timeout can't be that long
<tedg> It is something like 10 seconds.
<cjwatson> (and that's including build-dep installation and such)
<cjwatson> it's not running on dedicated hardware, so I suppose it could have been scheduled out if the nodes are overcommitted or something
<cjwatson> retrying, scored up a bit so we get a chance to recheck soon
<tedg> cjwatson, Great, thanks!
<xnox> doko: i'm toying with boost here.... a no change rebuild with c++11 abi took out source-highlight with undefined symbols throughout.
<xnox> i'll do more tests, but it seems like we will have pain with boot.
<mrmcq2u> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1455845
<ubottu> Ubuntu bug 1455845 in pulseaudio (Ubuntu) "Pulseaudio sinks nightmare to navigate" [Undecided,New]
<mrmcq2u> any thoughts?
<jamespage> please could an archive admin bump python3-greenlet to main in wily - its a binary only movement and is needed for new eventlet
<cjwatson> jamespage: done
<jamespage> cjwatson, ta
<Dragonkeeper> hey guys
<Dragonkeeper> im interested in if there is a way to install ubuntu on no standard hardware lacking a standard bios
<Dragonkeeper> in this case a chromebook cb3-111
<sarnold> Dragonkeeper: the iso images should do 64-bit uefi alright; 32-bit uefi may take more work
<Dragonkeeper> sarnold: im attempting to use chrubuntu script to boot from usb + seemed my firmware wasnt in dev mode even though the OS was . so see how this goes
#ubuntu-devel 2015-05-22
<alkisg> upstart needs /sbin in its path to work (/etc/X11/Xsession.d/99upstart). ssh, sudo, lightdm etc all put /sbin in the user's path. `su -` doesn't put it, it uses the values from /etc/login.defs instead of /etc/environment, so one cannot launch upstart if he logged in with `su -`.
<alkisg> That affects us in LTSP were we're using our own DM. We can work around it, but it does sound like inconsistent behaviour, should I file a bug against upstart or su?
<micahg> based on the man page, sounds like a bug against su
<micahg> well, there's at least the bug against su, can't speak for upstart's proper behaviour
<alkisg> Thank you micahg, I'll file a bug against it
<alkisg> xnox, good morning, I've filed LP #1457730 about what we were talking about 2 days ago, feel free to close it as "won't fix" if you prefer, but I wanted to document it so that I mention why the workaround is needed in the LTSP changelog. I hope you know I appreciate you and thanks for the time you've dedicated in chatting about it with me.
<ubottu> Launchpad bug 1457730 in upstart (Ubuntu) "Upstart packaging conflicts with man Xsession" [Undecided,New] https://launchpad.net/bugs/1457730
<pitti> Good morning
<Mirv> I wonder if anyone has wily in an lxc working? just checking. I just get "E: Method http has died unexpectedly" when attached and trying apt update :(
<Mirv> oh, interestingly it's just my lack of lxc skills, but seems like downgrading apt to the previous version works
<Mirv> s/just/not just/
<Mirv> I filed bug #1457754 , triaging help welcome since I have no idea what's happening in there
<ubottu> bug 1457754 in apt (Ubuntu) ""E: Method http has died unexpectedly" when run under lxc on wily apt 1.0.9.9ubuntu1" [Undecided,New] https://launchpad.net/bugs/1457754
<zequence> Can I request backports from Vivid to Trusty at this time?
<zequence> Seems like every time there is a new non-LTS release, you don't really want to backport to the latest non-LTS release
<zequence> Only to the LTS
<zequence> I know in the past you had to backport in the correct order, like Vivid -> Utopic -> Trusyt
<zequence> We might want to do a bunch (The Ubuntu Studio dev team), and we're not really that interested in backporting to Utopic
<pitti> zequence: AFAICS the problem there is primarily to ensure that utopic has a newer version than trusty
<pitti> zequence: otherwise, if you backport to trusty from vivid, install that, and upgrade to utopic there is no version for that package, and it might not even be installable any more
<pitti> (i. e. conflict because of changed libraries, etc.)
<zequence> pitti: Ah, right.
<Mirv> stgraber: you may not have gotten enough thanks yet for your lxc blog series, so here's +1!
<cjwatson> tedg: dbus-test-runner/amd64 did build cleanly in the end.  Must have been a race of some kind ...
<Mirv> ok, that mix of -fPIC/-fPIE patches was not perfect after all
<Mirv> mitya57: since we need to keep -reduce-relocations not set (so not enforcing) and have -fPIE on arm, do you see any other option out than to actually do what I was already doing, ie keep all of the patches disabled?
<mitya57> Mirv: I think it's OK to disable them until we find a better way to fix that
<mitya57> But those patches are applied upstream in 5.4.2 anyway
<Mirv> so they are
<LocutusOfBorg1> Oh bad I can't install xserver-xorg-dev on a clean 14.04.2 machine
<LocutusOfBorg1> the usual xorg backport, I'm wondering *why* people backport it :)
<LocutusOfBorg1> giving me bugs like 1424769
<LocutusOfBorg1> so I have bug 1457776, but I can't fix it because of impossibility to satisfy build-depends
<ubottu> bug 1358157 in virtualbox (Ubuntu) "duplicate for #1457776 virtualbox-dkms 4.3.10-dfsg-1: virtualbox kernel module failed to build [error: macro "alloc_netdev" requires 4 arguments, but only 3 given]" [High,Invalid] https://launchpad.net/bugs/1358157
<LocutusOfBorg1> anyway time lo leave
<LocutusOfBorg1> bye folks
<rcj> wgrant, How can I delete an LP git repo created in error https://code.launchpad.net/~rcj/open-vm-tools/+git/open-vm-tools
<cjwatson> rcj: You can't yet, but I have approved branches ready to land to fix that.
<cjwatson> rcj: Should roll out next week.
<cjwatson> rcj: Once it rolls out, there'll be a nice obvious "Delete repository" link at the top right there.
<rcj> cjwatson, thanks
<taggart> kees, cjwatson: does ubuntu use sshd_config DebianBanner?
#ubuntu-devel 2015-05-23
<Logan> does anyone know what bugproxy is? e.g. this cryptic report at https://bugs.launchpad.net/ubuntu/+bug/1457146
<ubottu> Ubuntu bug 1457146 in Ubuntu "Add OFED packages for Ubuntu 15.10" [Undecided,New]
<Logan> appears to have something to do with...IBM?
<cjwatson> taggart: The patch is there, but it's not in our configuration by default.  (That is, the patch introduces a way to turn off the Debian revision in the protocol handshake, but the default is to leave it in there.)
<Quintasan> Hi
<infinity> Logan: Yeah, it's a proxy from IBM's internal bug tracker.  Irksome that they picked a generic name.  Maybe we should force a rename on them.
<infinity> wgrant: Do you know the right people to talk to to get IBM to fix their auth tokens and code to cope if we force an s/bugproxy/ibm-bugproxy/ rename on them?  That generic account name is irksome/confusing.
<taggart> cjwatson: ok cool, I am updating a puppet module and I am going to setup "DebianBanner no" for both debian and ubuntu
<taggart> cjwatson: and I am starting to wonder if that would be a good idea for the package
<cjwatson> taggart: I wouldn't accept such a change
<cjwatson> taggart: The existence of the option is a reasonably stable compromise :)
<wgrant> infinity: You should probably rather get them to fix the displayname. The username is less interesting.
#ubuntu-devel 2015-05-24
<infinity> wgrant: I was going to fix the displayname myself, but although I have access to the name changey page, it gets annoyed with me when I submit. :P
<infinity> wgrant: Still, I think the namespace pollution of the username itself is also wrong.
<wgrant> infinity: Sure, but we don't forcibly change people's names unless their abusive.
<wgrant> ...
<wgrant> they're
<infinity> wgrant: No, but we can suggest a name change, and then execute on it if they agree.
<infinity> wgrant: I wasn't suggesting forcing anything, just asking if you had contacts, since they've talked to you in the past while writing the bot.
<wgrant> infinity: It seems to be different people every time, but I'll see if I can work out who is in charge.
<infinity> pitti: Do you know why the apport autopkgtest has been failing for ages?
<Noskcaj> Is something broken in the lp:debian/* branches? None seem to be updating
<wgrant> Noskcaj: It wasn't updated for stretch and wily. I've added them and restarted it.
<Noskcaj> thanks wgrant
<Noskcaj> also, http://qa.ubuntuwire.com/bugs/rcbugs/ needs a wily version if you have time
<Noskcaj> tumbleweed, http://qa.ubuntuwire.com/neglected/ seems to be broken
<tumbleweed> Noskcaj: it looks like UDD imports broke on syklone
<tumbleweed> (ubuntuwire)
<ari-tczew> xnox: could you take a look in free time on bug 1458397 ?
<ubottu> bug 1458397 in fuse (Ubuntu) "Merge fuse 2.9.3-16 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1458397
<Noskcaj> ari-tczew, mousepad merge should be fixed.
<Noskcaj> The delta should be gone before we release wily, so i don't think it's a huge issue to over-simplify it
<ari-tczew> Noskcaj: You just edit debdiff manually, right?
<ari-tczew> I don't think today is 07 May.
<ari-tczew> "patch: **** malformed patch at line 154: "
<Noskcaj> I edited it manually, i think the malformed line is from a missing whitespace line
<Noskcaj> I suppose i'll just wait till UDD is fixed, since debdiffs/MoM is always a pain to use
<ari-tczew> Noskcaj: I don't think using debdiffs is a pain.
<ari-tczew> It's a question of quality work.
<Noskcaj> I realise, i've just never used debdiffs since they take longer, so i forgot easy stuff like fixing the name
<Noskcaj> And irrelevant of my quality of work i don't get upload rights, so i try to get as much stuff done in the little time i have to do ubuntu stuff
<ari-tczew> Noskcaj: You could just use dch script and rebuild a source. Then you can regenerate a debdiff. It's simple and don't take too much time. In effect you provide appropriate quality of work.
<Noskcaj> I'll look into it
<ari-tczew> Noskcaj: You take it as "easy stuff" and your reason is a fact you still don't have upload access. It's not a reason to poor taking care of minor things. Personally, I'm not aware that you'll remember about such things when you got upload access.
<ari-tczew> Noskcaj: anyway, your debdiff needs to be fixed. I'll comment that on LP.
#ubuntu-devel 2016-05-23
<Logan> nacc: curious why you added a php-mbstring build dependency for php-finder-facade, since it doesn't seem like it needs it
<slangasek> Unit193: thanks for the pointer to bug #824943, but I'm not sure how you concluded I missed it, since that package had not been uploaded to the NEW queue at the time you wrote that :)
<ubottu> bug 824943 in software-center (Ubuntu) "software-center-gtk3 crashed with IndexError in _render_exhibit_at_cursor(): list index out of range" [Undecided,Fix released] https://launchpad.net/bugs/824943
<Unit193> slangasek: ESP!  But I saw ubuntu-core-launcher hit and looked at its changelog.  (And not sure/mistook that for snapd, partially because breaks and rest because tired.)
<nacc> Logan: hrm, i'm assuming i saw testcase failures w/o it. I will reverify tmrw AM.
<Logan> nacc: ok cool, thanks
<Logan> nacc: also you're aware that phpunit doesn't install properly at the moment, right?
<Logan> phpunit : Depends: phpunit-mock-object (>= 3.1) but 3.0.6-1+ubuntu1 is to be installed
<nacc> Logan: wasn't, but will add it to the list :) -- merging and getting 16.10 sync'd to Debian is my goal for this week across the php landscape
<nacc> Logan: i assume that was in 16.10 (and not 16.04)
<Logan> yep, that's correct
<Logan> I've been helping out with some syncs, at least :P
<nacc> Logan: thanks for letting me know, will get it fixed
<Logan> nacc: https://www.dropbox.com/s/j8upo5sbothxfi3/Screenshot%202016-05-22%2023.59.34.png?dl=0
<Logan> cheers :)
<slangasek> nacc: that's only in yakkety-proposed... I may have mentioned this earlier, possibly when you weren't looking at your IRC client :)
<cpaelzer> good morning
<pitti> Good morning
<pitti> Odd_Bloke: there's the upstream and Debian bug, not aware of a separate Ubuntu bug
<pitti> smoser: import tempfile> eww, ugly; that's also new since yakkety's py3?
<pitti> stgraber: the lxc failure is something else (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/l/lxc/20160521_010203@/log.gz)
<pitti> stgraber: we do have yakkety cloud images, but the test is looking for a yakkety-server-cloudimg-amd64-root.tar.xz which doesn't exist in https://cloud-images.ubuntu.com/yakkety/20160519.1/
<pitti> stgraber: did that maybe get renamed to -lxd.tar.xz?
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<seb128> enjoy dholbach ;-)
<Saviq> pitti, morning, can you please re-run http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api with --all-proposed?
<pitti> Saviq: will do, once the x86 backlog clears (we had some problems over the weekend)
<Saviq> ack
<Odd_Bloke> pitti: In yakkety, we're consolidating to just the squashfs; I believe stgraber and co. need to do some work before lxd will support that. :)
<pitti> Odd_Bloke: I take it droping -root.tar.xz was on purpose? but it sounds like -lxd.tar.xz would mostly replace it for nwo
<pitti> Odd_Bloke: stgraber force-badtest'ed lxc because of "missing yakkety images", but that just hides the real bug
<Odd_Bloke> pitti: -lxd.tar.xz is just the lxd metadata.
<pitti> oh
<Odd_Bloke> pitti: Dropping the -root.tar.xz was intentional, yes. :)
<pitti> Odd_Bloke: oh, and the -disk1 suffix got dropped as well? /me adjusts adt-buildvm-ubuntu-cloud
<Saviq> Mirv, we seem to have a problem https://launchpad.net/ubuntu/+source/qtchooser/58-gfab25f1-1
<Saviq> qtchooser : Breaks: libqt5core5a (< 5.5.1+dfsg-17~) but 5.5.1+dfsg-16ubuntu11
<Mirv> Saviq: yes, I noticed it about 1h ago when my builds started breaking too. I uploaded https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-17ubuntu1
<Saviq> Mirv, ack
<Saviq> pstolowski, â
<Mirv> it got autosynced from Debian where they did simultaneous uploads
<zyga> ogra_: hey
<zyga> ogra_: around?
<pitti> sil2100: to confirm, we won't build any touch products from yakkety, right? we'll move to xenial
<sil2100> pitti: hey! Yes
<pitti> sil2100: hey, how are you?
<pitti> sil2100: and long-term we'll move away from system-image towards snappy, right?
<pitti> sil2100: in systemd we still have that awful patch to use /etc/writable/; it's our only delta, so I'd like to sync systemd in yakkety now, as we won't need that patch anytime soon (or not at all any more)
<pitti> we can restore it at some point if needed, but I see no need dragging it along all that time
<Odd_Bloke> pitti: Yep; we'll be sending out an email with the details (once we're sure they're fully implemented ^_^).
<pitti> Odd_Bloke: I did http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=6676ed6 for now, this seems to work
<sil2100> pitti: hm, so the end-plan is to use snappy, yes, but that's still a bit far from now
<sil2100> Since I'm not familiar with those parts, what would be the impact of dropping the patch?
<Odd_Bloke> pitti: FWIW, if you were consuming streams it should have Just Worked (TM). :)
<pitti> sil2100: in a yakkety-based touch image you couldn't set the time zone through timedatectl, and hence through the settings app
<pitti> Odd_Bloke: you mean parsing http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:download.json ?
<pitti> if that's a stable format, I can do that
<seb128> pitti, imho if we start dropping "things touch needs" we should record them in a bug
<pitti> seb128: I can do that, no problem
<seb128> pitti, but yeah, same line of thinking than when we said that packagekit 1.0 is fine because click isn't going to be needed by touch in y any time soon
<seb128> speaking of which
<pitti> seb128: is there a bug for that? I'll look at that one then to use the same tags and similar title
<seb128> doko, mvo, it might make sense to just drop aptdaemon-pkcompat in yakkety and use packagekit aptcc instead?
<seb128> pitti, not yet no, I just though now when I saw your systemd question that we should probably record the "known brekages" somewhere
<ogra_> zyga, just returned from dentist, whats  up
<ogra_> ??
<pitti> seb128: I filed bug 1584671 with a  dropped-ubuntu-touch-patch tag for now
<ubottu> bug 1584671 in systemd (Ubuntu) "[dropped touch support in 16.10] Support /etc/writable/ for system-image for timedated and hostnamed" [Low,Triaged] https://launchpad.net/bugs/1584671
<seb128> pitti, thanks
<zyga> ogra_: hey :-)
<zyga> ogra_: I sent this via email now
<zyga> ogra_: feel free to ping me here for details
<pitti> seb128: actually, I renamed it slightly as it's a patch for system-image, not touch per-se
<seb128> well, it impacts the touch flavor
<seb128> but I'm not picking on the name
<pitti> seb128: I mean I retitled the bug, I kept the tag
<pitti> but feel free to adjust, I don't mind
<seb128> oh, ok
<seb128> no, looks good to me
<seb128> pitti, thanks!
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach will do some more piloting tomorrow... too much going on today
<jamespage> cjwatson, morning
<jamespage> cjwatson, do PPA's ever forget about previous versions uploaded?  having some hassle around some packages in Debian that don't use consistent orig.tar.xz's (generated from git tags...)
<cjwatson> jamespage: Never.
<jamespage> cjwatson, I thought that was the answer - thanks for confirming...
<cjwatson> jamespage: Then again the Debian archive only forgets about those semi-randomly and over a fairly long timeframe.
<cjwatson> jamespage: So it's not like using inconsistent orig tarballs is free of problems there either.
<jamespage> cjwatson, this is a bit of a pet peeve for me atm
<cjwatson> I'm sure.
<cjwatson> Not going to change in LP though :)
<jamespage> cjwatson, I appreciate that - we'll figure out some sort of workflow to try limit this from happening
<cjwatson> You can use a different PPA if absolutely necessary; they're only remembered within a single archive.
<jamespage> I can fake-sync it for now
<cjwatson> But same file name with different contents isn't a good look.
<jamespage> cjwatson, for the packages we're directly maintaining for openstack in ubuntu this is not a problem, as we're using pristine-tar and a gbp based workflow atm across the team
<jamespage> its more of a problem where we're participating in pkg-openstack in Debian, where the policy is not that...
<jamespage> ho-hum
<Odd_Bloke> pitti: Yep, that's streams; talk to smoser to check if there are already tools that will do what you want. :)
<pitti> Odd_Bloke: in Ubuntu we have some python-simplestreams and simplestreams CLI, but they aren't available on Debian; so it's "parse the JSON" or continue the "guess URL" approach
<Odd_Bloke> pitti: Ah, of course. :)
<rbasak> pitti, smoser: simplestreams should be fairly trivial to get into Debian I think, if somebody wants to do that.
<seb128> slangasek, pitti, xnox, hey ... so upstart in yakkety-proposed fails to build on s390x and that blocks unity to land (which blocks important fixes to be SRUed because Trevinho wanted to be good citizen and land to devel before SRU) ... since nobody seems to have slot to work on the upstart build, any objection if we delete that version from y-proposed to unblock unity?
<seb128> Laney, Trevinho, ^
<rbasak> pitti: the format is logically stable, but you should pass your parse logic by me or smoser since some parts of that are designed to change.
<rbasak> (eg. don't assume that searching for a set of things by key will always result in one image if it does right now; use product IDs if you need a particular thing, etc)
<Trevinho> pitti: hey!
<Trevinho> pitti: also, could you re-review the upower patch? :)
<seb128> Trevinho, let's wait a bit for them to reply and delete it by mid-afternoon to unblock unity if they don't?
<Trevinho> seb128: ok
<seb128> Trevinho, you can prepare the SRU meanwhile ;-)
<Trevinho> seb128: sure, so... You'd say to keep things in one branch or, just I prepare a debsrc and you can upload... what you prefer? :)
<seb128> Trevinho, you are going the work so as your prefer
<seb128> if silo works fine just go with that
<Trevinho> seb128: silo is fine for me, but... It takes longer in general, to get uploaded
<seb128> why?
<Trevinho> if someone can then upload that quickly, I'm fine with it
<seb128> it just takes the time to get the build in the ppa done
<Trevinho> seb128: people deosn't see it?
<seb128> but then you spare it in proposed
<seb128> oh, you mean in the queue?
<Trevinho> seb128: see the other SRU branches I've:https://requests.ci-train.ubuntu.com/#/user/Trevinho
<seb128> I don't think so
<Trevinho> they're still waiting
<Trevinho> I've pinged people in ubuntu-release, but still...
<seb128> it's just SRU team being busy/not picking those
<seb128> I don't think manual upload would solve that
<seb128> though the fact that there is no diff handy in the queue webui might make a few reviewer skip over it
<seb128> lunch, bbiab
<Trevinho> seb128: mh, yeah... I see
<Saviq> pitti, hey, can you please rerun http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api with --all-proposed again, a Qt issue (resolved since) prevented the previous runs from completing
<pitti> rbasak: http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/yakkety/ppc64el/ is very flaky, I'll add a hint for that now; but I suppose mysql on ppc64el is a supported thing, can your team look into that?
<pitti> seb128: right, the queues fill up faster than they get processed, and hardly everyone gets back to t or w I figure :/
<pitti> Saviq: that goes for e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#webbrowser-app as well I suppose
<Saviq> pitti, looks like it, yes
<pitti> Saviq: same issue as in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/u/ubuntu-system-settings-online-accounts/20160523_090119@/log.gz ?
<Saviq> pitti, most likely yes
<Saviq> pitti, and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtdeclarative-opensource-src could use an --all-proposed re-run,too
<Saviq> and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
<Saviq> ...
<Saviq> omg we really want a new unity8 in the release pocket...
<pitti> Saviq: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 -> not installable
<Saviq> pitti, yeah, I know, working on it
<pitti> ok
<Saviq> it's blocked by http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api
<Saviq> which is why I was asking for a re-run there
<pitti> Saviq: queued
<Saviq> thanks
<rbasak> pitti: looks like it needs a deep dive. I'm not sure that's within our remit. jgrimm, please can you advise? MySQL dep8 is flaky on ppc64el only.
<Saviq> pitti, I think we need to push http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api through - without it http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-shell doesn't build and so unity8 is uninstallable... and we're going in circles
<pitti> Saviq: builds happen against -proposed, so I don't understand how that would help?
<pitti> https://launchpadlibrarian.net/260775998/buildlog_ubuntu-yakkety-amd64.unity-scopes-shell_0.5.7+16.04.20160505-0ubuntu2_BUILDING.txt.gz FTBFS on some C++ errors
<Saviq> pitti, oh you're right, I thought it was waiting for unity-scopes-api (it was on Friday) - now it just FTBFS, and we've a fix cooking there
<seb128> grar
<Saviq> pitti, ok, then we should be back in business soon
<seb128> Trevinho, Laney, upstart from yakkety release is also missing a s390x build (unsure how that happened) so deleting the proposed version didn't help :-/
<Trevinho> ouch
<Trevinho> so, going for new silo?
<pitti> seb128: I think xnox already removed the s390x binaries before, so that we stop blocking on s390x ftbfs
<ricotz> seb128, ah, I guess the libreoffice xenial-i386 build would just need a retry
<seb128> ricotz, hum, unsure who cancelled it/why ... thanks for pointing out, I just retried
<ricotz> https://launchpad.net/ubuntu/+source/libreoffice/1:5.1.3-0ubuntu1/+build/9771317
<ricotz> seb128, I mentioned in #launchpad last week
<ricotz> the builder was stuck
<seb128> pitti, that doesn't help; unity buil-dep on libupstart-dev which doesn't exist at all
<seb128> so the build depwait
<pitti> seb128: ah, so we need to remove the s390x binaries of unity as well? (I'm surprised that didn't already happen)
<seb128> pitti, I guess so, but then we need to remove any unity rdepends binaries as well?
<pitti> right
<seb128> not sure I want to go this road
<ricotz> Mirv, hi, please note the *versioned* breaks of qtchooser against libqtcore4
<pitti> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt seems unhappy
<pitti> apw: about "trying: linux" -- supposedly we need to remove all those transitional packages now?
<apw> pitti, looking
<seb128> Trevinho, I would force land with the missing build if it's possible, ask on -ci-eng
<seb128> it's going to be stucked in yakkety-proposed but that's fine
<seb128> somebody is eventually going to resolve the upstart/s390x issue
<pitti> most likely not
<pitti> it was removed from s390x quite deliberately
<seb128> hum
<pitti> so I think removing unity7 on s390x is the right solution
<Trevinho> I guess there's no objection to that at all
<pitti> in yakkety-release, so that an FTBFS on s390x doesn't block any more
<seb128> ok, let's do that
<pitti> xnox, slangasek: hmm, so if I have a /usr/share/upstart/sessions/{bamfdaemon,hud}.override containing just "manual", shouldn't that prevent the corresponding *.conf from starting? they still auto-start
<seb128> but in any case it means we can land to silo to proposed
<seb128> unity s390x is not going to build
<pitti> yes, that's independent
<seb128> Trevinho, can you ask about that?
<Trevinho> seb128: about force landing?
<seb128> yes
<pitti> seb128: want me to remove unity7 on s390x, or are you on it already?
<pitti> i. e. the binaries from the "unity" source, right? (not unity8)
<seb128> pitti, I'm doing it
<pitti> ack
<seb128> done
<apw> pitti, ok, so i assume we removed the lts kernels from yakkety sometime recently
<pitti> apw: they have never been in x or y; I thought these binaries came from linux-meta and were just for upgrades from e. g. 14.04.3
 * apw wonders if that makes any sense, no it doesn't
<pitti> apw: but linux-meta in y should drop all these -wily etc. transitionals
<pitti> maybe it did, and they became NBS and uninstallable now?
<apw> pitti, right they should be being removed, but as yet we're still cpopying forward
<pitti> apw: hm, but they should still be installable, they just depend on the "normal" image/tool in y
<apw> pitti, but no they haven't been removed yet, because we're copying forward, and ^ that as you say
<pitti> apw: oh, red herring
<apw> so i don't think that can be what it is ocmplaining about
<pitti> apw: linux-image-generic itself is also uninstallable
<apw> pitti, is it?  isn't that just britney working out that linux needs linux-meta too ?
<apw> pitti, doesn't the second and third (?) sets just saying we need a debian-installer for this to migrate ?
<pitti> apw: that could be it; I tried in a schroot and it is installable
<apw> pitti, the first attempet looks like linux alone, which never works
<apw> i'll go check d-i
<pitti> so let's blame the missing d-i rebuild
<apw> and make one
<Mirv> ricotz: right, good point, so it should be -7 or higher
<ricotz> Mirv, I have commented on the bug
<Mirv> ricotz: thanks!
<ricotz> this breaks the world ;)
<slangasek> seb128: sure; so while we're at it, why was upstart built again on s390x, I'm pretty sure I removed stale binaries once already this cycle...
<slangasek> pitti: yes, my understanding is 'manual' should prevent an autostart :/
<seb128> slangasek, if it shouldn't build it should probably be removed from the arch list? otherwise it looks like it was an error and people try to fix it?
<Mirv> ricotz: 4.8.7+dfsg-7ubuntu1 uploaded now, but I can't follow up to see how it goes before tomorrow
<ricotz> Mirv, thanks
<pitti> slangasek: ok, thanks; the manpage seems pretty clear about it, but it doesn't actually prevent the job from starting
<Saviq> pitti, ok, unity8 should be installable again according to rmadison, could you queue the unity8 run with --all-proposed again (although apt in a container here still doesn't see the required unity-plugin-scopes package)
<pitti> Saviq: done
<stgraber> pitti: yeah, CPC did that weird thing where they removed the images we said we may be able to remove this cycle before doing the needed work for us to be able to use the new format...
<stgraber> pitti: so we're effectively stuck without working devel images and with failing lxc tests again...
<stgraber> pitti: FYI https://bugs.launchpad.net/cloud-images/+bug/1577922
<ubottu> Launchpad bug 1577922 in simplestreams "Please add a combined_squashfs_sha256 field for LXD consumption of the squashfs images" [Undecided,New]
<Odd_Bloke> stgraber: I'm pretty sure we all agreed to removing the images, and _also_ all agreed that we would remove them and people would fix things on their side.
<stgraber> Odd_Bloke: I know I agreed with the former, the latter, I was under the impression would be done after it would actually be possible for folks to migrate to the new format, which it's not until you do the stream change we need
<stgraber> Odd_Bloke: anyway, hopefully the change can go live soon and then I can start actually landing the needed change and then do another round of SRUs since this change missed the window for 2.0.1 (released last week). So it'll be another couple of months before people can use yakkety on xenial which is why I'm not super happy about it.
<stgraber> Odd_Bloke: the initial ETA for the change (early May) would have worked, it getting moved to June screwed things up by making it miss our .1 bugfix releases, making it a .2 thing and so delaying the fix by a month and a half or so for our stable users
<Odd_Bloke> stgraber: Understood, and that sucks; the changes required to the build system ended up being more complex than we were expecting.
<Odd_Bloke> combined_sha256 should now be being produced for yakkety, but I see that it isn't currently; we'll dig into that and get that fixed.
<hallyn> sladen: hey, https://wiki.ubuntu.com/apt-sync was filed in 2006, just curious, whatever happened with that?
<hallyn> it sounds sweet :)
<hallyn> would love for my apt-cache server to use that in the background
<pitti> stgraber: thanks for the pointer
<pitti> stgraber: could the tests use the images.linuxcontainers.org images for the time being? or would that be too much work?
<pitti> stgraber: this is mostly just FYI; I just don't like having a force-badtest for lxc for an extended period of time, as it's very useful to detect regressions from new kernels and such
<stgraber> pitti: the test already uses images.linuxcontainers.org for a bunch of images, the particular failing test is very specifically testing the ubuntu-cloud template
<pitti> stgraber: oh, right
<pitti> stgraber: so maybe an appropriate step for now would be to disable that test in yakkety?
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<rbasak> We need one more for quorum.
<elbrus> what does it take to end up on http://people.canonical.com/~ubuntu-archive/pending-sru.html
 * elbrus expected cacti and cacti-spine there
<pitti> elbrus: it's still in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1, i. e. hasn't been reviewed by the SRU team yet
<elbrus> pitti: ok
<elbrus> pitti: but what does "pending SRU" mean than?
<pitti> elbrus: SRUs which got reviewed/accepted by the SRU team and are actually in *-proposed, and being tested
<elbrus> ah, ok
<pitti> once they get verified and moved to *-updates, they disappear from the page again
<elbrus> pitti: at least you verified by your URL that the packages are on the SRU radar, which is really what I was interested in
<pitti> right
<juliank> What's up with the sbuild and apport regressions in xenial with apt 1.2.12? e.g. 'E: Unable to find a source package for procenv' for sbuild
<juliank> hmm, does not seem to be apt related
<Saviq> slangasek, infinity, I believe you guys have access to snakefruit, would you please queue a --all-proposed britney run of unity8 https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests thanks
<mwhudson> tianon: hi, did you talk to anyone about containerd / runc yet?
<slangasek> Saviq: looking at the excuses, it doesn't appear that will unblock anything given that unity8-common has an unsatisfiable depends on amd64
<slangasek> (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8)
<Saviq> slangasek, that's solved by now
<slangasek> Saviq: oh, sorry, refreshing
<Saviq> slangasek, I've just checked in a container here and I can `apt install unity8` with yakkety-proposed fine
<slangasek> Saviq: right; I'm trying a more narrow trigger first, but will watch for results and retry with --all-proposed if necessary
<Saviq> slangasek, I can tell you a normal trigger will fail
<Saviq> slangasek, because we've a unity-api released that's too new for the released unity8 (yes, we need to think about our Depends there)
<slangasek> Saviq: my "normal" trigger has about a half dozen --trigger options passed to it in order to test the packages all at once
<Saviq> acl
<Saviq> ack, even
<slangasek> I may have missed some, in which case yes I'll give up and use --all-proposed ;)
<clivejo> can anyone help me with a "stack smashing detected" crash and how to find out if its being caused by AppArmor?
<jtaylor> clivejo: its a compiler added check
<jtaylor> it usually means a buffer overflow
<jtaylor> or probably always
<jtaylor> clivejo: run with valgrind it is likely to tell you where
<clivejo> so its not AppArmor causing it?
<jtaylor> no
<sarnold> clivejo: it'd be a very strange program if an AppArmor denial caused this
<sarnold> it'd still be a bug in the program of course :)
<clivejo> how do I get a decent bt with these new ddeb files?
#ubuntu-devel 2016-05-24
<mwhudson> do removals from debian get synced/tracked in ubuntu somehow?
<nacc> mwhudson: do you mean do they get automremoved from ubuntu?
<nacc> *autoremoved
<mwhudson> nacc: yeah, or listed on some "packages no longer in debian" page
<nacc> mwhudson: well, i know publishinghistory is aware of when a package gets deleted, but looking at the notes, it's not automatic, it is requested by someone
<nacc> mwhudson: i'm not sure if there an existent source of packages in ubuntu but not in debian ... seems like there would be :)
<mwhudson> nacc: ah https://wiki.ubuntu.com/ArchiveAdministration#Removals_in_Debian
<jbicha> nacc: see also https://launchpad.net/ubuntu/yakkety and click the only in Stretch and only in Yakkety links
<nacc> jbicha: ah thanks!
 * mwhudson is confused: https://launchpad.net/ubuntu/+source/dh-golang shows 1.17ubuntu1 as published in yakkety
<mwhudson> but https://launchpad.net/ubuntu/+source/golang-github-rakyll-statik/0.1.0-2/+build/9641641 uses 1.17 (and failed as a resutl)
<Mirv> hi! could an autopkgtest magician mass restart at least http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src now that updated qt4-x11 is also in archives? this is fallout from qtchooser autosyncing from Debian, which moved files from qt4-x11 and qtbase to qtchooser, breaking the world..
<Mirv> restart the failed ones, that is
<Mirv> usually ^ for such I'd ask pitti at this hour, but I gave others a chance :)
<Mirv> I guess I could for the next time start collecting restart urls from the page source and just giving them all to firefox in one go. that'd be poor man's mass restart.
<Mirv> pitti: it'd need to be maybe --all-proposed too so it would consider both new qt4-x11 and qtbase-opensource-src?
<Mirv> I'm not sure how to interpret all of the errors
<Mirv> oh and consider the new qtchooser too. not having all three together causes problems.
<pitti> Good morning
<pitti> Mirv: yep, will do
<Saviq> pitti, good morning - unity8 itself is happy now http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 - there's a bunch of other pkgs waiting on u8, too, so an --all-proposed for unity8 might be in order - the remaining Regressions for unity8 at least are due to what Mirv described above, so if you kick those off we should be in a more-or-less working order
<pitti> Saviq: I did a mass-retry of related packages 30 mins ago, see backscroll and requests from Mirv
<pitti> http://autopkgtest.ubuntu.com/running.shtml is churning :)
<Saviq> pitti, ack, wasn't sure how broad the mass retry was - thanks!
<ginggs> Logan: thanks, i have tried again
<pitti> Saviq: news on http://autopkgtest.ubuntu.com/ look pleasantly green :)
<Saviq> w00t
<Mirv> green is good
 * Mirv likes green
 * pitti too!
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<pitti> slangasek, xnox: I filed bug 1585087 about it; I can probably do without (we can drop the upstart job from a package once we add a systemd unit), this is mostly just less convenient for experiments
<ubottu> bug 1585087 in upstart (Ubuntu) "*.override files do not work for session jobs" [Undecided,New] https://launchpad.net/bugs/1585087
<seb128> dholbach, hey, didn't you already pilot yesterday? ;-)
<dholbach> seb128, I started, but then a bunch of other things got in between
 * seb128 hugs dholbach
<seb128> I plan to do a shift as well this week ;-)
<dholbach> and it looks like it will be similar today :)
<dholbach> so I guess I'll do my shift piecemeal :)
<tsdgeos> is it a known bug that grub-mount takes ages on "complicated laptops"?
<tsdgeos> takes like 15 min to run each time in my netbook with lots of partitions
<pitti> slangasek, xnox: argh, got it; bamfdaemon also has a weird d-bus activationâ upstart redirection thing; bug updated/invalidated, unping, all good
<dholbach> LocutusOfBorg, looks like https://launchpad.net/ubuntu/+source/python-tornado/4.3.0-1ubuntu1 ftbfs on some archers
<dholbach> arches
<LocutusOfBorg> dholbach, I already have a patch
<LocutusOfBorg> I got the email, I'm testing a patch right now
<LocutusOfBorg> let me see
<LocutusOfBorg> how do you feel about the new debdiff on the bug?
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> FWIW it works
<LocutusOfBorg> dholbach, hold on
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<halvors> Hi. May the strongswan package for yakkety please be updated to version 5.4.0 which is now available?
<halvors> Anyone knows if 16.10 will default to systemd-networkd instead of ifupdown?
<pitti> halvors: we plan to do that on servers/cloud images, yes; desktop will continue to use NetworkManager
<halvors> pitti: Nice :D
<halvors> pitti: NetworkManager is not ifupdown as far as i know. I just think that systemd-networkd is a much better and more updated candidate than ifupdown.
<halvors> May the strongswan package for yakkety please be updated to version 5.4.0 which is now available?
<halvors> May it be possible to update the strongswan package for Ubuntu 16.04 as well?
<pitti> stgraber, Laney: I adjusted the session dbus.upstart to not scribble over an already existing bus from dbus-user-session: http://paste.ubuntu.com/16653578/
<pitti> stgraber, Laney: this now works with both current ubuntu (session bus) and user bus; it looks quite complicated, but now that I fought with upstart's handling of the environment I understand why the structure is that way :)
<pitti> stgraber, Laney: does that look resonable to you?
<pitti> maybe there's a better way than the "sleep infinity" dummy process
<Laney> is this for "start on started dbus" things?
<pitti> Laney: right
<pitti> if I just exit, there's no more proces and dbus would be stopped
<Laney> mmm
<pitti> and a "sleep 1" isn't enough due to "stop on stopping dbus"
<Laney> can't think of a way around that
<pitti> "task" would also not work as then starting would block forever
<Laney> do you need the DBUS_SESSION_BUS_ADDRESS stuff with user-session?
<pitti> Laney: we need  to tell the upstart --user instance about this variable
<pitti> Laney: well, in theory we could drop that, yes, as it shoudl already be in the env anyway, but I'd rather not break that
<Laney> I thought it was well known in this case
<pitti> Laney: yes, libdbus ought to fall back to $XDG_RUNTIME_DIR/bus; I haven't checked if that's the case, hang on
<pitti> ah yes, that actually works with libdbus
<pitti> but there's other implementations like gdbus or dbus-python, and I don't want to be that they all do this already
<pitti> Laney: in the end this is only for a transitional time -- we want to drop session upstart after everything got ported :)
<Laney> gdbus definitely does this
<pitti> Laney: with that my prototype for launching bamfdaemon and Xeyes works nicely
<Laney> but fine
<pitti> Laney: I'm fine with dropping the parts too, if you prefer that
<pitti> but I think we do need to keep the initctl notify-dbus-address, for talking to upstart itself
<Laney> with systemd we won't be doing this stuff
<Laney> so might shake out some things
<pitti> Laney: we actually do
<pitti>   dbus-update-activation-environment --verbose --systemd \
<pitti>     DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY
<Laney> huh!
<Laney> then we should
<pitti> I don't think this actually needs DBUS_SESSION_BUS_ADDRESS, but it does need $DISPLAY and $XAUTHORITY
<pitti> not sure why Simon put it there, but I trust he knows what he's doing
<Laney> maybe it's needed for old implementations
<Laney> like possibly dbus-glib
<pitti> Laney: so I now have bamfdaemon started from systemd, everything else from upstart, and stuff talks to each other
<pitti> and it goes up and down with the session
<pitti> having two different dbuses broke pretty well everything before
<Laney> cool
<Laney> so ship it IMHO
<pitti> Laney: I currently have the bits in a separate systemd-graphical-session.deb (mostly for experimentation)
<pitti> Laney: can you think of an appropriate existing place to put those?
<pitti> it's an Xsession.d script, two /usr/lib/systemd/user/* files, an upstart job, and a little shell script which I hope I can eliminate
<pitti> ubuntu-session would not be the worst place, but we want this for other flavors too
<pitti> so maybe just put it into dbus-user-session?
<Laney> pitti: Will it be upstream?
<pitti> Laney: too early to say
<pitti> Laney: I think I'll actually put the upstart job into the upstart package
<pitti> which then leaves the Xsession.d script and the "umbrella" units
<pitti> which could go into systemd too, but that makes it harder to opt out and uninstall/change while we develop this
<Laney> Do something like /etc/upstart-xsessions ?
<pitti> Laney: I really don't like this file
<pitti> it makes very little sense
<Laney> I mean a file which lets you opt in
<pitti> I mean in the systemd --user context
<Laney> could be ~/give-me-a-systemd-user-session
<Laney> seems like it's that or make a separate deb to install
<pitti> Laney: if we have a flag file, then we can't transition packages one by one
<pitti> Laney: and it's a lot of runtime effort to dynamically disable/enable upstart jobs on the fly
<pitti> Laney: my idea was to take a package, add a systemd unit, remove the upstart unit (or ship a "manual" override)
<pitti> Laney: otherwise the upstart unit would need to check if the corresponding systemd unit is running
<pitti> which is doable, but expensive and requires changing the existing jobs
<Laney> pitti: Then I'm not sure what you're asking with opt-out, sorry
<Laney> I thought you'd add something to XDG_DATA_DIRS that enables these override upstart jobs
<pitti> Laney: hm, neither am I now, sorry
<pitti> Laney: ah, that's actually a nice idea
<Laney> that's what they do with switching between xdg autostart and upstart jobs atm
<pitti> Laney: so with that, we'd do one round of porting, and then anohter round of uploading the packages  again to drop the overrides, upstart jobs, etc?
<pitti> about three times the amount of work, but easier to revert
<Laney> Well
<Laney> You can just make the override unconditional when we want to enable it for everyone
<Laney> Then it becomes cruft, but not critical to upload everything
<pitti> *nod*
<pitti> Laney: ok, that sounds good, I'll look into that (XDG_DATA_DIRS)
<Laney> pitti: Looks like it's actually XDG_CONFIG_DIRS for upstart, looking at init(5)
<LocutusOfBorg> seb128, mind if I merge hexchat?
<seb128> LocutusOfBorg, please  do :-)
<seb128> thanks!
<LocutusOfBorg> can you please comment the two commits? https://anonscm.debian.org/cgit/collab-maint/hexchat.git/commit/?id=cd9bd1da61b0248e4a3ec49fe4b987546dac74ec
<LocutusOfBorg> https://anonscm.debian.org/cgit/collab-maint/hexchat.git/commit/?id=75cbe4e74146d1db4051c337a5362ac21f471516
<LocutusOfBorg> they are fine, right?
<seb128> I've no idea about that
<LocutusOfBorg> "Ubuntu server must be chat.freenode.net not irc.ubuntu.com because of hostname verification"
<seb128> dunno about hostname verification
<LocutusOfBorg> seems good
<seb128> what's the issue with using the ubuntu alias?
<seb128> what is verifying what?
<LocutusOfBorg> not sure, maybe when people connects to irc using certificates?
<LocutusOfBorg> BTW debian committing ubuntu-specific stuff
<LocutusOfBorg> that patch is not used on Debian
<cjwatson> seb128,LocutusOfBorg: "openssl s_client -connect irc.ubuntu.com:7000" shows a certificate for *.freenode.net, so using chat.freenode.net indeed seems more correct if hexchat might be connecting over SSL
<LocutusOfBorg> <3 cjwatson
<seb128> cjwatson, thanks
<LocutusOfBorg> you rock, as always
<Saviq> pitti, can you restart http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-shell with --all-proposed - that would, I believe, unblock unity8 and a lot of things would look better
<Saviq> pitti, basically, any unity8 test in yakkety that isn't 8.12+16.04.20160518.1-0ubuntu1 could be triggered, would make things look much nicer
<LocutusOfBorg> seb128, I don't like the merge
<LocutusOfBorg> the pkconfig file is now in hexchat-plugins
<LocutusOfBorg> so, leave it in hexchat-plugins, and add breaks+replaces?
<LocutusOfBorg> and patch hexchat gnome to depend on it
<seb128> LocutusOfBorg, I guess so...
<LocutusOfBorg> there is already the breaks+replaces, because the split was done in debian too
<LocutusOfBorg> the only remaining change is the service file
<LocutusOfBorg> in case xchat-gnome breaks, can you please fix? :)
 * LocutusOfBorg isn't core-dev
<seb128> LocutusOfBorg, what needs fixing?
<LocutusOfBorg>     - install files missing since the split, include pkgconfig needed
<LocutusOfBorg>       to build xchat-gnome
<LocutusOfBorg> this is from you
<LocutusOfBorg> so I guess something will break now that the files are in another package
<seb128> ah, right, the indicator needs to build-depends on the right one
<LocutusOfBorg> that one yeah
<LocutusOfBorg> :)
<seb128> I can fix that yes
<LocutusOfBorg> thanks
<LocutusOfBorg> I uploaded, can you please point me to that indicator?
<LocutusOfBorg> I fail to find it
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/hexchat-indicator
<LocutusOfBorg> seems empty
<seb128> LocutusOfBorg, you need to bump the R/B versions
<seb128> Replaces: hexchat (<< 2.10.2-1)
<seb128> but xenial has 2.10.2-1ubuntu3
<seb128> which is > to that
<seb128> so it's not going to work
<pitti> Saviq: I already restarted them twice with --all-proposed, yesterday afternoon and this morning; has anything changed again?
<seb128> LocutusOfBorg, https://launchpad.net/distros/ubuntu/+source/xchat-indicator
<Saviq> pitti, oh hmm, /me looking into it
<LocutusOfBorg> seb128, xchat-indicator is universe
<Saviq> pitti, ah, flaky test on amd64, dammit (got a fix upcoming in a silo)
<LocutusOfBorg> I can do it
<seb128> LocutusOfBorg, thanks
<seb128> LocutusOfBorg, saw the comment about the version?
<LocutusOfBorg> yes, but I dont get it completely
<LocutusOfBorg> we need to break a version "before" the split
<LocutusOfBorg> isn't it fine?
<Saviq> pitti, so if you could run again for amd64, sorry about that :/
<seb128> LocutusOfBorg, no, we need the first version after the split
<seb128> LocutusOfBorg, because Replaces: hexchat (<< 2.10.2-1)
<seb128> but you are on xenial and have 2.10.2-1ubuntu3
<seb128> and install hexchat-plugins from y
<seb128> the Replaces is not going to work
<seb128> because it replaces only versions older than -1
<seb128> and ours is newer than that
<pitti> Saviq: it failed on qtdeclarative-opensource-src, qtdeclarative-opensource-src-gles, qtmir, systemd, and ubuntu-system-settings as well, though, always on amd64
<pitti> Saviq: so if that's so hard to hit and takes ten retries or so, maybe it's easier to force-badtest this version on amd64
<pitti> then the next unity8 upload still has to succeed
<LocutusOfBorg> I'm uploading
<pitti> Saviq: hinted now
<Saviq> pitti, works for me, I suppose it failed on all others because it was actually the same test run?
<pitti> Saviq: ah right, good point
<tedg> Seems like the Upstart build on s390x in the Y archive is hung: https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu23/+build/9668581
<pitti> tedg: yes, known-broken; we removed the binaries on y-release so that the s390x FTBFS doesn't block
<tedg> pitti: Did you remove things like UAL binaries as well? The silo is giving me a dep wait.
<pitti> tedg: I think seb128 removed upstart from s390x, but presumably not the rdepends yet
<pitti> tedg: yeah, depwait/ftbfs is the expected result now on anything upstart-ish on s390x
<tedg> Okay, cool. /me slashes his dreams of an s390x based phone
<seb128> no, I just removed the unity ones
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<rbasak> slangasek: any news on reviewing https://github.com/ltangvald/mysql-5.7/commit/fa6ea0346929584373aee3b373cba0751fb81830 for me please?
<caribou> what is the cleanest way to remove a (non-conffile) file that has moved to another package ?
<caribou> I'm removing /etc/default/grub.d/kexec-tools.cfg and moving it to kdump-tools as /etc/default/grub.d/kdump-tools.cfg
<caribou> so I want the former to be removed when the new kexec-tools package will install
<GunnarHj> dholbach: Thanks for helping with bug #1584314! Actually there is a libx11 task too, but for now I'd ask you to unsubscribe ubuntu-sponsors, because we aren't sure yet if that fix is sufficient.
<ubottu> bug 1584314 in libx11 (Ubuntu) "Please merge xkeyboard-config 2.17-1 (main) from Debian unstable" [Wishlist,In progress] https://launchpad.net/bugs/1584314
<caribou> control file has the needed Depends/Conflicts so the new kexec-tools is installed upon install of kdump-tools but that file is left behind
<rbasak> caribou: given that it's not a conffile, could the new kdump-tools Break on older kexec-tools (any version that expects to own the file) and in postinst, if kexec-tools.cfg exists, then rename it?
<rbasak> I'm not sure if that's clean in every way though. I think it covers the "must not mess with users' local modifications" rule.
<rbasak> It might break on purge edge cases.
<dholbach> GunnarHj, oh... I'm afraid I uploaded it already
<dholbach> https://launchpad.net/ubuntu/+source/libx11/2:1.6.3-1ubuntu3
<GunnarHj> dholbach: Ok, thanks, it won't hurt... Then I know.
<dholbach> ok
<Bluefoxicy> ctrl-alt-delete logs out in gnome wtf???????
<Bluefoxicy> instead of locking the screen lol
<rbasak> Bluefoxicy: try #ubuntu-gnome or #ubuntu-desktop.
<pitti> Laney: that works rather well indeed
<Laney> pitti: great
<pitti> https://git.launchpad.net/~pitti/+git/systemd-graphical-session FYI
* verne.freenode.net changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mdeslaur> infinity, kees, slangasek, stgraber: tech board meeting in...7 minutes?
<kenvandine> @pilot out
<seb128> wooot, kenvandine piloting :-)
<kenvandine> a bit :)
<seb128> every bit counts ;-)
<tianon> mwhudson: beyond the email Jon sent that I believe you were on CC for, nope
<jgrimm> infinity, slangasek: did you have any opinions on email I sent (on behalf of tianon) about runc/containerd packaging & go dependencies?
<jgrimm> hey there tianon
<slangasek> jgrimm: I haven't formed an opinion yet; infinity is off sick
<jgrimm> slangasek, gotcha.  ok, sort of in holding pattern on direction to get docker updated to 1.11
<elbrus> pitti: thanks for processing cacti-spine, but interestingly, one can only use it on a fresh install when also cacti is accepted
<pitti> elbrus: will get to that too
<pitti> elbrus: thanks for the poke,  it was in a batch of similar SRUs wich can't be accepted yet
 * elbrus expected that (but it looks slightly weird in the bug)
<pitti> There are no Launchpad bugs in the changelog!
<pitti> elbrus: ^ hmm
<pitti> elbrus: seems you built that http://launchpadlibrarian.net/260694162/cacti_0.8.8f+ds1-4ubuntu4.16.04_source.changes with a very old (or Debian) dpkg-source :)
<elbrus> pitti: indeed, I run Debian
 * elbrus is DD
<pitti> elbrus: right, I know, but I forgot that the Lauchpad-Bugs-Fixed: header was still only in ubuntu
<elbrus> that's why; eat your own dogfood
<elbrus> to make it worse still on Jessie...
<pitti> elbrus: I'll reject that, rebuild the source, and reupload, so don't get scared of the REJECTED/ACCEPTED pair
<elbrus> pitti: ack
<rbasak> elbrus: should the cacti-spine SRU have a Breaks on older cacti if it needs a newer cacti?
<elbrus> rbasak: it doesn't break anything
<elbrus> as cacti can't install, cacti-spine can't install
<rbasak> Ah, OK
<elbrus> if you installed cacti before, you are fine
<elbrus> so you just can't install cacti/cacti-spine in xenial right now
<elbrus> upgrades from before with the fixed cacti-spine would work
<rbasak> I see, thanks. I haven't really been following the details of the bug. I've been trusting you with that (since you maintain both in Debian) and not really looking at the details, only the Ubuntu process.
<elbrus> rbasak: and thanks for that... some of those details I wasn't 100% sure of...
<elbrus> I mean, Ubuntu process details
<rbasak> elbrus: np. And thank _you_ for looking after Ubuntu!
 * elbrus goes to bed now.
<rbasak> Serving on the DMB has given me a new viewpoint. When we grant someone upload access, really it's the applicant doing _us_ a favour by uploading, not the other way round :)
<elbrus> ;)
<pitti> rbasak++
<pitti> rbasak: I echo that from a sponsoring POV :)
<nacc> is it just me, or in a systemd-only world, does memcached's /etc/init.d/memcached not make sense?
<nacc> in particular the example provided in the same file, which doesn't work
<nacc> given systemd, would it make sense to either update the comments in that init-script (as part of an SRU?) ... or just not ship it at all? there's a memcached.service file already
<pitti> nacc: didn't look, but the init.d script is irrelevant if the package has an explicit .service
<nacc> pitti: ack, that's what it seems like to me
<nacc> pitti: would we have kept it since users can install upstart-sysv (in 16.04) -- is it relevant to upstart, i guess i mean?
<nacc> pitti: the issue is we had an actual user try to use it as per the init-script (since it's int eh package) and it just doesn't work they way it's describe
<pitti> nacc: possibly, yes
<nacc> pitti: ok, i'll test and play with it, i guess, to see if i can see if it's relevant ata ll
<nacc> it might just need clarity that it only applies to upstart
<pitti> nacc: right, we have some LSB diversions in place to redirect "/etc/init.d/foo op" to "systemctl op foo"
<robert_ancell> pitti, could you remove boomaga 0.7.1-1ubuntu1 from yakkety-proposed? That should have been a 0.7.1-1build4
<pitti> robert_ancell: I'm not entirely sure whether you can go back with version numbers
<nacc> pitti: ah ok, that would make sense; thanks for the insight!
<robert_ancell> pitti, damn, I was wondering that too
<nacc> i think once it's in proposed, it has to go up
<nacc> once "published"
<nacc> based upon reading lots of publishinghistory lately :)
<pitti> robert_ancell: well, we can try, but it might confuse things; wgrant, up by any chance?
<robert_ancell> They're marked as "Accepted" - does that mean it's published?
<pitti> uploads get auto-accepted in y; publisher then happens afterwards, i. e. they get published right now
<pitti> but the publisher shouldn't be a problem even
<pitti> robert_ancell: TBH, if I were you I'd just reupload an -1+build4
<robert_ancell> pitti, oh, that will work?
<pitti> $ dpkg --compare-versions 1-1ubuntu1 lt 1-1+build4 && echo yes
<pitti> yes
<pitti> i. e. + > z
<robert_ancell> ok, I'll do that
<robert_ancell> thanks
<wgrant> pitti: Hi
#ubuntu-devel 2016-05-25
<mikodo> I am hearing of much activity happening with development of unity8. Rightly or wrongly, that is what I heard. How can I restate my desire to see this become a priority in unity8: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400580
<ubottu> Launchpad bug 1400580 in unity8 (Ubuntu) " Color Inverse on display. Toggle Negative Image" [Wishlist,Triaged]
<mikodo> Even hearing that it looks like unity8 session has gone from being a pre-view to being the intended Xserver Ubuntu replacement. Is is time to build in replacement shading for Unity8 to replace X like my bug reads?\
<rbasak> mikodo: try #ubuntu-unity or #ubuntu-desktop
<mikodo> rbasak, Okay. Thank you.
<cpaelzer> good morning
<pitti> Good morning
<mwhudson> morning
<pitti> seb128: so you removed the whole upstart 1.13.2-0ubuntu24 from -proposed
<pitti> seb128: I thought just removing the binaries from s390x would suffice?
<Saviq> xnox, hey, could you help out with bug #1585517 - not sure what changed between vivid and xenial, but we can't cross-build unity8 any more
<ubottu> bug 1585517 in python-setuptools (Ubuntu) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517
<pitti> seb128: i. e. how did that proposed version blocked unity on the other arches? (I wonder what we need to "resolve" to be able to upload upstart again)
<seb128> pitti, yes, that was what Laney suggested doing at first/seemed right, but we overlooked that the yakkety version was also missing the s390x build
<seb128> sorry about that
<Saviq> xnox, I tried :any and :native on the unity8 B-Ds, but that didn't help (and actually broke vivid builds, too)
<pitti> seb128: ok, so if I'd upload upstart again, would I break anything?
<seb128> no
<pitti> seb128: no worries,  I'm just trying to understand what happened to avoid breakage
<seb128> pitti, I first though that release pocket was fine and proposed created the issue, that was a mistake/overlook
<seb128> so my bad for deleting it
<pitti> seb128: ok, understood; so all good then
<seb128> that was not needed/useful
<seb128> thanks for fixing!
<pitti> didn't hurt really
<pitti> I just have some cleanup to upload
<seb128> upload away :-)
<ricotz> hello, any action on updating usb-modeswitch which conflicts with latest systemd?
<pitti> ricotz: I already uploaded a fix
<pitti> to systemd, to drop the Breaks:; it's not necessary for Ubuntu
<ricotz> pitti, ah, thanks, will wait a bit longer then ;)
<Laney> mapreri: scribus appears in appstream now, by the way
<mapreri> Laney: nice!  Shall I assume I need to SRU it to have it work in xenial too?  (as I still see http://appstream.ubuntu.com/xenial/universe/issues/scribus.html )
<Laney> mapreri: indeed, that'll be needed to get it fixed there
<mapreri> ok
<Laney> might have the same re-processing problem too
<Laney> so if it gets an error the first time I'll have to trigger it after Contents gets updated
<mapreri> let's worry about it after the package is fixed there too.
<mapreri> hopefully i'll get around to it by the end of the week.
<Laney> nod
<Laney> thanks for tracking!
<seb128> is anyone having interest in util-linux / libblkid1?
<seb128> bug #1577768
<ubottu> bug 1577768 in util-linux (Ubuntu) "16.04 some dvd do not mount automatically (but do in 14.04)" [Undecided,Confirmed] https://launchpad.net/bugs/1577768
<seb128> happening in xenial, it makes the system not see e.g video dvds
<seb128> downgrading libblkid1 to the trusty version fixes it
<pitti> seb128: comparing "sudo LIBBLKID_DEBUG=all blkid -p /dev/sr0" with old and new lib and attaching that to the bug might help
<rbasak> Laney (or any other former DMB member): may I have your opinion on https://lists.ubuntu.com/archives/devel-permissions/2016-May/000927.html please?
<seb128> pitti, thanks, I'm trying to look at upstream report and git logs
<pitti> at least to get some tangible info for upstream
<seb128> pitti, rh has the same issue apparently so probably an upstream one
<pitti> yeah, we don't patch libblkid
<rbasak> pitti: bug 1585589 - Won't Fix?
<ubottu> bug 1585589 in init-system-helpers (Ubuntu) "init does leave no choice between upstart and systemd anymore" [Undecided,New] https://launchpad.net/bugs/1585589
<Laney> hey rbasak
<rbasak> o/
<Laney> I think that the best argument in favour of using packagesets is that you can delegate their management
<Laney> Creating the top-level objects (packagesets or PPU permissions) requires a TB member
<Laney> But once a packageset is created then the owner can alter it
<pitti> rbasak: I think I'll reassign to upstart to drop the upstart-sysv package; that was the plan anyway, but I wanted to leave some time between the steps to check for fallout
<rbasak> Laney: when you say requires a TB member, do you mean by policy (I shouldn't do it) or by technicality (I can't do it) or both?
<Laney> technically
<Laney> you can't give someone PPU
<pitti> rbasak: done
<rbasak> pitti: thanks. You mean the upstart bug right? Not a PPU ACL change? :)
<pitti> rbasak: yes
<Laney> And you can attach a textual description to a packageset, so you can leave future DMBs guidance
<rbasak> Can I alter a PPU set once it has been created for an uploader?
<Laney> You can alter a packageset which has a team you are in (or you) as its owner
<Laney> but you can't directly add upload rights to users
<rbasak> I see. So packagesets make it much easier for a DMB to action its own decisions.
<rbasak> And presumably I need to ask the TB to add or delete a packageset then, or to add or remove packages to users for PPU rights.
<Laney> launchpad treats these separately, there's archive_permission objects and packageset objects
<Laney> TB can manipulate the former
<Laney> And process-wise for you if you agree Gunnar's globs are okay for a packageset then it becomes trivial for him to request that it's extended in the future by looking at the description of the set
<Laney> I was in favour of making these kind of things as lightweight as possible
<rbasak> Laney: OK so you think a packageset for Gunnar is a good idea then? Would it include all language support then, including fonts-*? Or would we treat the globbing as in their own packagesets for convenience?
<rbasak> (I presume Launchpad can't have globs in ACLs so we'll expand them when updating)
<Laney> rbasak: I think it'll make it easier for you to track and administer in the future
<Laney> You need to expand the globs yourself
<rbasak> Laney: OK, so one packageset for all language support or one packageset per glob?
<Laney> rbasak: Hmm, I suppose you could go two ways
<Laney> You could break new ground and make a 'personal packageset' and just add Gunnar as the only uploader of that, then make its description be exactly what you voted to approve
<Laney> Or you could try to come up with a way of grouping these packages (in one or more sets) that makes logical sense
<Laney> 'spelling and fonts'? Not sure
<Laney> and im-config is a bit of an outlier in that group it seems to me
<Laney> I don't think there's anyone else who has as many PPU rights as Gunnar after this vote, so it's kind of novel actually
<Laney> I don't see anyone else coming along for this set of things, so I'd probably do him an individual one
<Laney> Question is where to document that you've done it that way
<rbasak> We can stick it in the wiki somewhere
<rbasak> If this were a personal packageset, would it have to be a new Launchpad team just for Gunnar, or could the ACL just point to Gunnar directly?
<Laney> I guess Gunnar will know and can remind you to do it this way next time
<Laney> Either, but probably the latter would be easiest
<Laney> It makes sense if you consider it an implementation detail of the PPU
<rbasak> Got it. Thank you for your help! I think I follow this now, and in particular I follow your reasoning too, which is useful.
<Laney> I would document this on here https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase
<Laney> "If a person has a large PPU ACL, do this"
<Laney> large and possibly frequently changing
<Laney> Make sure you give it a useful description including the globs
<rbasak> Can we change the description or does that require the TB?
<Laney> Not sure
<Laney> It'll come up here http://people.canonical.com/~ubuntu-archive/packagesets/ after it's created
<Laney> So you'll go to http://people.canonical.com/~ubuntu-archive/packagesets/yakkety/gunnarhj, read the description, see that his request matches and then go ahead and execute it without needing a vote
<Laney> (That part is the same for all packageset changes actually)
<rbasak> OK
<rbasak> pitti: does my answer in bug 1585375 seem reasonable to you? Is there a case for turning dh_installinit into a noop on Ubuntu if systemd units are shipped?
<ubottu> bug 1585375 in memcached (Ubuntu) "memcached init script deprecated" [Undecided,Invalid] https://launchpad.net/bugs/1585375
<rbasak> nacc: FYI ^
<doko> seb128, Laney: is sweetshark available? would need a LO build to build with new libs, probably merging the debian 5.1.3-1 package
<seb128> doko, he's busy with snappy work I think, unsure if he has slots for that atm... check with him on #ubuntu-desktop?
<infinity> pitti: Your rationale in LP: #1585589 is curious.  You can't actually break Touch any more than you already have. ;)
<ubottu> Launchpad bug 1585589 in upstart (Ubuntu) "drop upstart-sysv" [Medium,Triaged] https://launchpad.net/bugs/1585589
<infinity> pitti: (ie: touch is already uinstallable and unbuildable due to the init change)
<pitti> infinity: in terms of reverting stuff it's true
<infinity> pitti: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu-touch
<pitti> infinity: so I guess it's really time to change the touch seeds to systemd-sysv?
<pitti> Laney: ^
<Laney> I pinged sil2100 about that earlier
<Laney> but you might want to JFDI
<infinity> pitti: Revert the init change or force touch to systemd, but there's no in between.
<pitti> ok, doing the seed change then
<pitti> emulator and n4 at least booted with systemd, and calls/text messages/wifi/3G mobile network/unity were working
<pitti> and we do want to keep stuff buildable at lesat
<pitti> Laney, slangasek, infinity: FYI, I temporarily disabled s390x in snakefruit:proposed-migration/code/b1/ (see bzr diff); s390x boxes have been AWOL since yesterday and xnox isn't here to resussitate them
<pitti> Laney, slangasek, infinity: I'll be off tomorrow and Friday, so please bzr revert that delta once they come back
<pitti> (or let me do that on Monday)
<infinity> pitti: Does only xnox have console access to them?
<pitti> infinity: not sure who else, but last time I sent an RT it turned out that "xnox is the man"
<pitti> i. e. IS didn't really know where this lived and how to access it
<infinity> pitti: Yeah, I'd expect tinoco to be able to tell you how to mangle them.
<infinity> tinoco: ^
<pitti> infinity: I don't have access myself, we already tried
<pitti> i. e. xnox was telling the magic commands, but EPERM for me (even through vpn)
<infinity> pitti: Lacking VPN access, or lacking the right passwords?
<pitti> he did give me the passwords (back then), but firewall was blocking me out
<pitti> s/out//
<infinity> pitti: I'm positive I have the right network access, but have no idea what the specifics of your LPARs/VMs are.
<tinoco> pitti: hey
<pitti> hey tinoco, how are you?
<tinoco> pitti: what is the machine you're talking about ? DEVACXX ?
<pitti> tinoco: AUPKG01 and AUPKG02 (10.100.0.12 and 10.100.0.13)
<tinoco> ok
<tinoco> i thought they came back in yesterday
<tinoco> at least they should have had
<tinoco> let me check
<pitti> tinoco: mtr stops at em1.rapid.canonical.com, but that might also be our firewall blocking icmp
<tinoco> pitti: hum.. but the OS is up and running ?
<pitti> tinoco: I don't know
<tinoco> ah ok
<tinoco> i thought it was from it you mentioned
<pitti> tinoco: ssh says "no route to host" and I don't have any other access
<tinoco> checking
<tinoco> we changed network paths of this one
<pitti> tinoco: and it's also nto processing autopkgtest requests, so I suppose it crashed
<pitti> or someone shut htem down
<tinoco> yep, checking
<pitti> tinoco: cheers
<tinoco> aupkg01 is back on
<tinoco> lets see if you can reach it
<pitti> tinoco: I can, thanks
<tinoco> ok getting AUPKG02 back
<tinoco> pitti: they are not IPLing automatically
<tinoco> so they didn't come back after a maintenance
<tinoco> sorry for that
<tinoco> pitti: ok, doke. aupkg02 is getting back.
<tinoco> ping me if needed, cheers!
<tinoco> infinity: ^
<pitti> tinoco: confirmed, thanks!
<infinity> tinoco: Ahh, we've crossed streams.  Now, remind me how to disconnect from 3270 without halting? :P
<tinoco> infinity: #CP DISC HOLD
<tinoco> will disconnect you
<tinoco> do not #CP LOGOUT
<tinoco> :o)
<infinity> Oh, or just disconnect from the menu appears to be safe.
<infinity> And less typing.
<pitti> Laney, infinity: ubuntu-touch-meta uploaded with dropping upstart-sysv (and a whole lot of other stuff that ./update slurped in from the recent seed changes); so hopefully images will start building agaain
<pitti> otherwise we'll have to revert i-s-h and the touch seeds
<infinity> pitti: I suspect that'll fix the build issues, whether it works is a whole different story.
<pitti> yes, of course
<infinity> pitti: Once we're sure of the change and we've passed a point of no return, the next step is to drop init out of Essential, so we can shrink chroots again.
<infinity> pitti: Having it essential was always "wrong", but the easiest way to force the upgrade.
<pitti> infinity: coming -- see debian bug 756023
<ubottu> Debian bug 756023 in init "init: Move "Essential: yes" from init to init-system-helpers" [Wishlist,Open] http://bugs.debian.org/756023
<infinity> pitti: \o/
<infinity> pitti: I look forward to shrinking all my yakkety chroots and beyond.
<infinity> pitti: upstart was transitively essential for so long that I've almost forgotten what it's like to have a proper chroot. :P
<infinity> pitti: FWIW, that change can land at any point in this mess, we only needed it essential up to xenial to force the sidegrade.
<pitti> infinity: right, I just didn't get around to uploading it yet, and it didn't seem particularly urgent
<infinity> pitti: Nope, not urgent at all.
<infinity> pitti: And my narcotics seem to be finally kicking in, so I might go find a nap.  See you back at work tomorrow.
<pitti> slangasek, infinity, Laney: FYI, re-enabled s390x in britney
<cking> pitti, stress-ng 0.6.04-1 has been stuck in autopkgtest testing for ppc64el for ~4+ days in  the "Test in progress" state (looking at the update_excuses page). I think it needs some kicking
<pitti> cking: ah, I blacklisted it from testing as it keeps breaking the ppc64el testbeds
<pitti> cking: sorry about that, it shoudl be reflected better in excuses (there's a bug about that)
<pitti> cking: i. e. it gets stuck in an eternal testbed failure/retry loop
<cking> pitti, ah, so is it failing the test, breaking the machine or is there something else going on?
<pitti> cking: something like that, yes; I don't remember the precise failure mode; I'll need to run it manually and file a bug with the log
<pitti> I thought I already did, but I think that was for a different package
<pitti> s/I think that//
<cking> ..I guess if stress-ng is breaking the ppc64el testbeds then is stress-ng actually failing, since it's probably a more fundamental OS issue rather than stress-ng per se
<pitti> cking: yeah, I think it's just good enough to actually break the kernel/VM :)
<cking> ppisati, heh, so does that mean it will never get out of -prosed because it's actually doing it's job correctly?(!)
<cking> *proposed
<pitti> cking: well, we can override it
<cking> that would be nice :-)
<pitti> cking: done now; sorry, I didn't get to fully traversing excuses.html today, too much testing backlog and too much other things to do :/
<pitti> cking: should migrate soon
<cking> ppisati, thanks, sorry to hassle you, I know you're v. busy
<pitti> cking: no worries; and I'm pitti :)
<cking> oops, autocompletion failure
<ppisati> that's ok, i can hassle pitti for you if you want
<elopio> arges: ping, are you around? the snapcraft source page says it was published in proposed 4 hours ago, but I can't see it in my machine.
<elopio> is that normal? should I just wait?
<roadmr> hey folks! I'm trying to preseed xenial but it stops at the keyboard selection thing. My (works with 14.04) preseed has these. Do they no longer work on xenial?
<roadmr> ubiquity countrychooser/shortlist select US
<roadmr> ubiquity languagechooser/language-name select English
<arges> elopio: hi. let me look
<arges> snapcraft | 2.9       | xenial-proposed/universe | source, all
<arges> elopio: i see it in proposed
<slangasek> cyphermox: ^^ do you know the answer to roadmr's keyboard preseed question?
<cyphermox> roadmr: I think what you want is to preseed keyboard-configuration/layout to 'us' (or some other value)
<cyphermox> roadmr: I have this full preseed that worked last I tried: http://people.canonical.com/~mtrudel/preseed/full.cfg
<elopio> thanks arges, but I still don't see it. I have proposed enabled, apt update shows it. Still the latest snapcraft is 2.8.8b, coming from xenial-updates.
<elopio> It's weird.
<elopio> huh, I see it in the laptop, but not on the desktop nor the vm.
<elopio> arges: I switched from the main server to a server in the UK. That works for me.
<roadmr> cyphermox: thanks! let's see the diffs.
<daniele_> Hi i got error "No GSettings schemas are installed on the system" when I launch either nautilus or nm-applet
<daniele_> what is the problem I'm using ubuntu server
<roadmr> cyphermox: thanks! I added your d-i config settings and it just worked \o/
<roadmr> cyphermox: (only the ones for keyboard / country so not a big add)
<cyphermox> roadmr: great :)
<cyphermox> I don't think you need the console-setup ones, they're only there for hysterical raisins
<cyphermox> keyboard-configuration is sufficient :)
<roadmr> ok, i'll try to pare it down a bit, yay
<ccope> i'm trying to backport tar from trusty to precise using `backportpackage`, but it seems like it's not rebuilding against the precise dependencies (the Pre-Depends version requirements on libc6 and libacl1 prevents installing the package on 12.04). do i need to modify the source package in some way?
<cyphermox> ccope: simply building the package on precise should get you the right versions for libc6 and libacl1;  but for the backport you really do need to build it on precise for it to pick up the right versions
<daniele_> is anyone able to give me a hint?
<ccope> cyphermox, i'm running `backportpackage tar -d precise -s trusty -k MYKEY -w . -b`, which is building inside a precise chroot with pbuilder-dist
<cyphermox> daniele_: your system is not properly installed; you're missing packages to have the gsettings properly installed. that said, this isn't a support channel. you should ask on #ubuntu
<daniele_> cyphermox: thanks, btw I just reinstalled ubuntu server 10 minutes ago :(
<ccope> In the source package, i see that the control file contains `Pre-Depends: ${shlibs:Depends}, ${misc:Depends}`
<ccope> but I don't know how those get populated
<cyphermox> daniele_: sure, but installing ubuntu-server and then desktop packages is probably the wrong way to go about things if you want a desktop
<cyphermox> ccope: when the package gets built this gets informed by the packages used to build it
<daniele_> cyphermox: I though ubuntu server and desktop are the same
<daniele_> cyphermox: they both uses the same kernel
<cyphermox> daniele_: the kernel is the same, but the packages differ a lot
<cyphermox> daniele_: if you install ubuntu-desktop you'll get everything installed correctly
<ccope> cyphermox, the version dependencies don't match the libraries in the precise build chroot. the version for libacl1 makes no sense, there is no version 2.2.51-8 in any of the ubuntu repositories
<daniele_> cyphermox: that's the problem, I dont want to use unity. I wanted to install i3wm
<ccope> daniele_, please move your conversation to #ubuntu
<daniele_> ccope: ok, sorry :(
<cyphermox> ccope: sounds to me like the chroot might not really be a precise one then
<ccope> i'm logged into it, it is definitely precise
<ccope> https://gist.github.com/ccope/12d952f9de1a3861e715625cce2577ee
<ccope> full build log: https://gist.github.com/ccope/1811e51dfa71aee889f4fc61d5e46f46
<cyphermox> ccope: looking
<ccope> hm maybe it's using pbuilder instead of pbuilder-dist
<cyphermox> I don't think that would make much of a difference
<cyphermox> I'm building the acl package in a precise schroot now, we'll see
<cyphermox> I mean tar
<ccope> yup that seems like it was it.
<ccope> i think regular pbuilder uses the current release your host is running (and my host is 14.04)
<ccope> had to pass --builder=pbuilder-dist
<cyphermox> ccope: well, pbuilder should always use whatever release you tell it to, but I do get it to build properly in sbuild too: http://paste.ubuntu.com/16694093/
<cyphermox> I haven't used pbuilder in a long while though
<Unit193> Has there been any efforts made on a codebrowser?
<nacc> smoser: rbasak: so i think i hit a new corner-case (which rbasak, you and I may have discussed at some point) -- backports going ahead of security/updates. This happened to clamav in Dapper, where backports had 0.88.4-1ubuntu1~dapper1 while release had 0.88.2-1ubuntu1. That causes the import of 0.88.2-1ubuntu1.1 to error out as the 'tip' of ubuntu/dapper is after the to-be-imported version. Should I
<nacc> just not import backports?
<rbasak> nacc: you mean the backports pocket? I hadn't really considered that.
<rbasak> nacc: if we did import it I think it'd have to be a separate branch. So shall we just not import it for now?
<nacc> rbasak: yeah, exactly
<nacc> rbasak: it seems to be "out of band" sort of, so i think we'd need to consider it later
<nacc> rbasak: ok, will exclude all packages in 'backports' pocket, thanks!
<nacc> rbasak: i think i found another case where our "only import a version (the oldest one)" once iteration through the spph is going to not be exactly right
<nacc> rbasak: ping me when you're free, can be tmrw or later this week
<nacc> jgrimm: thanks for the import requests, found a few new bugs :)
<nacc> rbasak: specifically, exim4, in dapper/edgy timeframe: dapper published 4.60-3ubuntu3, which was then copied to edgy. but we only import the dapper version and don't create an ubuntu/edgy yet (since that version was already imported). Dapper then got security updates (4.60-3ubuntu3.1) and when the first 'new' Edgy import occurs (4.62-2), dpkg-parsechangelog spits an error that the range we check for
<nacc> untagged imports (4.60-3ubuntu3.1 -> 4.62-2^ [pseudocode]) has an unknwn start version in 4.62-2's debian/chagnelog. That error is not a big deal (and I could pipe off to /dev/null to quiet it). But that means that Edgy's history includes 4.60-3ubuntu3.1 as an ancestor, which is not correct
<lathiat> ah names i have not heard for a long time..
<rbasak> nacc: I see. Yes, that means my algorithm is flawed :(
<nacc> lathiat: :) i'm importing the published history for source packages into git, so it goes back to the "beginning of time" as far as launchpad is concerned
<nacc> rbasak: i'm not sure if it's algorithm or implementation, since we added the bits for the multiple ubuntu/heads later (although I guess this also means ubuntu/devel would be wrong, so nm)
<rbasak> I suppose copy forwards need to be imported at the "time" that they happen then?
<nacc> rbasak: yeah, that's what i'm thinking
<nacc> rbasak: i could another empty commit-tree that is the copy-forward when detected
<nacc> into the appropriate branch, that is
<rbasak> Does it need an empty commit?
<rbasak> Since the parents would be the same in all cases I think.
<nacc> oh true
<rbasak> Could create a branch pointer or bump it forward for every copy forward.
<nacc> right
<nacc> so the amendment is then that we only import a given version once for a given series
<rbasak> Yes, but also that on an import for a given (version, series), if the version is already imported then don't commit a second time, just locate the commit and set the branch pointer to it (with sanity checks).
<nacc> rbasak: yep, i'm seeing where to insert that into my code now
<nacc> it will get detected as the verison already being tagged, i think (in the pseudocode)
<rbasak> It all makes sense, I just fear that I'm losing sight of all the use cases.
<nacc> it's actually a lot like a sync, just ubuntu -> ubuntu
<nacc> rbasak: yeah, there's so many corner cases :/
<nacc> in fact, i think if i just put the duplicates back into the iterator, it will get handled just like a sync and will be correct
<nacc> although, nm, we don't want a second commit, so not quite a sync, but the same logic -- i'll just check if what we're "sync"ing is a debian commit (ancestor of debian/sid) or not to differentiate
#ubuntu-devel 2016-05-26
<smoser> nacc, you decided no backports ?
<smoser> that is fine with me.
<nacc> smoser: at least for now, we'll need to consider where to put them in the tree (and how they should be named/tagged/etc)
<nacc> smoser: i don't think it's a significant use-case, since it's opt-in for users
<smoser> agree.
<nacc> smoser: thanks!
<rlaager> What's the procedure to get a bug nominated for a release? I'd like to see this SRUed to Xenial, and I'll prep a debdiff (again) once another pending SRU is resolved: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1571241
<ubottu> Launchpad bug 1571241 in zfs-linux (Ubuntu) "ZFS initrd script does not import zpool using /dev/disk/by-id device paths" [Undecided,Fix released]
<sarnold> hey it looks like i've got buttons for that
<sarnold> are you sure "Fix Released" is the right status?
<rlaager> sarnold: Yes, it should be Fix Released in yakkety. I haven't personally tested it. I suppose I can do that right now. But the fix is in 0.6.5.7, which is in Yakkety.
<rlaager> sarnold: Yes, yakkety works.
<sarnold> aha
<sarnold> thanks
<nacc> rlaager: typically you ask in #ubuntu-bugs, iirc sru right (https://wiki.ubuntu.com/StableReleaseUpdates)
<rlaager> nacc: Thanks. Sorry, I've read that page several times, but I missed that.
<nacc> rlaager: np, it's in Procedure, 4.
<nacc> so i guess that's 3.4 :)
<rlaager> Yeah, I see it now. I searched for #ubuntu-bugs after you mentioned it.
<nacc> rbasak: ok, new caveat, do we want to be tracking debian/sid and experimental?
<nacc> rbasak: as there are times where we sync or merge with experimental, it seems
<nacc> specifically exim4 4.73~rc1-1ubuntu1
<nacc> well, e.g. :)
<nacc> it is orphaned by our current algorithm because changelog previous (4.73~rc1-1) is not (4.72-2ubuntu1) but 4.72-3 is in the new debian/changelog and is imported.
<Mirv> flexiondotorg: very nice blog post that ubuntu-mate-yakkety-progress-update :)
<alkisg> Hi, there's an autogenerated .html web page somewhere in ubuntu.com or launchpad.net, that lists all of the packages in the -proposed repositories, along with how long they've been in the queue etc... but I can't find it in google... does anyone know its URL?
<ricotz> alkisg, http://people.canonical.com/~ubuntu-archive/pending-sru.html
<alkisg> Thank you! :)
<rbasak> nacc: eventually we'd want to track experimental I think, yes. Not sure about right now, though I appreciate that it creates a history problem with missing parents if we don't.
<caribou> Is there a way to have a conffile that we modify upon install be identified as such (i.e. modified by us) so it is not considered a user change ?
<caribou> rbasak: that /etc/default/grub.d/kdump-tools.cfg once again :)
<rbasak> caribou: you want a package to be able to modify its own "conffile" without creating conffile prompts? Use ucf.
<rbasak> (or better, .d directories or something if possible)
<caribou> rbasak: another option is to install separate files in /var/lib/kdump & manage specificities with symlinks & dpkg-maintscript-helper
<rbasak> caribou: can you explain in more detail what you're trying to achieve?
<caribou> rbasak: the crashkernel= boot parameter has architecture specific values that I need to configure upon install in /etc/default/grub.d/kdump-config.cfg
<caribou> so it is picked up by update-grub
<caribou> rbasak: so either I have architecture-specific files in /var/lib/kdump & I symlink it to /etc/default/grub.d/kdump-config.cfg
<caribou> rbasak: or /etc/default/grub.d/kdump-config.cfg is a real file that I modify and use ucf
<caribou> rbasak: right now, crashkernel=384-:128M for all architectures which is wrong for ppc64el
<caribou> rbasak: and s390x uses /etc/zipl.conf
<rbasak> I wonder if /etc/default/grub.d needs to grow some arch-conditional functionality.
<rbasak> Would the user ever need to modify /etc/default/grub.d/kdump-config.cfg?
<rbasak> Or is it going into /etc only because that's where the .d directory is?
<rbasak> Or do you want the user to be able to delete the file?
<caribou> rbasak: yes, if the hardware has very large amount of memory, hence 128M is too small
<rbasak> Does kdump-config.cfg contain only that small crashkernel line?
<caribou> rbasak: use can change it but shouldn't remove it or it'll break kernel crash dump functionality
<caribou> A replacement variable to be used by update-grub :
<caribou> rbasak: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:128M" to be exact
<rbasak> I think that's suitable for ucf, though I'm interested to hear what others think.
<rbasak> Perhaps a /usr/share/kdump/kdump-config.cfg.<arch> or something, and have the maintainer scripts call ucf against the right file.
<caribou> rbasak: yes, that's one of my option
<caribou> and it would simplify the script logic; right I have to use 'sed' on the existing file
<caribou> rbasak: thanks; I'll test this one out
<rbasak> caribou: it might be worth filing a bug in Debian asking for arch-conditional functionality right inside /etc/default/grub.d/. If that were possible, then you could just drop a conffile in, right? It might not be worth doing it for the single use case that needs it, but letting the maintainer know may help tally up the use cases.
<rbasak> (but I'd use ucf in the meantime and assuming the answer is "sorry, not worth it for now")
<caribou> rbasak: good idea
<brendand> when using adt-virt-qemu, can i prevent the target from being destroyed at the end of the testing?
<caribou> rbasak: well, maybe one of the grub maintainer who's hanging around here will have something to say
<rbasak> caribou: :)
<rbasak> brendand: are you looking for adt-run --shell-fail or --shell?
<brendand> rbasak, probably. i've used that before but not on a transient target so hopefully it works
<brendand> i need to use a file that is placed in the real-tree during the autopkgtest run, i can see copyup commands copying real-tree on the target to tests-tree in the output-dir, but it looks like it is subsequently deleted - how can i prevent that? or is there an alternative way to copy files from the test bed to the host?
<rbasak> brendand: for debugging?
<rbasak> or something else?
<brendand> rbasak, no i need the junit xml file generated by nosetests
<brendand> so i need to get it on to the jenkins slave
<rbasak> What for? To save an artifact?
<brendand> rbasak, to use with jenkins junit test results plugin. it gives a nice detailed picture of the results
<rbasak> OK, so I guess you need a standard way to get test artifacts from dep8 tests saved by adt-run to be used later.
<rbasak> I'm not aware of a documented way to do this, but it might be worth filing a bug to ask for functionality in adt-run for the test to be able to supply that.
<rbasak> I imagine something like an environment variable to tell the test where to put things.
<rbasak> Since right now it only copies out stdout, stderr, etc.
<brendand> i'm pretty sure there is a way because a previous test suite i worked on did it. i'll go look at that code and see what was done there
<rbasak> pitti doesn't seem to be around.
<brendand> rbasak, yeah. sheesh
<brendand> :P
<rbasak> I wouldn't be surprised if there is an undocumented directory that you can use if you happen to know to drop stuff there. But it might be undefined behaviour and too much knowledge of adt-run internals. It would be nice to have a formal and stable way to do it.
<dobey> brendand: does the -o option to adt-run not give you what you want?
<brendand> dobey, no that tells adt-run where to put the artifacts that it does copy from the testbed
<brendand> dobey, i want to see that other things go there than the defaults
<brendand> i think i found it, just testing it now
<ginggs> doko: hi, i fixed the shogun ftbfs, what do i need to do to LP: #1576967 ?
<ubottu> Launchpad bug 1576967 in shogun (Ubuntu) "shogun fails to build, demoting to proposed" [Undecided,Confirmed] https://launchpad.net/bugs/1576967
<brendand> dobey, rbasak - everything written into $ADT_ARTIFACTS will end up in 'artifacts' under the output-dir
<brendand> not mentioned in the man page - maybe it's in the more extensive web based documentation
<nacc> rbasak: I think, technically, it's trivial for me to track debian/* (which woudl be overkill, as we don't sync from oldstable/stable). This is a harder thing to fix-up, though, i think, as it will cause us to reparent entire trees
<nacc> bjf: jgrimm pointed me in your direction to ask a quick query about a bug: LP: #1433906
<ubottu> Launchpad bug 1433906 in linux-lts-vivid (Ubuntu) "Acer, Inc ID 5986:055a is useless after 14.04.2 installed." [High,Triaged] https://launchpad.net/bugs/1433906
<nacc> bjf: I provided some feedback, as this is filed aginst the LTS HWE stacks, but I think is actually an upstream issue (and thus probably shoudl be filed against linux as well), given 16.04 reports
<nacc> bjf: just didn't want henrik's work to go ignored (and someone on #ubuntu asked about it so i happened to look)
<bjf> nacc, looking
<nacc> bjf: thanks!
<bjf> nacc, we have it on our radar now ... will see what we can do
<nacc> bjf: thanks! it does seem like upstream would take the next revision of henrik's patch, based upon my review of the list, but also i wasn't sure if ubuntu ever took outofband patches (not yet upstream) from the community -- i assumed not, but figured i should learn :)
<bjf> nacc, we will do so in the right situation .. this looks like it might be one
<nacc> bjf: got it, thanks!
<rbasak> brendand: neat. Useful to know. Thanks!
<brendand> oh this is weird - the files in artifacts/ are 3 and a half hours older than everything else :/
<brendand> so jenkins won't use the xml file, ugh
<mapreri> Laney: ximion: so, i just tried on a real fresh yakkety vm to look up scribus on {ubuntu,gnome}-softwere, and it does't show up.  why?
<nacc> mapreri: typo? ubuntu-software (vs. softwere) ?
<nacc> mapreri: oh scribus itself
<Laney> don't know, sorry - start debugging by pkill -f gnome-software; gnome-software --verbose and then see if you get anything interesting
<ximion> mapreri: run "appstreamcli get scribus.desktop"
<ximion> does that return something?
<Laney> it's definitely in the appstream
<Laney> don't have bandwith beyond that to debug for you atm, sorry
<mapreri> appstreamcli knows something, so this is cool already.  https://paste.ubuntu.com/16710210/
<mapreri> `gnome-software --verbose` is kinda of noisy.
<Laney> search for scribus
<mapreri> this is crazy https://paste.ubuntu.com/16710302/
<mapreri> (gnome-software:2344): Gs-DEBUG: app invalid as no pixbuf scribus.desktop
<mapreri> (gnome-software:2344): Gs-DEBUG: no search results to show
<mapreri> not sure what's telling me though
<Laney> that's your way in to debug it, unless ximion knows why already
<ximion> mapreri: does "/var/lib/app-info/icons/ubuntu-yakkety-universe/scribus_scribus.png" exist?
<mapreri> nope
<mapreri> /var/lib/app-info/icons/ubuntu-yakkety-universe/64x64/scribus_scribus.png does though
<mapreri> ximion: guess you forgot 64x64 â
<ximion> ah, right, that's good enough
<ximion> jup
<ximion> so, gnome-software is being dumb here
<ximion> or rather appstream-glib
<Laney> it has both a cached and a stock icon in the appstream
<ximion> for some reason, it uses the icon name "scribus", which is the stock icon-name, while the icon cachename, "scribus_scribus.png" is available
<ximion> Laney: yeah, I though that would confuse it at first too, but since the stock icon name is very common, we would have lost 60% of all apps in GS if this was a common bug
<ximion> hmm...
<Laney> I'll leave it with you
<Laney> thanks
<ximion> Laney: this might be a bug in the generator not building new-style metadata, but *also* a bug in asglib for not reading the old data properly
<ximion> which, in the latter case, is important, because the patch which touched it last is queued for SRU
<ximion> so far with only positive feedback
<ximion> I'll investigate this, because there is a chance that if it is broken at all, that I was the one who broke it
<Laney> this is yakkety which has the new code already
<ximion> (although this ran through multiple rounds of testing by various people already...)
<Laney> so yes, thanks
<mapreri> (btw, this only confirms my idea that the AS system was too young to supersede ubuntu-software-centre)
<Laney> not helpful
<mapreri> ximion: if you need some kind of testing I'm up for that, but I'm not sure if there is something more i can help with that
<ximion> mapreri: it doesn't make sense that only Scribus would be hit by this bug
<mapreri> yeah, indeed :s
<ximion> btw, whatever the bug is, the chance that it doesn't exist in Xenial is high
<mapreri> i mean, it's not that i'm doing something so weird
<mapreri> ximion: to check that, I suppose I could get a xenial VM and temporary put yakkety in the apt lines, right?
<Laney> it's true actually
<Laney> get https://launchpad.net/ubuntu/+source/appstream-glib/0.5.13-1/+build/9549443/+files/libappstream-glib8_0.5.13-1_amd64.deb
<Laney> and it works again
 * Laney marked the sru accordingly
<ximion> Laney: are you sure?
<mapreri> let me try
<ximion> I tried with the new and old asglib (using Cuttlefish as an example of having both stock and cached icons), and no matter which asglib I use, that too doesn't show up
<Laney> http://people.canonical.com/~laney/weird-things/scribus.png
<mapreri> yeah
<mapreri> it shows up indeed with the older asglib
<ximion> Laney: wow, I just got the gnome-software freezes the entire system bug
<ximion> couldn't click on any desktop element anymore
<Laney> "the" bug?
<ximion> on KDE!
<Laney> crazy
<ximion> jup, I saw it reported on GNOME
<Laney> not heard of or seen that
<ximion> and I though that the chance that this was related to gnome-software was close to zero...
<ximion> mapreri: I can reproduce this now, I'll prepare a patch later
<mapreri> ximion: great, thanks
<ximion> need to get some other things done first
<ximion> Laney: ah, I confused it with LP:#1578317 (and messed that one up with another thread of GS stopping the whole system)
<ximion> Laney: when doing a new debdiff, which version number should that have?
<mapreri> now, unrelated, can I sru this scribus package by just appending '~ubuntu16.04.0' to the version?  (this is the only change since xenial)
<ginggs> mapreri: 1.4.6+dfsg-2ubuntu1 should be fine - you have 1.4.6+dfsg-3 in yakkety
<ximion> Laney: this might be a bug in GS afterall...
<ximion> Laney: it's not my bug! :D
<ximion> the patch I made just exposed a different bug in asglib ^^
<mapreri> inceptionbug
<ximion> or rather, some odd behavior, where I need hughsie for to clarify
<ximion> at time, the code simply prefers stock >> cached >> local >> remote icons
<ximion> which would make sense if GS would fall back to the cached icon if the stock icon isn't found
<ximion> so, this can be fixed in asglib or GS
<ximion> mapreri, Laney: bug report against GS filed and attached to LP 1576780 after a brief discussion with the GS maintainer
<ubottu> Launchpad bug 1576780 in appstream-glib (Ubuntu Xenial) "Needs to implement the full DEP-11 icon spec for compatibility with 3rd-party repos" [Medium,Fix committed] https://launchpad.net/bugs/1576780
<ximion> it's a rather severe bug in GS, IMHO, so we should fix it in an SRU if a patch is available
<ximion> meanwhile, the appstream-glib fix which trigger this bug should stay blocked
<mapreri> ximion: but are you saying that it works perfectly fine in yakkety with kde?
<ximion> yes, because I had an icon theme which shipped a different Scribus icon
<mapreri> ah
<mapreri> tricky.
<ximion> (was still on to fix a KDE bug ^^)
<ximion> switching back to breeze made the entry disappear again :D
<ximion> mapreri: plasma-discover is not affected by this bug, it shows Scribus
<ximion> so, you have KDE covered :)
<mapreri> o.O( who uses the default DE anyway!? )
 * ximion needs to run
<nacc> hrm, seems like xfce4-whiskermenu-plugin has broken grep-merges
<nacc> as it's author and uploader are None
<nacc> Unit193: --^
<slangasek> oh, is that what broke it ;)
<nacc> slangasek: i just dumped a few print's in and saw:
<nacc> package xfce4-whiskermenu-plugin, author None, uploader = (None)
<nacc> seems like that implies that the json has a None for the 'user'?
<slangasek> yeah, how did someone manage that
<slangasek> I guess that's a bug in the MoM code, since the lp upload page looks fine
<slangasek> bdmurray: ^^ maybe you have insight on this
<nacc> slangasek: ack, i was looking at the same
<bdmurray> slangasek: no idea
<b4r> anyone in particular working on the php7.0 package and updating to today's php 7.0.7?
<nacc> b4r: responded in #ubuntu-server
<Unit193> I didn't break it. :3
<rhollencamp> trying to follow directions at http://packaging.ubuntu.com/html/udd-getting-the-source.html#branching
<rhollencamp> when I run `bzr branch ubuntu:x/cinnamon-settings-daemon cinnamon-settings-daemon.dev`
<rhollencamp> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/x/cinnamon-settings-daemon/".
<rhollencamp> looking in launchpad, it doesn't list a branch for xenial (https://code.launchpad.net/ubuntu/+source/cinnamon-settings-daemon)
<Unit193> nacc: About the only thing I can think of is if it's expecting my name to only have letters.
<Unit193> But that'd break on some forign names too.
<bdmurray> sinzui: Is all the TODO stuff in the bug description of bug 1556981 done?
<ubottu> bug 1556981 in juju-core (Ubuntu Wily) "[needs-packaging] Juju 1.25.5 is not in wily and trusty" [Wishlist,Fix committed] https://launchpad.net/bugs/1556981
<sinzui> bdmurray: I am shamed, it is and I did not update when I added the comments. I will update now
<bdmurray> sinzui: I didn't mean to publicly shame you.
<sinzui> bdmurray: the bug is updated. I think the wily and trusty packages are good to go to *-updates when their 7 days in proposed is up
<bdmurray> sinzui: think? do you have any reservations because I was about to release them
<sinzui> bdmurray: please do release them. They are solid
<nacc> Unit193: oddly it shows you correctly for the package just before it
<nacc> rhollencamp: possibly because it's in sync with debian now?
<Unit193> I don't see anything I could have done, hmm.  Also, wow.  Thanks for the ping, means I uploaded the new one exactly one month after. :D
<nacc> rhollencamp: not sure, but the vcs in the control file is: https://anonscm.debian.org/git/pkg-cinnamon/cinnamon-settings-daemon.git
<nacc> Unit193: yeah, I doubt it's you :)
<Unit193> Figured good to check.
<mwhudson> can someone remind me how often the cronjobs that import things from debian run?
<mwhudson> there is one cron job that copies state from debian into the 'debian' distro on launchpad
<mwhudson> and another that copies things from the 'debian' to 'ubuntu' distros
<mwhudson> iirc one of these is gina and the other is iron, but i certainly forget all the details
<wgrant> mwhudson: gina imports into the debian distro on LP every six hours, running on the machine named iron.
<wgrant> The "autosync" from Debian to Ubuntu runs on snakefruit at a frequency I don't recall.
<mwhudson> wgrant: aah
#ubuntu-devel 2016-05-27
<cjwatson> wgrant,mwhudson: 0 5,11,17,23 * * *
<mwhudson> yummy cron syntax
<mwhudson> every 6 hours, at a wild guess one hour offset from when gina runs?
<cjwatson> gina is 05 4,10,16,22 * * *
<cjwatson> so close enough, yes
<Unit193> mwhudson: Is 42 */3 * * * any more fun? :3
<mwhudson> Unit193: no it's all terrible
<mwhudson> apart from @daily, @hourly etc i can remember what those mean :)
<Unit193> Or @reboot in that case.
<raymod2> Does anyone know how to send a drag-n-drop event to another application programatically?
<raymod2> I'm trying to send multiple *.kml files to google earth to be displayed on the same map.  But when I use g_app_info_launch_default_for_uri() the 2nd and subsequent files are rejected and google earth emits an error saying that an instance is already open.
<dobey> that's not DnD; seems like a bug in google earth that it doesn't support taking multiple kml files as command line args
<raymod2> dobey - well the reason I am looking into DnD is because I can drag and drop additional *.kml files into the google earth window
<raymod2> So I thought maybe my application can somehow send DnD events to a running instance of Google Earth to get it to do what I want.
<raymod2> (rather than g_app_info_launch_default_for_uri)
<dobey> well i'm not sure what you're trying to do exactly. why are you using g_app_info_launch_for_uri()?
<raymod2> That's how I send the first *.kml file to Google Earth.  It launches a new window and the KML is displayed properly.
<dobey> what happens if you run "google-earth foo.kml bar.kml" ?
<dobey> faking DnD is not the right answer here. it's certainly possible, but quite ugly and would be very disturbing for any user of your app
<raymod2> Hmmm, it says cann't open file for reading.
<dobey> well, where foo.kml and bar.kml are two of the URIs you're trying to pass to google earth
<dobey> and google-earth is whatever the actual command for running google earth is
<dobey> but i don't think you want to run g_app_info_launch() anyway
<raymod2> I hadn't tried opening a *.kml directly from a terminal prompt.  It doesn't work that way.
<dobey> what doesn't work that way?
<raymod2> It only seems to work with g_app_info_launch_default_for_uri().
<raymod2> When I pass the *.kml on the command line Google Earth launches but then displays a dialog saying it can't open the file for reading.
<raymod2> Just running "google-earth foo.kml" fails every time.
<dobey> well, what does "xdg-open foo.kml" do then?
<raymod2> Yes, that works.
<dobey> and what happens if you do that while google earth is running?
<raymod2> That tries to launch a new instance of Google Earth which outputs an error about another instance running - then the new instance crashes.
<raymod2> "Google Earth appears to be running already. Please kill the existing process, or delete /home/dan/.googleearth/instance-running-lock if this is an error."
<dobey> so then google earth is broken and doesn't support any rpc to tell it to open another file i guess
<raymod2> sounds like it.... but what about my DnD idea?
<raymod2> I don't think Google cares about Linux so I suppose I need to find some hack to work around this.
<dobey> well i don't know what you're app is doing exactly, but i would suggest not relying on google earth being installed
<raymod2> Well, it might be too much work to write a Google Earth clone from scratch!
<raymod2> And how is it you don't know what my app is doing exactly?  I said what it is trying to do.  Load multiple *.kml files into Google Earth and display them simultaneously.  Do you know what a KML is?
<dobey> i know what a kml is. i don't know why you're writing an app to load kml files into google earth, when google earth already internally has support for loading kml files
<raymod2> Also, why do you keep saying I shouldn't use g_app_info_launch_default_for_uri() for this?  That seems like exactly what this API is for.
<raymod2> dobey, my app generates the KML files.  I want to display them without writing Google Earth from scratch.
<dobey> because you want to pass multilpe URIs, not run N instances of google earth (or whatever mapping app might be installed)
<dobey> i presume you are using gtk+ or gnome libs?
<raymod2> Well, I want to add these *.kml files at different times.  Not all at once.
<raymod2> Yes, I am using GTK+ which of course gives me access to glib APIs.
<dobey> you might want to look at using libchamplain, which provides a map widget, and i think has support for loading kml data
<raymod2> That sounds like it will be a degraded user experience.  I've already got this working in Windows and OSX.  I'm just trying to port my application to Linux.
<raymod2> I thought this would be easy since I am using GTK+.  Boy was I wrong.
<raymod2> (this issue is one of many!)
<raymod2> ...but it seems to be the last roadblock
<raymod2> Why do you think DnD is a bad idea?  It seems to be my only hope.
<dobey> because having the mouse move randomly across the screen is never good
<dobey> and becasue it only increases the dependency on google earth existing
<raymod2> I wasn't suggesting taking control of the mouse.  Surely there is an ABI for this.
<dobey> how else would DnD work?
<raymod2> How does the file manager send the DnD to the open application?  It doesn't need a user and a mouse to do this.
<dobey> you have to initiate a drag, move the mouse to the other window, and then drop
<dobey> i don't think what you are calling DnD, is DnD
<raymod2> DnD is just a form of interprocess communication.  The details of mouse pointers and mouse clicks is just a user input method that directs the application to what the user wants.  Then the application initiates the actual DnD somehow programmatically.
<raymod2> Presumably the window manager plays a part in all this.
<dobey> DnD is not "just a form of IPC"
<raymod2> My application accepts DnD events so I am not ignorant to how it works.  I need to send one rather than receive one.
<raymod2> Does anyone else have anything to add?  I don't think dobey can help with this.
<RAOF> raymod2: It *is* possible to send DnD events programattically, but this means you'll need to be implementing (one or more of) the (three) X11 DnD protocols.
<tjaalton> anyone using apt-mirror to mirror trusty? it's giving weird errors here..
<tjaalton> looks like the skel-directory was corrupt
<sarnold> tjaalton: can you pastebin something? there were problems with the archive mirrors ~38 hours that might have caused trouble on downstream mirrors.. that problem should have been resolved 'everywhere' by now though
<tjaalton> sarnold: nah this was there for some time now, I'll let it sync the mirror before checking again. at least the skel-directory looks better now
<wgrant> skel-directory?
<tjaalton> I think it's a local cache for apt-mirror
<sarnold> tjaalton: btw, skel-directory? my (not atp-mirror based mirror) doesn't have anything matching '*skel*dir*' ..)
<sarnold> ahh
<wgrant> Ah
<wgrant> Yeah, not an actual thing.
<tjaalton> once it's in a consistent state the files are copied to the proper place
<tjaalton> one thing I noticed though is that we're not generating Contents files like debian?
<wgrant> Debian moved their Contents files a while ago, and we haven't followed suit.
<tjaalton> right
<tjaalton> ok
<tjaalton> is it planned?
<wgrant> Specifically, Debian's are now per-component.
<wgrant> We have no specific plans to follow that change.
<wgrant> But we're also not explicitly not.
<tjaalton> okay
<wgrant> There's just no pressing need to do that work, as far as we can tell.
<tjaalton> what about doing .xz files?
<tjaalton> Packages
<wgrant> xenial added xz and dropped bz2.
<wgrant> http://archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/
<tjaalton> ah, indeed
<seb128> slangasek, what's the status of https://launchpad.net/ubuntu/+source/command-not-found/0.3ubuntu16.04.1 ? there is no SRU bug so it looks like nobody in the SRU team is going to copy that over to updates, should a new upload be done? or the SRU team convinced to copy it without associated bug?
<caribou> If I need to force an update of a package (kexec-tools) when new kdump-tools is installed, is a versionned Depends: sufficient or do I also need to add a Breaks: ?
<rbasak> caribou: a versioned Breaks is sufficient I think, if a newer version of kexec-tools is available. A Depends would additionally force both packages to be installed.
<caribou> rbasak: I'm currently using only a versionned depends which works correctly
<caribou> rbasak: just curious to know if the Breaks is better
<rbasak> I don't think you need the Breaks, at least not for that specific requirement.
<rbasak> Are you familiar with https://wiki.debian.org/PackageTransition? It should cover most cases.
<caribou> rbasak: that's what I tought also
<caribou> rbasak: I think I read this one recently; I went through so much of the Debian documentation lately that I'm a bit lost in what I read or not
<caribou> rbasak: thanks; I read part of it earlier but now it outlines another change in kexec-tools that needs to go in.
<caribou> rbasak: so you are correct; according to that, only a Depends: is sufficient
<brendand> can anyone think why there might be a clock skew from the host on a adt-virt-qemu created vm?
<brendand> for some reason it seems to be a few hours behind the host time
<caribou> Is it good practice to use distribution-specific variables (like $dist.Depends} in debian/control to avoid delta b/w Ubuntu and Debian ?
<caribou> I have one kexec-tools dependancy that is specific to an Ubuntu delta that I'm getting rid of, but I'd like to avoid a delta in the depending package
<caribou> sorry for all those questions, but I _really_ want weed out as much delta as possible b/w kdump-tools & kexec-tools
<Odd_Bloke> I'm trying to add an upstart job (on trusty) between networking coming up and cloud-init running; cloud-init-nonet has "stop on static-network-up" and cloud-init has "start on ... and stopped cloud-init-nonet"; if I set "start on stopping cloud-init-nonet" will my job block cloud-init running?
<Odd_Bloke> smoser: (You might be able to help me with ^)
<smoser> probably not
<Odd_Bloke> smoser: Do you know of a way of doing it?
<smoser> looking
<smoser> xnox, ^ ?
<Odd_Bloke> xnox is on a boat this week, I believe.
<smoser> hm.
<smoser> Odd_Bloke, starting should work
<smoser> (man starting)
<smoser> init(8) will wait for all services started by this event to be running,
<smoser> and maybe stopping too
<smoser> as it has similar text.
<smoser> so yes, i think you're right
<smoser> i'd give it a try with a task that does sleep 90
<Odd_Bloke> OK, I'll try putting a sleep in and see if things block as... that.
<Odd_Bloke> ^_^
<Odd_Bloke> smoser: Ah, http://upstart.ubuntu.com/cookbook/#task also has some relevant text.
<Odd_Bloke> smoser: Yep, "start on starting cloud-init" and "task" blocks cloud-init from starting until the "script" block is done.  Thanks for the help!
<Odd_Bloke> smoser: (And without "task" it doesn't block)
<smoser> you could have probalby done it without task and a pre-start
<smoser> but task is probably right
<smoser> if it is somethign that shoudl run to completion and be done
<smoser> like sleep 90
<smoser> :)
<nacc> slangasek: general question for you -- historically (and currently), do syncs occur from any release of Debian or primarily current testing, unstable and experimental? How exactly does experimental work? Are publishes in experimental considered part of the history of unstable (but a place to 'test' things for unstable?) I ask because the changelog entries for releases in each refer to the other series,
<nacc> so I'm trying to decide how best to handle them in the importer
<nacc> sigh, /me googles and maybe finds the relevant answers
<infinity> nacc: autosyncs happen from unstable.  Manual syncs can happen from any of the three.
<nacc> infinity: got it
<infinity> nacc: A manual sync from experimental, however, will *not* track experimental, so manual syncing is required from thereon until unstable has a higher version.
<infinity> (Perhaps a misfeature, but one we've lived with for a decade)
<nacc> infinity: ah sure, that makes some sense, at least
<nacc> infinity: luckily i'm not too worried about the process, i'm just trying to recreate the history in git :)
<nacc> infinity: and our 'parent verification' doesn't work with debian's process yet, so i'm just trying to get my head around it
<infinity> nacc: As for the Debian history of a package, that's muddier, as it's maintainer dependant.  Some people scrub experimental from history when uploading to unstable, some people don't.
<nacc> infinity: yeah, that's what i'm noticing :)
<nacc> infinity: up until now, we were only importing 'sid' explicitly ... but that led to us not finding syncs directly from experimental, if they never got pulled into sid at any time, so i'm adding experimental as a first step, but i'm realizing they are more intertwined than the ubuntu notion of series, so our existing code doens't dtrt
<infinity> nacc: And to make it more exciting, some people will have revisions in there that have never existed in the Debian archive.  So, attempting to create a commit/tag for that revision won't work out too well. :P
<nacc> infinity: yeah we've seen that a few times already :)
<nacc> infinity: we only go of spph right now for creating tags
<nacc> infinity:  we just do some sanity checks off the changelog entries
<rlaager> nacc: By any chance, are you working on version control for all packages in the archive, with imports from Debian?
<infinity> I suspect he's only working on a small subset he cares about.
<infinity> Unless he's decided to do LP dev work and is actually making git package imports a thing for everyone.
<nacc> rlaager: it works for any package
<nacc> infinity: starting small, but there's no reason it can't be used by others :)
<nacc> there are lots of corner cases :)
<cjwatson> when I was doing version tracking in debbugs I decided that the correct thing to do was to infer the history from changelogs
<infinity> nacc: You might want to poke cjwatson/wgrant and see if this overlaps with any future plans they had.
<nacc> infinity: there are probably better ways to this fully w/in LP, my tool just takes the spph and applies an algorithm rbasak has devised
<nacc> infinity: ack, will do!
<infinity> cjwatson: That works better for debbugs than it does for attempting to actually break uploads into git commits, though.
<cjwatson> it might be a useful component of what we need to do; there are several other pieces
<cjwatson> infinity: the git case is more complicated, but knowing which versions are parented to which other versions is still useful, I think
<nacc> cjwatson: yeah, we are treating the spph as "authoritative" and orphan'ing when things don't match that
<nacc> cjwatson: so everything will get tag, but not everythign will have a full 'git' history necessarily
<cjwatson> the spph doesn't tell you the parent version, unless you parse the changelog
<nacc> cjwatson: right, in our algorithm, 'parent' is the previously published version
<nacc> cjwatson: we verify it against chagnelog, and handle some specific cases where they don't agree
<cjwatson> mm, which is sort of OK for a single distribution but doesn't deal with merges excellently
<nacc> cjwatson: rbasak is probably better at explaining the thoughts behind the algorithm, but let me share the doc with you
 * rbasak is otp
<cjwatson> nacc: ok, I don't really have time for an extended discussion right now :)
<cjwatson> was just drive-bying
<nacc> cjwatson: np! i'm not doing it justice
<nacc> cjwatson: i haven't hit a merge yet where the algorithm gets confused, but i've only tested a small set of packages
<nacc> tbh, the issues we've hit so far have all been with just the normal history being ... unexpected :)
<nacc> rbasak: if/when you are off the phone, would appreciate a minute of your time
<rbasak> ack
<slangasek> nacc: syncs can happen from any Debian suite, but autosyncs all happen from a single place (unstable, with I think only one historical exception for an LTS).  Syncs from experimental can be done individually (as we did last cycle for a few php packages).  Whether it's part of the "history" of unstable or not is entirely package-dependent; you can infer some of this from debian/changelog
<nacc> slangasek: thanks
<slangasek> seb128: command-not-found> gah, sorry, seems this fell off my radar.  publishing it now (Friday or not)
<seb128> slangasek, thanks
<rbasak> Unfortunately debian/changelog misses history some times, and I'd prefer the git history to show what was actually published and available to users rather than what the changelog shows.
<rbasak> That makes it a little difficult to decide what the parent of a particular upload is. I think there's a fundamental dissonance between how the archive is organised and what I think git history should show. So I think it's necessary to do some heuristics to do a reasonable job in a bunch of common edge cases.
<rbasak> nacc: ping. Hangout?
<slangasek> rbasak: we're talking about a separate branch (unstable vs. experimental); unless you have an actual git repo, you can't infer anything about the merge topology /except/ by looking at debian/changelog
<rbasak> slangasek: for an Ubuntu merge, we're doing something a little odd, but I think it works.
<slangasek> hmm
<rbasak> A merge ends up with two parents. One of them is the claimed parent in debian/changelog
<rbasak> The other is what was previously in the pocket.
<rbasak> I think.
<nacc> yeah
<slangasek> right, that doesn't sound odd to me at all, that sounds correct ;)
<slangasek> and consistent with the prior art on this in UDD
<rbasak> But except for the merge case, we're picking one parent.
<rbasak> I favour picking the one in LP publishing history, because that's what users saw. It'd be confusing for it not to match I think, for example when working out why something happened from the history.
<rbasak> Even though sometimes for example an Ubuntu uploader will not leave a deleted SRU proposed verification-failed entry in the changelog in an upload that supsersedes it.
<slangasek> not sure I understand, "except for the merge case"
<rbasak> Let me take an example. In sid, the maintainer uploads version A, there is an NMU of A.1, and then the maintainer uploads B.
<rbasak> Sometimes when he uploads B, A.1 isn't in debian/changelog.
<rbasak> If we rely on debian/changelog to determine the parent, then A.1 will be tagged but otherwise unreachable, and not in our imported history.
<rbasak> (of the sid branch tip)
<slangasek> er, right, yes
<slangasek> in that case it's a single branch (unstable) and the history should match the upload history
<rbasak> OK. I think we agree :)
<slangasek> but unstable vs. experimental are different branches, just as unstable and Ubuntu devel series are different branches, and for *that*, you only have the changelog to hint you about the merge topology
<rbasak> But, experimental could jump ahead. An experimental upload could be based on a newer unstable, or on the thing that was previously in unstable.
<nacc> rbasak: https://launchpad.net/debian/+source/exim4/+publishinghistory?batch=75&memo=150&start=150 is the one i'm looking at now
<mapreri> Laney: can you prod dep11-generator for scribus/xenial-proposed? /cc ximion
<ximion> it really is time that I give Laney his immutable suites, so he doesn't have an excuse other than ENOTIME to switch to asgen...
 * mapreri -eparse ximion's message, but guess it was not address to him anyway
<ximion> appstream-generator is the new thing which doesn't have some of the flaws dep11gen has
<worralph> when building debian packages is there a way to check for unpackaged files under debian/tmp?
<cjwatson> dh_install --fail-missing is the usual approach
<worralph> cjwatson: isnt fail missing the default and it only fails if you specified the file in *.install? i want to have the same behaviour as rpm which is something like unpackaged files
<worralph> cjwatson: thanks i figured out i need to override dh_install
<dobey> --fail-missing isn't the default no
<Unit193> Not even --list-missing..
<dobey> files listed in *.install which don't exist in the install path, do fail by default, but that is not the same as --fail-missing
<worralph> thanks
#ubuntu-devel 2016-05-28
<elbrus> rbasak: my proposal with respect to LP 1578144 would be to have cacti move to xenial-updates before we fix the next issue that popped up...
<ubottu> Launchpad bug 1578144 in Cacti "cacti and cacti-spine are not compatible with MySQL 5.7 default sql_mode" [Unknown,Incomplete] https://launchpad.net/bugs/1578144
<elbrus> with the current package in proposed, at least the package does reasonable things (albeit not everything)
<elbrus> upstream didn't respond at all so far... slightly disappointing...
<rbasak> elbrus: that sounds fine. I'm in regular touch with MySQL upstream if that'll help you?
<worralph_> is it possible to have per subpackage conffiles?
<rbasak> What's a subpackage?
<worralph_> when you have one source package that is split into several other packages
<rbasak> Oh, I see. One source package makes multiple binary packages. You're asking whether each binary can have its own conffiles? Yes. conffiles are defined in binary packages so that's the only way they actually happen anyway.
#ubuntu-devel 2016-05-29
<stefanct> apt-get source gitg ; sudo apt build-dep gitg ; cd gitg-3.17.1 ; debuild -b -uc -us -tc
<stefanct> let's suppose gitg-3.17.1 is the directory that apt-get source gitg creates...
<stefanct> how could that fail with wrong versions of a library?
<stefanct> the concrete example is failing for me in xenial
<stefanct> Requested 'libgit2-glib-1.0 < 0.24.0' but version of libgit2-glib is 0.24.0
<stefanct> (commands paraphrased from memory... but that's essentially what i tried to do: build gitg from xenial from source)
<elbrus> rbasak: Not sure if upstream can help here, as I don't want to ask them to check the cacti code.
<elbrus> rbasak: One remark I'd like to make: I can see why changing the sql_mode is something good from MySQL perspective, but I would have expected the package/team in Ubuntu to handle it better, i.e. either a heads-up to the maintainers, or a grace period. Especiall the short period in Xenial was extremely bad for such potentially big impact change.
<elbrus> rbasak: no offence, but both the php 7.0 change and the mysql change cought me by surprize and were both late
<elbrus> and disruptive
<rbasak> elbrus: I agree. Sorry. We should have communicated it better.
<rbasak> elbrus: I'm also not sure we should have done the MySQL switch in hindsight.
<rbasak> elbrus: I think I trusted tests too much. We don't have enough coverage to do that.
#ubuntu-devel 2017-05-22
<hallyn> cyphermox: hey!  any hints for debugging wpa_supplicant refusing to connect to a hotspot (blackberry passport) which a (linux-based) nokia n9 and a windows laptop can both connect to?
<hallyn> (i've tried both 4.4 and 4.8 kernels;  xenial host)
<xnox> do we care about tagging things ubuntu/1-1ubuntu1 or debian/1-1ubuntu1 ?
<xnox> it seems like most tools default to debian/, and don't always work automatically with ubuntu/ tags.
<xnox> apw, rbasak, slangasek, opinion? ^
<rbasak> xnox: tagging where?
<xnox> debcommit --release in git
<xnox> it seems to hardcode debian/ prefix for non-native packages.
<rbasak> Right. In which repository though?a
<xnox> lp:~ubuntu-core-dev/+git/systemd
<xnox> but i'm more concerned generically as well.
<rbasak> I see.
 * xnox has not use the server team tooling yet.
 * rbasak ponders
<xnox> and e.g. gbp dch -> defaults to debian/%(version)s
<cjwatson> it's still the debian/ directory
<rbasak> Where uploaders maintain a separate git repository, we have plans for integration but aren't doing it yet.
<xnox> however i think it should be debian|ubuntu/%(version)s
<cjwatson> and versions already have to not clash
<rbasak> But also, we allow you to do what you want - the importer won't care and won't use your tags.
<xnox> not true for native packages though. we have a few native packages (ubuntu-specific, mostly) that don't have ubuntuX suffix
<xnox> i have been using ubuntu/* tags, but i'm now pondering if my manual efforts were futile.
<rbasak> Note that http://dep.debian.net/deps/dep14/ calls for <vendor>/<version>
<rbasak> It might be reasonable to file bugs for tooling which cannot follow that by configuring the vendor.
<xnox> right. i'm pondering to update tooling to handle things transperantly. yeah.
<xnox> thanks.
<ogra_> abeato, i guess for bug 1692494 getting a review from infinity would be good
<ubottu> bug 1692494 in klibc (Ubuntu) "klibc does not support reboot arguments" [Undecided,New] https://launchpad.net/bugs/1692494
<abeato> ogra_, yup
<ogra_> (so we can have it in-distro to not need to puch it to the PPA for core)
<ogra_> *push
<abeato> ogra_, sure, it is something that can go there, I've also submitted upstream :)
<ogra_> ah, k
<abeato> http://www.zytor.com/pipermail/klibc/2017-May/003957.html (it is in Forwarded field in the patch)
<ogra_> prefect :)
<sil2100> cpaelzer: hey!
<sil2100> cpaelzer: I'm reviewing the nagios SRUs right now and was wondering - since the author mentions this is also a security issue, were there any plans on getting it to -security?
<sil2100> cpaelzer: e.g. was that reviewed by the security team, or maybe it's -updates only?
<sil2100> (depends if its -security worthy)
<sil2100> cpaelzer: anyway, for now I'm getting this to -updates
<cpaelzer> hi sil2100
<cpaelzer> sil2100: it is updates only
<sil2100> ACK, got it, thanks! Published
<cpaelzer> sil2100: it didn't pass my barrier of real-security fix
<cpaelzer> sil2100: and usually the sec's team limit is higher
<cpaelzer> than mine
<cpaelzer> sil2100: thanks for asking
<fallentree> Hello, could someone take a peek at  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690796? I've hit that too, and it appears to be a problem with pagefaults caused when swapping which results in owning those pages crashing or hanging. Sounds pretty severe.
<ubottu> Launchpad bug 1690796 in linux (Ubuntu) "Kernel bug causes hang" [High,Incomplete]
<fallentree> Namely: kernel BUG at /build/linux-lz1RHE/linux-4.10.0/include/linux/swapops.h:129!
<fallentree> /owning/processes owning/
<fallentree> I had a pagefile (default on recent 17.04 installation), and have since moved it to a swap partition. So far so good. It appears both the reporter and I use swap over LUKS containers (though mine was a pagefile, so extra layer: ext4)
<fallentree> But looking at the reporter's attached files, they use a partition as well, but over LVM. So I'm guessing the layering is triggering the pagefault (sw over LVM over LUKS, and swfile over ext4 over LUKS)
<fallentree> s/pagefile/swapfile   (sorry, long day)
<psusi> say, who do you tell about a broken mirror?  bug #1692546 shows apt got forbidden trying to fetch packages, and when I browse to http://mirror.aarnet.edu.au/ubuntu/dists/, I get forbidden as well
<ubottu> bug 1692546 in grub-installer (Ubuntu) "Grub failed during install" [Undecided,New] https://launchpad.net/bugs/1692546
<cjwatson> psusi: #ubuntu-mirrors to start with; failing that, rt@ubuntu.com
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<sil2100> !dmb-ping
<nacc> rbasak: are ok with me pushing my branch then, presuming all your comments are addressed?
<rbasak> nacc: yes. I intended that the first time, sorry.
<nacc> rbasak: no problem, i just wanted to confirm with you directly
<nacc> rbasak: branch pushed, fyi
#ubuntu-devel 2017-05-23
<rbasak> apw, cking: I'm confused. https://launchpad.net/ubuntu/+source/zfs-linux/0.6.5.9-5ubuntu5 doesn't appear in https://launchpad.net/~colin-king/+uploaded-packages and doesn't appear to have needed sponsorship. What am I missing?
<apw> rbasak, could it have been a sync into -proposed from cking's ppa and then when its been copied again that is lost ?
<apw> rbasak, as to why its not on his +uploaded-packages ...
<apw> rbasak, i wonder if those are the first ones since the buildinfo
<apw> rbasak, or indeed if artful is missing from that list
<apw> (+uploaded-packages)
<apw> rbasak, ok that artful zfs is listed under _my_ sync's.  iirc that was the first upload he did which had .buildinfo included
<rbasak> apw: ah, yes, thanks. https://launchpad.net/ubuntu/+source/zfs-linux/0.6.5.9-5ubuntu5/+publishinghistory
<apw> rbasak, and that meant i could not sponsor it as an upload (he test builds them in a PPA) so i copied it out of the PPA
<apw> there begin a bug in that pull-lp-source does not get .buildinfo
<rbasak> Not relevant to my reason for asking, but I'm curious as to why buildinfo gets in the way here. Why could you not sponsor it as an upload?
<dupondje_> I got some gzip issues in Tomcat. But after downgrading zlib1g it works again. Is there somebody with some experience in this? :D
<dupondje_> xnox: happen to be around?
<xnox> dupondje_, sure
<dupondje_> I upgraded my system recently to 17.04. And was having an issue with my 'UniFi' controller. Seems like gzip compression in the build-in tomcat was broken. "curl: (23) Error while processing content unencoding: invalid code lengths set"
<dupondje_> Now I was able to pinpoint it, and the following commit fixes my issue: https://github.com/madler/zlib/commit/f9694097dd69354b03cb8af959094c7f260db0a1.patch
<dupondje_> I don't see any other bugreports, so it must be some edge case I guess. But would an SRU be possible for this you think?
<xnox> dupondje_, yes, please open a bug report.
<dupondje_> the SRU style kinda bug report? :)
<dupondje_> xnox: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1692870
<ubottu> Launchpad bug 1692870 in zlib (Ubuntu) "gzip compression broken in UniFi (built-in tomcat)" [Undecided,New]
<xnox> dupondje_, if you could update the bug description to follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template that would be awesome
<xnox> dupondje_, specifically how to reproduce the problem/bug would be very useful. As I am not familiar with tomcat.
<dupondje_> adjusted
<dupondje_> Thing is I didn't had time to test if tomcat is affected somehow. But as the UniFi guest portal is using tomcat in the background, and relies on java (which uses the zlib). I guess it will (in some cases)
<mdeslaur> kees, infinity, stgraber, slangasek: tech board meeting in 15 minutes
 * slangasek nods
<ddstreet> stgraber sorry to bug you, but i noticed you've done a few sponsor uploads for the ifupdown and vlan pkgs, could you review and/or sponsor bug 1573272 if you have a chance?
<ubottu> bug 1573272 in vlan (Ubuntu) "default gateway route not installed for bond interfaces through reboot" [Medium,In progress] https://launchpad.net/bugs/1573272
<slangasek> kees: now why are bindnow numbers still so low?
<kees> slangasek: those aren't benefited from the generous PIE logic. i.e. bindnow is only detected on executables with it set
<kees> slangasek: so, 50% of source packages have a PIE executable (with bindnow), and 80% of source packages lack an ET_EXEC (i.e. not not PIE)
<kees> (does that make sense?)
<slangasek> kees: so you're saying the heuristic is lowballing?
<slangasek> rbalint: hi, so when PIE was turned on in Debian, did you do anything systematically with static linking?
<slangasek> rbalint: thinking about how we might do this more cleanly this time around, since when we turned it on for amd64 we spent a long time chasing opaque build failures.
<rbalint> slangasek: i tracked down every issue, and finally the solution was recompiling the static libs with PIE
<rbalint> they don't need to be PIC, PIE is enough
<slangasek> rbalint: so what I'm wondering is if we shouldn't analyze the archive for "-dev build-deps that don't produce shared lib runtime deps", do build tests of those packages, confirm they FTBFS, rebuild the build deps, rebuild the dependent packages, confirm it fixes the FTBFS
<rbalint> yes, this would be the way to go archive-wide IMO
<slangasek> rbalint: ok.  would you like to drive this? :)
<slangasek> rbalint: I'm interested in making sure that we fix these build failures early so that developers don't trip on them
<rbalint> slangasek: sure :-)
<slangasek> cool
<slangasek> rbalint: to be clear, we would want this analysis across all of main and universe
<rbalint> slangasek: sure, it was my understanding, too
<nacc> cyphermox: would you happen to have any insight into LP: #1688018 or LP: #1682227 ?
<ubottu> Launchpad bug 1688018 in network-manager (Ubuntu) "DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6" [Undecided,Confirmed] https://launchpad.net/bugs/1688018
<ubottu> Launchpad bug 1682227 in dnsmasq (Ubuntu) "dnsmasq, network manager *still* not able to relay DNS queries or respond to DNS requests after VPN connection failure / die off" [Undecided,New] https://launchpad.net/bugs/1682227
<cyphermox> not sure the second is accurate, would need to dig in more about the first...
<cyphermox> nacc: too many people with unrelated issues touching these bugs, some are about VPN and network interfaces, other about suspend/resume behavior, and others about $somethingelse
<nacc> cyphermox: yeah, me neither yet
<nacc> cyphermox: right, so there are (i think) two classes of bugs, as you noted
<nacc> s/r is supposedly fixed (or is confirmed fixed for many users)
<nacc> the dns 'leak' is a separate bug
<nacc> *class
<cyphermox> yes, suspend resume is probably fixed.
<nacc> i agree they are all really noisy :)
<nacc> rbasak: LP: #1573624, not sure if you've seen that last comment?
<ubottu> Launchpad bug 1573624 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.11-0ubuntu6 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1573624
<cyphermox> yeah... well it's a "common problem" and people don't usually have the esoteric knowledge of DNS in the context of VPNs
<nacc> cyphermox: right
<cyphermox> I have no idea why some of these have been marked as duplicate when they pretty obviously look like not
<rbasak> nacc: that comment sounds like bug 1592669
<ubottu> bug 1592669 in mysql-5.7 (Ubuntu) "postinst fails when daemon is not running (or is disabled by policy-rc.d)" [High,In progress] https://launchpad.net/bugs/1592669
<rbasak> nacc: I'll comment
<nacc> cyphermox: yeah, the s/r bug that is fix-released had a crazy number of dupes, i'm not sure where they all came from
<nacc> rbasak: yep, thanks!
<cyphermox> nacc: so first step would be to make sure dnsmasq indeed has the requisite fixes, so at least we know we don't need to look at suspend/resume too much
<cyphermox> (I'm doing this, just including the running commentary)
<cyphermox> err, why is this done without patches?
<nacc> cyphermox: dnsmasq is a 1.0 source format pkg
<nacc> iirc
<cyphermox> doesn't matter, we still do patches for that?
<cyphermox> (usually anyway)
<cyphermox> it doesn't matter, it's just yucky
<nacc> cyphermox: maybe i am misunderstanding, but i thought a 1.0 source package was an orig tarball plus a diff tarball (a single patch to apply aiui)
<nacc> cpaelzer: would you be able to respond to LP: #1540692 from a qemu perspective?
<ubottu> Launchpad bug 1540692 in qemu (Ubuntu) "Enable the VirtIO GPU 3D (Virgil)" [Wishlist,Confirmed] https://launchpad.net/bugs/1540692
<nacc> cpaelzer: i'm guessing we're just following debian's lead, but would like confirmation
<cyphermox> nacc, you can still use a patching tool like quilt for 1.0 format packages; it only needs a bit of configuration
<nacc> cyphermox: ah ok, i guess maybe it's not available by default and the tool i usually use (e.g., `dpkg-source --commit`) just says "no" :)
<nacc> *not configured by default
<cyphermox> nacc: in any case, looks like dnsmasq is up to par (at least AFAICT), so focusing on the VPN situation...
<nacc> cyphermox: ok
<nacc> cyphermox: here is another possibly related (with a specific missing connection between NM and openvpn being claimed): LP: #1686252
<ubottu> Launchpad bug 1686252 in plasma-nm (Ubuntu) "OpenVPN connection doesnt reconnect on connection loss" [Undecided,New] https://launchpad.net/bugs/1686252
<nacc> the 'repeatedly tell OpenVPN to connect' seems similar
<cyphermox> no, that's something different
<nacc> cyphermox: ok :)
<nacc> rbasak: it appears that perhaps this is a real bug: LP: #1688068 ?
<ubottu> Launchpad bug 1688068 in mysql-5.7 (Ubuntu) "apparmor profile prevents running in live CD" [Undecided,New] https://launchpad.net/bugs/1688068
<nacc> sarnold: for something like LP: #1687930 which is really just a report of https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-8779.html, what does the security team usually do with such bugs?
<ubottu> Launchpad bug 1687930 in rpcbind (Ubuntu) "remote denial-of-service" [Undecided,New] https://launchpad.net/bugs/1687930
<ubottu> rpcbind through 0.2.4, LIBTIRPC through 1.0.1 and 1.0.2-rc through 1.0.2-rc3, and NTIRPC through 1.4.3 do not consider the maximum RPC data size during memory allocation for XDR strings, which allows remote attackers to cause a denial of service (memory consumption with no subsequent free) via a crafted UDP packet to port 111, aka rpcbomb. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8779)
<sarnold> nacc: we normally mark it confimred, public security, and add the bug to the UCT entry so we stand a chance of closing the bug when updates are issued
<nacc> sarnold: ok, are you able to do that for this bug? i can do the first part, not sure if i have permissions to do the second
<sarnold> nacc: of course if it's in universe we add the usual "this package is community-supported, please provide debdiffs" etc etc
<nacc> sarnold: right
<sarnold> nacc: heh yeah, it's not worth figuring out how to do merges in bzr to add one line to the file :) hehe
<nacc> sarnold: thanks!
<cpaelzer> nacc: done on the qemu bug
<cpaelzer> nacc: it is not only debians lead, but also component mismatch and full of CVEs recently
<cpaelzer> nacc: I wrote it in the bug to be clear with the reporter
<nacc> cpaelzer: thanks!
<bdmurray> What would I use on Lubuntu and Xubuntu that is equivalent to gnome-session-quit?
<wxl> it's via lxsession if memory serves correctly
<wxl> (for lubuntu)
<nacc> cpaelzer: fwiw, re: c#2.6 in LP: #1686679, the Author should be the patch's author, not the backporter's.
<ubottu> Launchpad bug 1686679 in autofs5 (Ubuntu Yakkety) "[SRU] Ubuntu16.04 : autofs takes extreamly long with large number of direct maps" [Medium,New] https://launchpad.net/bugs/1686679
<bdmurray> wxl: Is there anyway you could confirm that for me so I can fix a software-properties bug?
<Unit193> What precisely does gnome-session-quit do?
<bdmurray> gnome-session-quit - End the current GNOME session
<bdmurray> There's a reboot button in software-properties-gtk that I'm guessing doesn't do anything on Lubuntu or Xubuntu.
<Unit193> xfce4-session-logout --reboot
<bdmurray> Unit193: will there be a prompt too?
<Unit193> If you want that, drop '--reboot'
<wxl> i'm on kubuntu right now and plasma ain't behaving for me. once i get it going again i'll open a vm for you, bdmurray
<bdmurray> wxl: cool, thanks
<bdmurray> Unit193: Thanks
<wxl> lxsession-logout
<Unit193> bdmurray: Sure thing!
<bdmurray> wxl: I've put this issue in bug 1693038 since it might be worth SRU'ing.
<ubottu> bug 1693038 in software-properties (Ubuntu) "needs to support restart on Lubuntu and Xubuntu" [Undecided,New] https://launchpad.net/bugs/1693038
<wxl> bdmurray: if you subscribe lubuntu packages team, we'll notice :)
<nacc> rbasak: https://launchpadlibrarian.net/318686604/HookError_source_mysql_5.7.txt from LP: #1689015 appears to be a bug in the mysql apport hook?
<ubottu> Launchpad bug 1689015 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.18-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1689015
<bdmurray> nacc: For sure with the 2nd traceback
<nacc> bdmurray: yep
<bdmurray> nacc: At least in zesty there is try except for the other one
<nacc> bdmurray: ah ok, good to know
<rbasak> nacc, bdmurray: I suspect the user has replaced /usr/bin/python with python 3.
<rbasak> We should have apport pick up on that and have a bug pattern on it.
<bdmurray> rbasak: Why do you suspect that in that bug? Also re apport bug 1681528.
<ubottu> bug 1681528 in apport (Ubuntu) "Include information about python versions" [Undecided,New] https://launchpad.net/bugs/1681528
<rbasak> bdmurray: I'd need to check, but https://launchpadlibrarian.net/318686604/HookError_source_mysql_5.7.txt and I don't think that the hook has been converted to Python 3. So I wouldn't expect that error. Also I've seen users do this before, IIRC wrt. mysql.
<rbasak> I could be wrong. Just a hunch.
<nacc> rbasak: yeah there was another bug that i triaged today with  that issue (they eventually get a backtrace about ConfigParser, which is now configparser in python3)
<bdmurray> rbasak: running python3 /usr/share/apport/package-hooks/source_mysql-5.7.py or python  /usr/share/apport/package-hooks/source_mysql-5.7.py works for me on a xenial system
<rbasak> bdmurray: could it be an edge case?
<rbasak> bdmurray: what does the shebang say?
<bdmurray> rbasak: there is no shebang in it
<rbasak> bdmurray: http://paste.ubuntu.com/24637495/
<rbasak> This is why I think it's a 2 vs 3 thing.
<rbasak> bdmurray: so I don't know how he's got things running under Python 3, but I'm pretty sure the hook was not written to target 3.
<rbasak> We can fix it of course.
<rbasak> We should update it to work on both at a minimum. And perhaps there's a dependency that's not being declared.
<rbasak> Or, perhaps it's an edge case code path that we haven't noticed and is always buggy since something in apport was deliberately switched to use 3.
 * rbasak EODs
<bdmurray> python3-apport is seeded and apport just uses all the stuff in /usr/share/apport/package-hooks/
<bdmurray> The point being I don't think the user did anything wrong but that the hook needs updating.
#ubuntu-devel 2017-05-24
<cpaelzer> nacc: I assume that came up on triage?
<cpaelzer> nacc: I usually do Author + Original-Author (in case they differ)
<cpaelzer> nacc: the former the one who writes the patch for the deb the latter being the one who originally wrote the code
<cpaelzer> nacc: as that usually starts with a git format patch most data is already around
<cpaelzer> nacc: but that reporter is from STS, he should know now more on patch style recommendations - I just gave him some early hints
<cpaelzer> pitti: hi are you around for bug 1693115
<ubottu> bug 1693115 in libvirt (Ubuntu) "apparmor denial: qemu cannot read /proc/*/cmdline " [Undecided,Incomplete] https://launchpad.net/bugs/1693115
<pitti> cpaelzer: hello, how are you?
<cpaelzer> pitti: great and I hope you are even greater
<cpaelzer> pitti: good to see you around
<pitti> cpaelzer: I am, thanks!
<cpaelzer> good
<pitti> cpaelzer: ah yes, thanks for following up, I'll respond ASAP
<cpaelzer> pitti: I was just answering the bug realizing that I could just as well ask you :-)
<cpaelzer> pitti: thank you
<pitti> I just found a regression in freeipa-client too
<pitti> yay for starting to run integration tests on 17.04 (so far we only ran on 16.04)
<cpaelzer> pitti: just want to check asap if it is a regression-update (which it hopefully isn't, but especially then I want to check)
<pitti> cpaelzer: well, if so, it doesn't seem to be completely broken -- qemu seems to do well enough with out reading cmdline, not sure what it tries to check there
<cpaelzer> pitti: it wants to tell people who shut it down
<cpaelzer> pitti: I fixed that already
<cpaelzer> pitti: but the proximity of my fix and your report made me suspicious
<pitti> cpaelzer: oh -- I built that image last week, it doesn't yet have the fix for #1680384
<cpaelzer> pitti: I put it in the bug
<cpaelzer> pitti: yeah exactly - if you miss that then that is the explanation
<cpaelzer> pitti: once you updated on your next run you can update and hopefully close the bug as fix released or dup
<pitti> cpaelzer: yes, I'll verify that -- upgrade the package on my test image, and re-run
<cpaelzer> pitti: what is the interval you update your images?
<cpaelzer> ah sounds like on trigger, ok
<pitti> cpaelzer: normally ~weekly, but it's the first one ever, so I can rebuild one at will
<cpaelzer> pitti: I saw you to avocado based test in cockpit, for a long time I was thinking of that but as usually you beat me
<cpaelzer> pitti: one day I might copy a few bits from there
<pitti> the test/verify/ ones are much more interesting though  :)
<cpaelzer> you mean the ones you run outside of autopkgtests for their complexity?
<pitti> yep, I have 2.5.0-3ubuntu5
<cpaelzer> ok, 5.1 should fix it for you then
<pitti> cpaelzer: right, I don't yet have an autopkgtest wrapper for test/verify
<pitti> just a simple one
<pitti> \o/
<pitti> cpaelzer: followed up, â¥
<cpaelzer> thank you a lot pitti
<cpaelzer> pitti: actually did you mean pro-actively instead of "retro" ?
<pitti> retroprogressawesomely!
<rbasak> pdeee, bmw: as I prepared updated packages for 0.14.1, what can I do to make sure they're working?
<rbasak> *as I prepare
<jamespage> any of the MIR team around? I need a review on https://bugs.launchpad.net/ubuntu/+source/vine/+bug/1688091
<ubottu> Launchpad bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New]
<jamespage> that's holding most of OpenStack Pike b1 in proposed in artful right now
<rbasak> bdmurray: did you intentionally not accept Trusty in bug 1690730?
<ubottu> bug 1690730 in postgresql-9.6 (Ubuntu) "New upstream microreleases 9.3.17, 9.5.7 and 9.6.3" [High,Triaged] https://launchpad.net/bugs/1690730
<bdmurray> rbasak: No, it was not intentional.
<nacc> cpaelzer: yeah -- is Original-Author a DEP3 header?
<rbasak> dep3 just says to use Author multiple times as required.
<nacc> rbasak: right
<nacc> Applied-Upstream seems new
<mdeslaur> rbasak: any progress from upstream about the mysql-5.7 autopkgtest failure?
<rbasak> Skuggen: ^?
<nacc> rbasak: fyi, snap should be updated with your queue fix(es)
<rbasak> Thanks!
<nacc> rbasak: and figured out the two import failures, just refactor errors
<bmw> rbasak: just now seeing your message about testing
<bmw> biggest thing is just running our unit tests included in the packages
<bmw> there's close to 100% coverage there
<rbasak> bmw: can I do that from an installed system, rather than from the source tree?
<rbasak> bmw: this is to catch packaging errors, for example if something's in the source tree but fails to end up in the deb.
<bmw> good question, our debian packager always tracks us down when unit tests fail for him but to be honest I'm not sure how he runs them
<bmw> I'll see if he's around
<rbasak> bmw: we can automate as-installed testing like this too - we call it dep8 (after our spec for how it works).
<rbasak> bmw: essentially I just need something to run after the packages are installed that'll give me a yes or no. This might involve an extra binary package with the test suite, for example.
<bdmurray> rbasak: I'll review mysql for Trusty now.
<bdmurray> rbasak: or maybe I mean postgresql - one of those database things
<nacc> bdmurray: that is what you meant :)
<nacc> rbasak: sigh, have time for a  HO after the certbot stuff?
<Skuggen> rbasak: I mentioned the test fix for mysql 5.7 before (if it's the same failure)
<Skuggen> mdeslaur:^ If it's the mysql_not_windows test failure?
<Skuggen> On Artful
<mdeslaur> Skuggen: yeah, that's the one
<mdeslaur> Skuggen: you mentioned it where?
<Skuggen> https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/commit/?h=mysql-5.7/lars/ubuntu&id=2f13c610e43b89566e0bd0501c19d4edf9258f59
<Skuggen> MySQL package maintainer channel
<mdeslaur> Skuggen, rbasak: is one of you going to do an upload, or do you want me to do it?
<nacc> cyphermox: is there a reason src:nplan contains a .git directory?
<cyphermox> I may have failed at uploading?
 * cyphermox sighs
<cyphermox> nacc: you can disregard...
<Skuggen> mdeslaur: I'm working on a more complete merge from debian as well, but that's not ready yet, but maybe it's a good idea to get the current Ubuntu package working on Artful first
<nacc> cyphermox: yeah, but it's there now and i need to think about how to handle it :)
<nacc> cyphermox: our importer gets pretty confused :)
<cyphermox> nacc: not sure I understand what you mean
<cyphermox> ah
<mdeslaur> Skuggen: it's blocking other things from migrating, so I would prefer that
<Skuggen> rbasak: ^
<Skuggen> I don't have upload rights :)
<cyphermox> nacc: do as you prefer, it won't be there in next upload. Seems like an instance that ought to be handled anyway
<nacc> cyphermox: i swore that the debian manual somewhere said src packages shouldn't contain .git, so we weren't handling that case. But i'm not finding it now. Ther eis 3.0 (git), though, so we need to consider it
<nacc> cyphermox: yep, needs to be handled
<mdeslaur> Skuggen: I can sponsor your two commits that add the patch and the changelog if you want
<cyphermox> nacc: fwiw, importing netplan isn't a bit deal though, it's a native package and one that we're upstream for. the real git repo is in launchpad already
<Skuggen> mdeslaur: Sounds good to me
<mdeslaur> ok, will do in a few minutes
<mdeslaur> thanks Skuggen, rbasak
<nacc> cyphermox: yep, it falls under the umbrella of 'thou shall not fail' (where thou is the importer) and 'import everything' :)
<cyphermox> nacc: I think regardless of configuration the importer should be able to handle an existing .git directory in a source package, or at least not barf on it
<nacc> cyphermox: yep
<nacc> cyphermox: just need to think about how, since we are also a .git directory :)
<nacc> s/are also/also have/
<cyphermox> sure
<cyphermox> what I'm saying is you'll get other instances than just nplan
<nacc> cyphermox: yep  agreed
<nacc> i wonder what dgit does
<cyphermox> well, the issue in this case is that I should have used gbp to build the source package
<cyphermox> that rips out .git from the source.
<nacc> ah i see, dgit does that for imports too
<nacc> dgit: warning: removing from source package: ./.git
<cyphermox> nacc: and I agree nplan probably ought to be a 3.0 (native) rather than 1.0 format package.
<cyphermox> nacc: and that looks like it will avoid the issue in the future
<nacc> cyphermox: yep, i think so
<nacc> cyphermox: and i think at the same time, i'll push this fix to follow dgit's lead and remove .git/ from srcpkgs on import
<cyphermox> hrm, that seems wrong
<cyphermox> I mean, it's going to make things work, but then what you'll import won't actually be precisely what was in the upload
<nacc> cyphermox: that's true, but for our import-comparison function it will be (since it will always be looking at the tree-hash without the .git directory)
<nacc> cyphermox: otherwise, i'd need to do a lossless rename of either our .git directory or teh srcpkg -- the latter of which is messy and has the same issue (matching the upload)
<cyphermox> nacc: that's fine, but it won't fix the issue that if you build a new upload based on that import you'll have an extra diff of a removed .git directory
<rbasak> mdeslaur: thanks!
<nacc> cyphermox: ah i see what you mean
<cyphermox> nacc: the right solution would be setting GIT_DIR to something else for the imports.
<nacc> cyphermox: no, it's worse than that
<rbasak> Skuggen: also thanks!
<nacc> cyphermox: what should `git clone` do?
<rbasak> nacc: HO?
<nacc> rbasak: yes please
<rbasak> nacc: standup URL?
<cyphermox> nacc: explode in flames? ;)
<nacc> cyphermox: yeah :)
<nacc> rbasak: yep
<cyphermox> nacc: I thought you used a tool to clone too
<nacc> cyphermox: right, but then that tool is now different than `git clone` which should always work too
<nacc> (and is the default on LP)
<cyphermox> nacc: if there's no other way around, I suppose removing .git on import is the lesser evil
<nacc> rbasak: for context, LP: #1693290
<ubottu> Launchpad bug 1693290 in usd-importer "Unable to import nplan (May 29, 2017)" [Undecided,New] https://launchpad.net/bugs/1693290
<cyphermox> (but you might want to ask others for their opinion)
<nacc> yep, and we're not necessarily doing this change forever
<cyphermox> nacc: well, yeah, for any source package that includes it..
<cyphermox> I wonder if you couldn't just fudge things by making britney very much dislike .git directories in source ;)
<nacc> cyphermox: tbh, this is the first srcpkg with this issue :)
<cyphermox> nacc: heh
<cyphermox> I'm happy to reupload if it makes your life easier.
<nacc> cyphermox: well, the history is still there, so it's ok :)(
<cyphermox> right, it won't solve history
<ddstreet> cyphermox hi, sorry to bug you, i have a bug 1573272 that i need to get into artful, it's a small change to the vlan pkg, since ifupdown/vlan is deprecated in artful it should hopefully be an easy/safe upload, could you take a look and maybe sponsor?
<ubottu> bug 1573272 in vlan (Ubuntu Artful) "default gateway route not installed for bond interfaces through reboot" [Medium,In progress] https://launchpad.net/bugs/1573272
<ddstreet> i can work on getting it sru'ed once it's in artful
<cyphermox> ddstreet: ok
<bmw> rbasak: while it's not exactly pretty, here's a pretty decent one line test that certbot and its plugins and dependencies are installed correctly
<bmw> certbot plugins --prepare | grep -q apache && certbot --help nginx | grep -q nginx-ctl
<kees> infinity: https://outflux.net/ubuntu/hardening/i386/ now being gathered/graphed. delta to amd64 wrt PIE is amd64:80% PIE, i386:55% PIE
<infinity> kees: Curious.  Is that 55% because lots of people now build with hardening=+all/+pie, or because you count PIC libs and non-ELF packages as a yes?
<infinity> kees: (As in, I would have expected that delta to be higher)
<kees> infinity: the data collection was adjusted to have a source package be seen as "PIE" if it has ELF objects but no ET_EXEC in any binary package.
<kees> i.e. all-library package is counted as PIE
<kees> and to distinguish from the stricter count ("has ET_DYN executable"), I left BINDNOW as it was counted before.
<kees> so the difference between bindnow and pie is roughly the difference between packages with ET_DYN executables and packages without ET_EXEC.
<infinity> kees: PS: The i386 graphs say "amd64" on the Y axis. ;)
<kees> whoops
<infinity> We'll call that the axis of evil.
<kees> ahah
<infinity> kees: Hahaha.  So I was going to ask if there's a better breakdown of this data so I can see what actually needs fixing.  Then I saw "pie.data" and excitedly clicked on it to find it has... A single line.
<kees> :)
<kees> graph data!
<kees> I could include the scan log?
<infinity> kees: Any idea why the FORTIFY_SOURCE count is so low?  I refuse to believe that 33% of our ELF objects don't link to glibc, nor do I believe that 33% of maintainers intentionally turn it off, so that seems a bit suspect.
<kees> when I've looked into that in the past, it was mainly due to a few situations. if you build with fortify enabled, there are some possible results:
<kees> - you don't use any scary functions, so nothing is replaced with ..._chk() version to be detected by the scanner
<infinity> Ahh.  Yeah, that would do it.
<kees> - you DO use scary functions, but their use can be entirely validated at compile time, so no ..._chk() versions to be detected...
<infinity> Built with doesn't imply it actually gets the macros inserted.
<kees> - and you use scary functions, can't be compile-time validated, so _chk() versions exist to be detected (this is graphed)
<infinity> That's a bit irksome for post-build analysis, but oh well.
<kees> - last case, which I've never seen: you use scary functions but they can be neither validated at runtime nor compile time, so no _chk()
<kees> sure is. having "compiler flags" in some ELF note in binaries would be nice, but bloaty
<infinity> There's also "you build without optimisation because you're a bad person", but I want to know about those ones.
<kees> oooh yes
<kees> that too!
<infinity> (And then the as-stated above "your ELF object doesn't link to glibc", but other than some other-libc compilers, freestanding toolchains, and bootloaders, there should be precious few of those)
<infinity> But yeah, the "macros isn't used because it's just not needed" cases probably cover most of the mysterious gap.  Just sucks that it's really hard to tell for sure that's the reason for the gap.
<kees> yup. but that's why I made it default-enabled in the compiler. ;)
<infinity> kees: is this just main or all components?
<infinity> "NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2 is set by default, and is activated when -O is set to 2 or higher."
<infinity> kees: ^-- Do you recall if that hack included -Os?  s isn't technically "higher" than 2, more complementary.
<kees> infinity: this is all components
<infinity> Also holy crap, 8.10... That was eons ago.  We were both young and virbant humans, full of promise for the future.
<kees> infinity: I don't know -- it's entirely handled by the glibc header files, IIRC
<infinity> Oh, right.  I guess I could answer my own question there.
<infinity>     && __GNUC_PREREQ (4, 1) && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
<infinity> So, the gcc manpage might be a lie.
<infinity> Looks like it flips it on for -O > 0
<kees> or it's changed in the last 9 years :P
<infinity> Well, yes, I meant it's currently a lie. ;)
<kees> ah, yes :)
<kees> https://outflux.net/ubuntu/hardening/i386/main/  <- main-only
<infinity> Oh, and __OPTIMIZE__ is just set to 1 for any -O that's not 0.
<kees> (and evil axis less evil now)
<infinity> I was expecting it to have useful information.
<infinity> But whatever.
<infinity> kees: http://paste.ubuntu.com/24646078/
<infinity> So, that's nice.
<kees> infinity: oh, cute. I really don't think that used to be the case.
<rbasak> bmw: thanks! I'll use that.
<infinity> kees: More curiously, I would expect printf(__STATIC_DEFINE__) would be optimisable away.  Maybe it's because I got clever and put the newline in.
<infinity> Hrm, nope.
<infinity> Ahh, replacing it with a string literal "1" optimises it away.
<infinity> Need a smarter compiler.
<infinity> kees: http://paste.ubuntu.com/24646299/ <-- Better test that actually compiles with -O0 to show how things work today.
<infinity> kees: Is it possible that maybe gcc changed the meaning of __OPTIMIZE__?  Cause the glibc code in question hasn't changed since 2005.
<infinity> (Or maybe the Ubuntu gcc manpage has been lying since forever)
<doko> jbicha, chrisccoulson: did the scrollbar behaviour in thunderbird on 16.04 did change by intent? clicking in the portion below the slider now scrolls to the relative position of the slider, not to the next screen
<jbicha> doko: isn't that how the scrollbar in Firefox works? I believe Thunderbird 52 switched to gtk3
<jbicha> don't you use other gtk3 apps?
<doko> jbicha: no, but that definitely is a change in some recent update
<doko> wondering why we get this in a stable release ...
<jbicha> you're seriously wondering why we don't leave Thunderbird at version 45 forever?
<doko> jbicha: was this a recent change in thunderbird, or in some gnome library?
<jbicha> I believe the change is because Thunderbird 52 builds with gtk3 now
<doko> ahh, ok. that might explain it
<doko> can this behaviour be configured?
<doko> hmm, probably not. at least it's gnome3 :-/
<jbicha> I think it is configurable, but this should affect all gtk3 apps I would thinkâ¦
<jbicha> doko: try https://wiki.archlinux.org/index.php/GTK%2B#Legacy_scrolling_behavior
<doko> ahh, ok
<wxl> i don't know that i've ever quite understood the difference between SRUs and backports. that said, which direction to go with for 1251495?
<wxl> bug 1251495 that is
<ubottu> bug 1251495 in mailman (Ubuntu Trusty) "Lists with topics enabled can throw unexpected keyword argument 'Delete' exception." [High,Triaged] https://launchpad.net/bugs/1251495
<infinity> wxl: backports are for bringing whole new versions back.  SRUs are for fixing bugs.  This is a single-char typo, clearly an SRU candidate.
<wxl> k great thx :)
<Unit193> jbicha: Re: Debian 863288.  The indicator stack is entirely unmaintained, orphaned, and unused in Debian.  The release is from 2012, and since then there have either been no releases, or very Ubuntu centric.  It doesn't make sense to recommend that in Debian.  https://anonscm.debian.org/cgit/users/unit193-guest/deluge.git/commit/?id=d65670c15990838b8b1b1447ac99ca5f5194fd23 is a much better option.
<ubottu> Debian bug 863288 in deluge "deluge: Recommend python-appindicator" [Wishlist,Open] http://bugs.debian.org/863288
<jbicha> Unit193: it's not entirely unmaintained in Debian, see Mike Gabriel's libdbusmenu and NEW uploads this week
<Unit193> Right, those are forks.
<jbicha> right, that's what I intend to talk to Mike about :)
<Unit193> > #arctica
<jbicha> because indicators are not really maintained in Ubuntu eitherâ¦
<sarnold> "congratulations mike you're the new indicators maintainer, pls rename your packages" ? :)
<jbicha> sarnold: :)
<Unit193> sarnold: He's stripping out the Canonical/Ubuntu specific bits, I think Ubuntu would object. :P
<jbicha> he might have been stripping those because the Ubuntu packages were being actively maintained at the time, but not with the features he wanted
<dasjoe> Just out of interest, why is https://login.launchpad.net/ not showing the same data as https://launchpad.net/~dasjoe?
<dasjoe> My profile lists my full name, login.launchpad.net does not. Also, login.launchpad.net does not show my second (and preferred) email address at all
<cjwatson> For better or worse, you have to set those separately in SSO (login.*)
<cjwatson> There's some linkage between the two systems but it doesn't extend to synchronising that sort of data
<dasjoe> I can't add the second email address, the token link shows chrome's (?!) 404
<cjwatson> Should probably report that as a bug against canonical-identity-provider
<dasjoe> cjwatson: thanks, filed
<nicolas17> hi, is there a channel for Ubuntu infrastructure/sysadmins?
<wxl> #canonical-sysadmins
<wxl> oops
<wxl> #canonical-sysadmin
<nicolas17> thanks
<nacc> rbasak: if you could look at http://paste.ubuntu.com/24648967/, first draft of the doc -- and maybe we can discuss tmrw after the team mtg?
#ubuntu-devel 2017-05-25
<tsimonq2> I haven't been able to find much info on this, but why is it that when someone installs python-foo (for example), it installs the Python 2.7 version? Are we supposed to explicitly say python3-foo as if it's a different programming language, or are we still transitioning to Python 3?
<Skuggen> mdeslaur, rbasak: Could you try rerunning the failed tests for MySQL 5.7.18? The only one that seems mysql-related is mysql2, and that's an unstable test (it's testing internal server behavior)
<rbasak> Skuggen: OK, requested. Cc: mdeslaur
<Skuggen> rbasak: diaspora-installer still failing, but it does for multiple other updates as well (e.g postfix and openssl)
<rbasak> ^ can someone force-badtest diaspora-installer 0.6.5.0+debian1 on s390x and armhf please?
<rbasak> Looks like it bundles gems that are broken :-/
<Unit193> \o/
<rbasak> Perhaps that should be force-skiptest
 * rbasak doesn't know
<rbasak> slashd: around?
<sil2100> rbasak: I think he's from Canada, so still a bit too early for him
<rbasak> Thanks
<slashd> rbasak, I'm here
<rbasak> ^ can someone force-badtest (or whatever is appropriate) on diaspora-installer 0.6.5.0+debian1 on s390x and armhf please? It's blocking mysql-server-5.7.
<nacc> rbasak: heya -- sorry for the reconnect here, iwlwifi had a fatal error (??). In any case, did you see my paste from yesterday?
<rbasak> nacc: I missed it, sorry. Looking now.
<nacc> rbasak: http://paste.ubuntu.com/24648967/
<rbasak> nacc: looks good!
<nacc> rbasak: i think 4) indicates a bug (import-local with multiple srcpkgs doesn't really make sense, does it?)
<rbasak> nacc: "queue" does need pkg/ubuntu/<series>-devel to exist for whatever is is importing. Perhaps that could be optional though. I think it should validate against only each base ref in the end, and perhaps only warn in case of mismatch.
<nacc> rbasak: ah ok, not HEAD, i'll adjust
<rbasak> nacc: import-local shouldn't complain about that in case of wanting an orphan commit. I have done that in the past to compare things across package renames etc.
<nacc> rbasak: ah true
<rbasak> nacc: and for simliar reasons I may import-local a package rename.
<rbasak> So I think it should warn but not fail in case of mismatch.
<nacc> rbasak: right, i'll be more explicit, i think everything should do the validation, but only 3) should treat it as fatal?
<nacc> rbasak: and then as we use it, if some case makes no sense to emit a warning, we can figure out a means to disable it
<cyphermox> nacc: bug and a wpa log please? ;)
<cyphermox> (well, just filing the bug is going to DTRT)
<rbasak> nacc: agreed, thanks
<nacc> cyphermox: not wpa, iwlwifi driver itself barfed
<nacc> cyphermox: i can file a kernel bug, though, yeah :)
<cyphermox> nacc: well, just in case ;)
<nacc> cyphermox: grr, i'm worried it might be hw issues ... Microcode SW error detected
<sil2100> slangasek, infinity, stgraber: hey! Through a recent e-mail vote the DMB granted cking (LP id colin-king) PPU rights to the zfsutils-linux and spl-linux packages - from what I see this requires action from TB (I get a 401 when trying to add the new sources) - could you add those to his PPU list?
<cyphermox> that is a common error, I think, it doesn't necessarily mean a firmware issue
<nacc> cyphermox: oh ok, i'll look around to see if it's already reported
<sil2100> Thanks!
<cyphermox> nacc: however, if you're on a thinkpad, there's new firmware if you want to update.
<nacc> cyphermox: oh i see, the actual issue is the "queue 2 stuck for 10000 ms"
<cyphermox> (I went looking, I had something weird happening in EFI and thought it might help)
<nacc> cyphermox: oh interseting, can we do updates to the fw from ubuntu?
<rbasak> sil2100: there's some documentation on this in https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase. For TB actions, we're currently filing a bug and emailing the TB list.
<cyphermox> nacc: on some hardware you can (there's fwupdate/fwupd for that) but I don't think that's available for thinkpads.
<rbasak> sil2100: also please don't forget the announcement (documented there too)
<cyphermox> nacc: they just ship an iso you can boot directly, so you don't need to worry about whether the OS is supported.
<sil2100> rbasak: I did send out the announcement already
<nacc> cyphermox: ok, i'll see if the same exist for the yoga :)
<rbasak> sil2100: to ubuntu-news-team@? I didn't see that.
<sil2100> Oh, no, not that, but I never sent one there before
<rbasak> sil2100: also ubuntu-devel@
<rbasak> sil2100: see the documentation, that explains it :)
<sil2100> Yeah, see it now, is this something new? I don't remember seeing it there ;p
<rbasak> Since August, yes :)
<sil2100> Missed it completely
<sil2100> ...and I was even part of the meeting where we came up with this, duh
<sil2100> Well, I only remembered 'sending announcements' but not the mailing lists we agreed to send it to
<ktt9> Hi there. I have a question about libbamf and it's default matcher. Should I really query the default matcher every time I want to get desktop file for some xid?
<ktt9> Because if I store matcher in static variable and get it only once, it seems that it produces wrong results in some cases.
<gsilvapt> wxl, you around?
<nacc> ktt9: i think you want to find a more appropriate channel
<ktt9> nacc: sorry. What channel should I ask in?
<nacc> ktt9: i'm not sure, but this channel is for the development of ubuntu itself
<ktt9> Hmm... Maybe it's #ubunty-unity then. Thanks anyway.
<nacc> ktt9: or maybe ask a question about the package on lp? https://answers.launchpad.net/bamf/+addquestion
<ktt9> nacc: 5 expired questions, last of which is dated 2013 don't look very promising.
<nacc> ktt9: yeah :/
<jbicha> nacc: askubuntu.com is likely a lot better than LP answers
<nacc> jbicha: good point
<tsimonq2> mitya57: Hey there... what's the plan with Qt 5.9 in Artful?
<tsimonq2> mitya57: Would it be bad to land 5.9.0 in Artful then update to 5.9.1 when it's out, or are we waiting several more months for 5.9.1 to come out?
<tsimonq2> mitya57: I guess IMHO we should get test packages (of 5.9.0) in a PPA and get some feedback from the flavors using it (Lubuntu Next and Kubuntu) and then land once we've fixed any issues that arise.
<tsimonq2> mitya57: But you're more experienced than I am in this area, so I'd like to hear your thoughts. :)
<nacc> Logan: do you know why you added a delta to src:twig to b-d on language-pack-fr-base instead of locales-all?
<nacc> Logan: i think we can sync it again, if that is not necessary
<nacc> rbalint: i wonder if you might be able to spend some systemd cycles on LP: #1624317
<ubottu> Launchpad bug 1624317 in systemd (Ubuntu) "systemd-resolved breaks VPN with split-horizon DNS" [High,Confirmed] https://launchpad.net/bugs/1624317
<nacc> rbalint: it seems like a relatively highly visible bug that pitti did work a bit before, but it also seems like a behavioral regression from 16.04 for many users (there are other bugs duped back to this one and others still open)
<nacc> cyphermox: --^ i'm not sure if it's related to what you were looking at for openvpn
<rbalint> nacc: i put it on my list, but most likely those cycles will take place next week :-)
<nacc> rbalint: np, thanks!
<Unit193> nacc: Like sponsoring, or easy merges to fix security issues?  (Deluge, Debian 862611)
<ubottu> Debian bug 862611 in deluge-webui "deluge: CVE-2017-9031: directory traversal attack vulnerability" [Serious,Fixed] http://bugs.debian.org/862611
<nacc> Unit193: i can probably do that merge tmrw
<Unit193> Ah, cool.  That works, thanks.
<nacc> Unit193: is an SRU bug filed already? i guess it's needed everywhere?
<Unit193> nacc: Not that I know of, but Debian 857903 wasn't SRU'd either.
<ubottu> Debian bug 857903 in deluge-webui "deluge: CVE-2017-7178: WebUI CSRF vulnerability" [Important,Fixed] http://bugs.debian.org/857903
<nacc> Unit193: i guess due to being in universe
<nacc> Unit193: someone has to care enough :)
<Unit193> s/$/ to fix in Ubuntu/ :>
<nacc> Unit193: yeah :)
<nacc> Unit193: i can merge it now, actually, one sec
<Unit193> deluge --version â deluge: 1.3.15
<Unit193> nacc: Cool, it's pretty easy, and hopefully one way or another won't be needed for long. Debian #863288
<ubottu> Debian bug 863288 in deluge "deluge: Recommend python-appindicator" [Wishlist,Open] http://bugs.debian.org/863288
<nacc> Unit193: uploaded to artful
<Unit193> Danke.
<nacc> Unit193: np
<nacc> rbasak: if you happen to be available in the AM, i'd apreciate a few minutes to go through what i have for the srcpkg stuff
#ubuntu-devel 2017-05-26
<Logan> nacc: we didn't use to have locales-all :)
<nacc> Logan: ah ok, so it can be dropped?
<Logan> yup
<nacc> Logan: thanks!
<est31> hi, I'm not sure whether this is the right place to request this
<est31> but the currently available version of VLC in ubuntu has an open CVE
<est31> upstream has released a fix, and it has made it into debian unstable
<est31> https://packages.debian.org/sid/vlc
<est31> https://packages.ubuntu.com/zesty/vlc
<est31> can maybe the vlc update be backported?
<dax> est31: it is CVE-2017-8312 or a different one?
<ubottu> Heap out-of-bound read in ParseJSS in VideoLAN VLC due to missing check of string length allows attackers to read heap uninitialized data via a crafted subtitles file. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8312)
<est31> CVE-2017-8312 it is, yes
<est31> see http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2017-May/058651.html
<ondrej_> Hi, has anyone successfully integrated git-buildpackage with backportspackage from ubuntu-dev-tools?
<acheronUK> does 'apt-file update' download the contents for people in artful 3.1.4 version?
<acheronUK> had to downgrade to zesty's 2.5.5ubuntu1 here to restore functionality
<Unit193> acheronUK: That hooks into apt's download method, so contents are updated when you 'apt-get update'
<jamespage> cyphermox: thanks for the MIR review of vine :)
<acheronUK> Unit193: except, that they are not
<acheronUK> Unit193: ummmm. looks like it might be an old apt.conf workaround lurking and interfering
<Unit193> acheronUK: Think you're going to need to be a little more verbose on that one.  The nice part about it is that it works on both styles.
<acheronUK> one I added I mean. sigh
<Unit193> Aha, I see.
<Laney> ondrej: what would you be after there?
<Laney> branching / tagging?
<Unit193> acheronUK: I kind of wonder what might be screwing that up.
<acheronUK> Unit193: a workaround to get rid of "W: Target Contents-deb-legacy (Contents-amd64) is configured multiple times in /etc/apt/sources.list:3 and /etc/apt/sources.list:16"
<acheronUK> messages
<acheronUK> when apt sees say a "deb http://archive.ubuntu.com/ubuntu artful main restricted" line
<acheronUK> and a "deb http://archive.ubuntu.com/ubuntu artful universe" one
<Unit193> Ahhh, I see.  That's an unimportant one, and I didn't hit it this time anyway so maybe that's been modified (or maybe this sources.list is...More likely.)
<acheronUK> Unit193: this is an upgraded zesty box, so my sources.list was just a sed replacement
<acheronUK> maybe one from a clean install would be fine
<ondrej> Laney: I have a set of custom scripts that I run from gbp repository to build for distributions in DISTS="foo bar baz" and upload them to specified PPA.  It seemed like most of the custom script would be replaceable with backportpackage, but it operates only on .dsc files, so there's a missing step between 'gbp buildpackage' and backportspackage
<ondrej> e.g. something like ability to run `gbp buildpackage --debuild='backportpackage -d $DIST .'` would be very helpful
<Laney> Mmm
<Unit193> acheronUK: Yeah mine is a bit non-standard: http://paste.openstack.org/show/610708
<acheronUK> Unit193: and is quite similar to what I've just switched to
<acheronUK> going to do some artful iso install tests soon, so I'll take a look at what the default from those look like now
<Unit193> It splits the different sections out.
<Unit193> I'm not entirely sure if 'Ubuntu' proper installs have universe commented out?
<acheronUK> I'll have to check. If one from a default install gives me those errors, I'll know there is still some residual apt config weirdness left over from zesty
<acheronUK> Unit193: for now, thanks :)
<Unit193> Those warnings will likely remain, fyi.  But 'welcome.  I like this update partially due to the fact it works in Ubuntu as well as external repositories (including my own.) vs the old one that had to be patched to work with Ubuntu repos, thus broke on external.  However, this newer one has poor backwards compatibility.
<Unit193> Eg, ubottu won't like it.
<ondrej> Laney: I guess I can make a wrapper that would call dpkg-buildpackage -S and then call backportpackage on the result, but it seems like missing functionality from backportpackage
<est31> dax: are you looking at the issue, or should I ask somewhere else
<ondrej> Laney: so, the only thing missing in backportpackage is the ability to pass unknown (or -- prefixed) arguments to the builder
<Laney> ondrej: k, I guess this sounds like a bug against lp:ubuntu-dev-tools
<ondrej> Laney: done (https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1693766), thanks for being listening ear
<ubottu> Launchpad bug 1693766 in ubuntu-dev-tools (Ubuntu) "[feature request] pass unknown arguments to backportpackage to the builder" [Undecided,New]
<sergiusens> slangasek apw is it ok to build click with --disable-packagekit ... the api seems to have changed in xenial since this was last built
<slangasek> sergiusens: does the package currently ftbfs without this change?
<sergiusens> slangasek: I haven't tried on its own, but could; I did not touch that part of the code
<sergiusens> one sec
<slangasek> well, we wouldn't want to change that without a specific reason
<cjwatson> click should do that by itself if the version range is such that the plugin would be unbuildable
<cjwatson> see debian/rules and debian/packagekit-check
<cjwatson> sergiusens,slangasek: ^-
<cjwatson> I'm a little surprised that this would have been broken in xenial; but it's only needed by the phone
<sergiusens> slangasek: so ignore me
<sergiusens> ah, thanks cjwatson was just looking at that
<sergiusens> cjwatson: and no, not broken in xenial; I was trying to move the plugin forward and had some left over code when I tried it on xenial
<sergiusens> sorry for the confusion
<cjwatson> good stuff
<nacc> anyone else getting SSL cert verification for `pull-lp-source` or `syncpackage` ?
<nacc> *verification failure
<powersj> nacc: yes
<powersj> I did a pull-lp-source about 30mins ago fine, now it seems to give me SSL cert failure
<nacc> powersj: ok, glad it's not just me -- same symptoms (working fine before)
<cjwatson> nacc,powersj: yep, looks like a slightly busted cert renewal on launchpadlibrarian.net.  chasing via sysadmin
<nacc> cjwatson: thanks!
<cjwatson> fixed
<nacc> cjwatson: confirmed, thanks!
<jbicha> bdmurray: it looks like phased-updater stopped working yesterday
<jbicha> https://people.canonical.com/~ubuntu-archive/phased-updates.html
<sergiusens> slangasek: apw cjwatson https://code.launchpad.net/~sergiusens/click/package-rename/+merge/324689
<mdeslaur> anyone have an idea why diaspora-installer is failing in the autopkgtests?
<mdeslaur> xnox: perhaps you? ^
<xnox> mdeslaur, #EOW #OnHoliday #StillWorking
<infinity> mdeslaur: Because it's a flaming heap that pulls a bunch of gems from the interweebs and slaps it all together.
<infinity> mdeslaur: If you wanted a more in-depth analysis of why ruby and/or those gems suck on some arches, I don't know. :P
<mdeslaur> infinity: ah crud, can we push mysql-5.7 out then?
<infinity> mdeslaur: Yeah, I might just badtest diaspora-installer for now.  It was (differently) broken in yakkety too, almost seems like a miracle that it was occasionally functional in zesty.
<mdeslaur> infinity: thanks
<dax> est31: I got as far as "there's no Launchpad bug for it" and went to bed, sorry. Hopefully someone else in here knows the process better.
<stgraber> sil2100: please reply in LP: #1693538
<ubottu> Launchpad bug 1693538 in ubuntu-community "Please grant colin-king PPU rights for zfsutils-linux and spl-linux" [Undecided,New] https://launchpad.net/bugs/1693538
<apw> stgraber: it will be zfs-linux and spl-linux
<apw> (of course I understand I do not speak for them)
<stgraber> apw: yeah, figured it was zfs-linux but I'd like the DMB to confirm
<nacc> jbicha: i know you're not a kde developer, but I would appreciate some eyes on LP: #1451728 -- two packages ship the same file in ubuntu (account-plugin-google, kde-config-telepathy-accounts)
<ubottu> Launchpad bug 1451728 in kaccounts-integration (Ubuntu) "[master] kde-config-telepathy-accounts package install error" [Critical,In progress] https://launchpad.net/bugs/1451728
<jbicha> wow, that's a lot of dupes
<nacc> jbicha: yeah
<nacc> jbicha: and a lot of spam and angry users :)
<nacc> makes for hard reading
<nacc> but, at least, in zesty, it appears they no longer conflict
<nacc> http://paste.ubuntu.com/24671827/
<nacc> jbicha: i was going to look at it in depth next week, but I believe you are much better versed with the desktop side, so just wanted to bring to your attention. I think any user could get into that situtation with installing multiple desktop envs
<jbicha> if it is already fixed in zesty, hopefully it will be easier
<nacc> jbicha: yeah, i just hadn't tracked down (yet) what the fix was
#ubuntu-devel 2017-05-28
<augu> what format should system tray (notification area) icons be? Mine keeps getting a black line below it like it's the wrong format.
<slangasek> xnox: LP: #1694156 for great justice
<ubottu> Launchpad bug 1694156 in systemd (Ubuntu) "systemd-resolved and libvirt dnsmasq instance get into a busy loop when a query is issued for a URI record" [Undecided,New] https://launchpad.net/bugs/1694156
<slangasek> mdeslaur: is LP: #1694161 of interest to you?
<ubottu> Launchpad bug 1694161 in libvirt (Ubuntu) "libvirt should register its dnsmasq with systemd-resolved, and set a suitable domain for lookups (e.g. 'libvirt.')" [Undecided,New] https://launchpad.net/bugs/1694161
<gsilvapt> hello all. I want to use lxd to test snaps and other apps and make sure I'll not harm my system. however, it is not very clear how should I set things up. Could someone give some guidance?
<WillyTheBig9143> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug
<WillyTheBig9143> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug
<Erebus3666> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.fr
<Erebus3666> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.fr
<Marielle> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.freedesktop.o
<Marielle> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.freedesktop.o
<ubottu> Launchpad bug 1686329 in Ubuntu "System freezes randomly after upgrading to ubuntu 17.04" [Undecided,Confirmed]
<ubottu> Launchpad bug 1674838 in linux-hwe-edge (Ubuntu) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [Undecided,In progress]
<ubottu> Launchpad bug 1680904 in linux (Ubuntu Zesty) "duplicate for #1693357 zesty unable to handle kernel NULL pointer dereference" [High,In progress]
<ubottu> Launchpad bug 1680904 in linux (Ubuntu Zesty) "zesty unable to handle kernel NULL pointer dereference" [High,In progress]
<ubottu> Freedesktop bug 99295 in DRM/Intel "[Regression BDW] kernel panic in Intel i915 module, complete system freeze in 4.10-rc2" [Blocker,Resolved: fixed]
<Maria563> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.freed
<Maria563> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.freed
<WillyTheBig9143> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug
<WillyTheBig9143> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug
<Marielle> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.freedesktop.o
<Marielle> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.freedesktop.o
<p_teen_girl632> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.
<Johnny3736> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?
<p_teen_girl632> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.
<Johnny3736> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?
<daniel_3896003> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c2
<daniel_3896003> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c2
<Erebus3666> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.fr
<Erebus3666> DONT USE UBUNTU 17.04 UNTIL THE LAZY FAGS OVER AT UBUNTU FIX THESE ISSUES (UNLESS YOU WANT YOUR PC TO FREEZE LIKE A MOTHER FUCKER ===> https://bugs.launchpad.net/ubuntu/+bug/1686329 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1693357 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680904  https://bugs.freedesktop.org/show_bug.cgi?id=99295#c22 https://bugs.fr
<dobey> wow, such hate
#ubuntu-devel 2018-05-21
<hyperair> o/ can removed packages be SRU'd back into an already released ubuntu release?
<hyperair> cjwatson: ^
<hyperair> https://launchpad.net/ubuntu/+source/openscad/+publishinghistory for context
<LtWorf> anyone has anything to do with upstream mongodb? their ubuntu repo repo.mongodb.org makes very policy-outdated packages that don't work with systemd
<LtWorf> (found out at work we were using that on a server, don't know why)
<rbasak> LtWorf: sorry, no, you'll have to report that with them.
<rbasak> LtWorf: they do have a public bug tracker (jira).
<LtWorf> rbasak: was hoping someone had an account already
<LtWorf> anyway i just wiped it and got the ubuntu one :)
<rbasak> LtWorf: I do have an account, but I won't put my name to a report without verifying it first, and that's much more work than for someone who already has confidence in a report to sign up.
<LtWorf> ok
<rbasak> tsimonq2: if it's not too much effort, could you please rebase your add-lubuntu git-ubuntu branch onto current master?
<rbasak> That would include the CI fixes and we should be able to get CI passed then.
<tsimonq2> rbasak: Sure, but it wil end up being after you EOD.
<rbasak> tsimonq2: np, I can land it together. I've already started a one-off catchup from your list.
<rbasak> Uh
<rbasak> s/together/tomorrow/
<powersj> If I got to http://manpages.ubuntu.com/manpages/man1/systemd-resolve.1.html it automatically takes me to Xenial's man page. At somepoint will this change to bionic?
<Nafallo> powersj: after 18.04.1 I'd suspect
<xnox> powersj, i think the answer is never, unless you figure out the branch this thing is deployed from and make a merge proposal =/
<powersj> xnox: dpb1 and I found it
<powersj> working through it
<dpb1> xnox: :)
<rbasak> tsimonq2: one thing I forgot to mention. We still consider the imported branches unstable - there will be a non-fast forwarding reimport/breakage of everything at some point in the future.
<rbasak> tsimonq2: currently we lose all MPs (landed or not) against the imported repositories when we do that.
<tsimonq2> Is that planned?
<tsimonq2> (Meaning, can you let me know when it happens?)
<rbasak> tsimonq2: yes it's planned, and we can pre-announce it
<rbasak> (not planned with a date yet, just planned)
<rbasak> We have a bunch of bugs we want to fix first
<tsimonq2> OK
<tsimonq2> Thanks.
<rbasak> https://bugs.launchpad.net/usd-importer/+bugs?field.tag=hash-abi-break
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<rbasak> That needs updating :-/
<rbasak> tsimonq2: ^
<tsimonq2> Oh hi.
<Laney> rbasak: I think you just need to do !dmb-ping is <new text> to update it
<rbasak> !dmb-ping is cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<rbasak> "Your edit request has been forwarded to #ubuntu-ops"
<rbasak> Laney: thanks!
<rbasak> Normally I'd ping the others to let them know what I just did. I think I probably don't need to on this occasion :)
<hggdh> rbasak: just updated
<rbasak> Thanks!
<sil2100> Awesome, thanks!
<hggdh> (I did not do it, wxl did :-)
<teward> anyone know if it's possible to find out specific details from inside an autopkgtest run?
<teward> because nginx is failing for the searx autopkgtest, but the actual failing component is uwsgi
<teward> not nginx, and I can't see the uwsgi fail reason because the way systemctl handles it suppresses all error output unless you go and get it from `systemctl -l status uwsgi`
#ubuntu-devel 2018-05-22
<cpaelzer> pitti: hiho, what is actually the convention on the autopkgtest users password (if ther is any)
<cpaelzer> for a test that runs with needs-root anyway (so I know I'm root)
<cpaelzer> I'd need to know its PW
<cpaelzer> I could of course just set one via e.g. usermod -p - if that is allowed and not breaking the test
<pitti> cpaelzer: there isn't any really
<cpaelzer> IIRC we get the special root access via the tty
<cpaelzer> and that is it
<cpaelzer> so no policy beyond that special access via the tty then?
<pitti> cpaelzer: if you need a password, the test should set it by itself (and declare breaks-testbed)
<cpaelzer> yep I'll do so
<pitti> cpaelzer: special access via tty is only for qemu; there you of course need to specify the password on the CLI (but not in the test!)
<cpaelzer> I just didn't find a doc clearly stating on or the other, so I wanted to ask
<cpaelzer> thanks pitti!
<pitti> cpaelzer: but setup-testbed actually creates a systemd unit that just offers a root shell on ttyS1 :)
<pitti> which avoids knowing any password
<tjaalton> so are we dropping support for running native i386 in 18.10?
<tjaalton> seems not decided yet
<Unit193> I liked the "heavily warn, but allow it up until the next LTS" method.
<pitti> seems safer to not allow it at all now, to avoid getting people stuck on short-lived releases
<tjaalton> yeah, I'd drop it from 18.10
<Unit193> pitti: Given that some LTSes are only 3 years, one really doesn't gain time.
<tjaalton> still longer than "until next lts"
<tjaalton> besides, kernel support is shared by all
<Unit193> Sure, just personally I'd prefer to roll with the normal releases until then.  I do have some 32bit only stuff still. :3
<pitti> Unit193: what happened to 5 years?
<Unit193> pitti: Eg, Xubuntu never did that.  Only 3.
<Unit193> Same with a few other flavors.
<tjaalton> and what does that mean exactly? that they don't provide fixes to the desktop packages? everything else in main will still get updates
<Unit193> Except that all of Xfce is in universe, soo..
<tjaalton> so?
<tjaalton> I said main, which has a lot of libraries I bet the xubuntu bits depend on
<Unit193> Of course they do.
<tjaalton> and looks like it uses firefox as the browser, which is probably the most security sensitive app on it
<Unit193> Arguably openssl, I'd say. :>
<tjaalton> still supported
<Unit193> I'm aware, yes.  Point isn't "What's an LTS mean?" though.
<didrocks> bdmurray: hey, any update on https://code.launchpad.net/~didrocks/ubuntu-release-upgrader/add_telemetry/+merge/345088? I added more metrics after our last week discussion with j_ibel
<bdmurray> didrocks: Oh, I didn't see the updates. I'm not clear on the answer about the "From" distro.
<bdmurray> didrocks: and when I said From I meant "To"
<didrocks> bdmurray: look at the README on https://github.com/Ubuntu/ubuntu-report
<didrocks> bdmurray: you have a lot more information reported than installer or upgrader one
<didrocks> one of them is "Version", which is basically the "To"
<bdmurray> didrocks: What if it crashes before the upgrade completes?
<didrocks> bdmurray: no Upgrade telemetry file present
<didrocks> if the user can still boot a bionic session, they will have the other info
<didrocks> but not upgrader specific ones
<bdmurray> didrocks: I'm sorry but I'm not following. Why would the upgrade telemetry file not be present?
<didrocks> bdmurray: well, you mentioned if "it" crashes, I think you meant "it" being do-release-upgrader
<bdmurray> didrocks: I did
<didrocks> if do-release-upgrader crashes, then, the upgrade file isn't present as it's saved whenthe upgrade completesâ¦
<bdmurray> didrocks: So we'll only have information on succceses?
<didrocks> bdmurray: we send the information after first login on a new release for the user
<didrocks> so if the upgrade or install fails, we don't send those possibly corrupted metrics
<didrocks> this is where whoopsie should trigger and report the crash
<didrocks> but completely unrelated to hardware and other report info
<bdmurray> Okay, and are you looking for me to just approve the MP?
<didrocks> bdmurray: yes, if you don't spot any obvious issue or typos :)
<bdmurray> didrocks: Okay, thanks for talking it through with me!
<didrocks> thanks for the review! ;)
<slangasek> infinity, kees, stgraber, mdeslaur: TB posers meeting?
<infinity> wxl: *nudge*
 * wxl awakens from his slumber
<infinity> wxl: Can you apply another month or two of "democracy, what democracy?" to https://launchpad.net/~techboard/+members ?
<infinity> wxl: We're also chasing down the whole election business, promise. :P
<wxl> ok
<infinity> wxl: Thanks!
<wxl> np
<wxl> supposedly owners are supposed to get those messages but it didn't come. i'll mail the cc so they're informed
<infinity> slangasek: We're good through Aug 03, if you can manage to get someone's attention about an election before then. :)
<slangasek> infinity: k
<wxl> infinity: slangasek: to be clear, what's lacking? what resources do you need? can we/i help?
<slangasek> wxl: someone with authority needs to call for candidates and run an election.  That's ultimately probably only sabdfl, but perhaps the CC can help
<wxl> slangasek: i'll ask the cc about that and get back to you
<wxl> slangasek: anything else?
<slangasek> wxl: that's all, thanks :)
<wxl> slangasek: infinity: do you have an easy way of generating emails to send to the appropriate ubuntu developers for the tb elections?
<slangasek> wxl: I do not
<wxl> oh nevermind
<wxl> i found it
<elim_garak> is anyone here an admin or moderator for the ubuntu mailing lists?
<elim_garak> I cant subscribe to ubuntu-bugs to save my life
<elim_garak> ive tried to send emails to subscribe to the mailman system, ive tried emailing the admin of the list. nothing
<elim_garak> ive checked my junk, spam, everything. I'm not getting emails from the list
<elim_garak> and, i cant subscribe to any ubuntu list
<wxl> did you use the form elim_garak https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs ?
<elim_garak> yes
<elim_garak> never get the confirmation email
<elim_garak> was hoping an admin or mod could manually add me or test sending me something
<nacc> well tht wasn't one of the things you mentioned above :)
<wxl> i'd advise checking with #canonical-sysadmin as that sounds like a general issue that may affect more than your ability to subscribe
<elim_garak> ty will do
#ubuntu-devel 2018-05-23
<eoli3n> Hi, on 16.04 repo, "ubuntu-drivers autoinstall" installs intel-microcode if needed. On 18.04, it doesnt.
<eoli3n> Is there any way to change the string of the guest session name ?
<eoli3n> in lightdm ?
<rbasak> nacc: could you remind me of an example where bug 1755247 happens please?
<ubottu> bug 1755247 in usd-importer "Duplicate import tags not implemented" [Undecided,Fix committed] https://launchpad.net/bugs/1755247
<rbasak> I can't find anything in MPs / current docs.
<ricotz> mdeslaur, hi :), is there some progress regarding clamav 0.100.0?
<mdeslaur> ricotz: nobody is working on it
<ricotz> mdeslaur, oh really, I see
<mdeslaur> ricotz: it doesn't contain any CVE fixes, so the security team isn't working on it. Not sure who else works on it.
<ricotz> mdeslaur, ok, thanks for the info
<nacc> rbasak: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+ref/importer-fix-tests first comm
<nacc> rbasak: but basically anytime we see a (source pkg, version) tuple from Launchpad with new contents
<nacc> rbasak: doc/SPECIFICATION.tags as well
<rbasak> nacc: I was looking for a reference that named a source pkg and version where that happened
<nacc> rbasak: uh ... i'd need to look
<nacc> rbasak: all of the packages with the orphan tag bug will show it, i think
<nacc> as reimport tags == orphan tags
<rbasak> OK, thanks
<rbasak> So s_moser most recent bug should be an instance of that, right?
<nacc> yeah, i think so? i mean, in theory, any orphan tag that used to exist would now be a reimport tag
<rbasak> OK. I'll dig tommorrow
<wxl> slangasek: infinity: my call for nominations awaits moderator approval on the list
<slangasek> wxl: on which list?
<slangasek> wxl: (whichever list, I don't have mod privs)
<wxl> slangasek: the titular one :)
<wxl> slangasek: also the list seems to suggest otherwise
<slangasek> ?
<wxl> oh
<wxl> nevermind. looking at the wrong list. bah.
<wxl> ok
<wxl> i sent to ubuntu-devel but probably should have sent to ubuntu-devel-discuss
<wxl> s/discuss/announce/
<wxl> you are in control there so let me resend
<slangasek> ok :)
<wxl> ok NOW you can do it slangasek :)
<wxl> thx slangasek
<wxl> @tsimonq2: where/
<udevbot> Error: "tsimonq2:" is not a valid command.
<tsimonq2> wxl: Wrong chan. :P
<wxl> aigh
<Guest20589> I thought I would ask in here so those idiots in #ubuntu hardly ever have a clue. anyone know how to run kexec with kexec-tools by setting it to true and APPEND="/usr/lib/memtest86+/memtest86+.elf"
<Guest20589> would that work?
#ubuntu-devel 2018-05-24
* FilthyJew changed the topic of #ubuntu-devel to: Seeking a lesbian mistress to massage my filthy jewish cunt hole
<FilthyJew> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, lamont, kees, darkwing, Unit193, idleone, dax, infinity, Laney, or slangasek!
-FilthyJew:#ubuntu-devel- SOMEBODY PLZ LICK MY FILTHY JEWISH CUNT HOLE
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | 18.04 released | Devel of Ubuntu (not support or app devel) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | #ubuntu-app-devel for app development on Ubuntu
<steven> morning guys is this the place to ask when the system breaks and ubuntu is at fault (probably due to canonicals live patch)?
<rbasak> steven: no, this channel is for Ubuntu development. For support, try #ubuntu.
<steven> was trying that, but as you might know. it really is hard to get support in there :)
<tjaalton> for livepatch maybe #ubuntu-kernel?
<steven> I'll try that one, thanks!
<cpaelzer> I'm caught in a triangle of dh_installinit/dh_systemd_enable/dh_systemd_start and unable to achive a .service being off and its .socket being running after install
<cpaelzer> I summarized it here http://paste.ubuntu.com/p/PbmwTW6jK3/
<cpaelzer> If anyones dh_ foo is better than mine let me know what you'd suggest I should try
<cpaelzer> FYI for the question above, dropping the sysV script gave me what I wanted, and goging forward that isn't too bad. But if there are suggestions how to do without let me know
<xedniv> anyone here has tips to setup a build host, ex. to rebuild a specific package or packages, maybe including private patches. not necessarily CI, but more or less same capability
<acheronuk> jbicha: can you or anyone else please no change rebuild openexr? looks like the original sync built against the old ilmbase as new was not published, hence it depends on that and is blocking its own transition
<jbicha> acheronuk: that's not the blocker, the blockers are perl (some autopkgtests got stuck in RUNNING), jemalloc (was synced from experimental but FTBFS so
<jbicha> maybe it and the things built against it should be removed from cosmic-proposed) and python-numpy (FTBFS on armhf)
<jbicha> I found those by looking in excuses for openexr (see blender and exactimage)
<jbicha> I couldn't figure out what I need to do with a cookie or something for ./retry-autopkgtest-regression to work (for perl)
<acheronuk> jbicha: the openexr in -proposed depends on libilmbase12 (>= 2.2.0), so that is VERY much oart of the issue
<acheronuk> *part
<jbicha> acheronuk: oh ok, sure I can rebuild it then, maybe slangasek can handle jemalloc and the perl retries when he's around
<acheronuk> jbicha: ./retry-autopkgtest-regression --help tells you what to so with the cookie I think?
<Laney> --state=RUNNING
<Laney> but it's OK, I did that for you
<jbicha> acheronuk: I read that but it wasn't working for me. I use Firefox
<acheronuk> printf "autopkgtest.ubuntu.com\tTRUE\t/\tTRUE\t0\tsession\tVALUE\n" > ~/.cache/autopkgtest.cookie
<jbicha> the documentation there seems a bit too sparse
<acheronuk> VALUE is replaced by you cookie data
<acheronuk> *your
<acheronuk> jbicha: you may have to find a browser extension to get the data
<jbicha> oh it works now, that's weird
<jbicha> thanks :)
<acheronuk> \o/
<acheronuk> :D
<odyssey4me> cjwatson hi again, remember me looking at why the hash retrieval isn't working quite right.. I have a new log: https://gist.github.com/odyssey4me/549131501f752dfe957d1ec151d62914
<odyssey4me> I *think* that's telling me that the mirror isn't doing the 2-step updates right. It'd be useful to get that confirmed.
<odyssey4me> If so, would using archive.ubuntu.com give me a better experience?
<cjwatson> odyssey4me: Right, that looks like a classic case of putting the new InRelease file in place before the by-hash files that it references.  If you have some way to contact the mirror.rackspace.com admins then please do; the fix may be as simple as https://wiki.ubuntu.com/Mirrors/Scripts?action=diff&rev1=17&rev2=18, but failing that they can contact me at cjwatson@ubuntu.com and I can help them out.
<cjwatson> odyssey4me: archive.ubuntu.com indeed doesn't suffer from this problem AFAIK.
<cjwatson> odyssey4me: Though it may well be slower / more expensive / whatever depending on your network environment.
<odyssey4me> cjwatson thanks - will follow up with them, they're already considering revisiting the scripts for the child mirrors
<odyssey4me> apparently they're using some other script which has a lot more to it, so it's not really a copy-paste situation :/
<odyssey4me> thanks for listening though, and I'll put them in contact with you if they would like any clarification - appreciate that
<cjwatson> odyssey4me: I thought they might be.  I'd be happy to debug it if they don't see the problem.
#ubuntu-devel 2018-05-25
<voxadam> I don't know if this is the right place to ask about infrastructure but it's all I could find.
<voxadam> I'm downloading an image from fwts.ubuntu.com and for some reason it's incredibly slow, <500 KB/s.
<voxadam> It looks like fwts.u.o is a CNAME for cranberry.canonical.com.
<eoli3n> Hi, session-wrapper doesn't work anymore on ubuntu 18.04, any help to find a quick workaround would be appreciated
<eoli3n> bug is pretty easy to reproduice
<eoli3n> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1773189
<ubottu> Launchpad bug 1773189 in lightdm (Ubuntu) "session-wrapper not working anymore" [Undecided,New]
<eoli3n> session-wrapper var from lightdm, i mean
<eoli3n> fixe
<eoli3n> d
<seb128> wgrant, cjwatson, can we get cosmic translations open?
<GunnarHj> seb128: Even if translations for cosmic is opened, bionic should keep being in focus until 18.04.1 has been released, right?
<seb128> GunnarHj, yes
<GunnarHj> seb128: ok
<GunnarHj> seb128: Another translation matter: The email conversation about langpack updates we had with sil2100 halted. Do you have any further input before you leave for vacation?
<seb128> GunnarHj, we should do a full langpack refresh before .1 I think
<seb128> but that's something for the second half of june imho
<seb128> I'm going to be back before that
<GunnarHj> seb128: Yeah, it's my understanding that we have an agreement so far. I was rather thinking about a possible update for 16.04.5. But also that can probably wait until you are back.
<cjwatson> seb128: I'll have a look on Tuesday.  It's a somewhat delicate operation and has gone wrong in ways requiring database surgery in the past, so I don't really want to try it on a Friday afternoon.
<seb128> cjwatson, thanks (and fair enough for waiting newt week)
<seb128> GunnarHj, well, that doesn't require me, but +1 on having a refresh on 16.04
<GunnarHj> seb128: The question I raised was if a 16.04 refresh would be done for all languages or only tested ones. In case of the latter I suppose it's not sufficient for the gnome-software update you mentioned, or..?
<seb128> GunnarHj, we should perhaps bundle the translations in gnome-software in xenial, it change more than langpacks are able to
<sil2100> GunnarHj: I think we only discussed the matter of releasing all translations for .1's
<sil2100> GunnarHj: not for all point-releases
<sil2100> GunnarHj: I'm +1 on .1 having a full language update, I have mixed feelings about doing the same for .5 - I'd stick with the previous schema
<sil2100> GunnarHj: could you schedule a langpack update for .5?
<sil2100> (on the translation release schedule that is)
<GunnarHj> seb128: Yeah, bundling them in xenial for g-s is probably the way if we don't skip the test requirement.
<GunnarHj> sil2100: Ok, that clarifies your view. Sure, I can add a .5 round for xenial langpack updates.
<sil2100> GunnarHj: it's that for xenial IIUC we didn't have a full langpack update for a long time, and without any automated testing I wouldn't suddenly want to break translations for some languages that we didn't test
<GunnarHj> sil2100: Right, that's how the procedure has been for quite some time. But in the mail I mentioned that Martin apparently made an exception for 14.04.5.
<GunnarHj> sil2100: (Which in effect made all the previous test efforts for 14.04 meaningless.)
<sil2100> It was a bold move! I mean, probably the risk of getting things busted is low
<sil2100> But I'd really like to have some bare sanity-tests before we do things like this so late in a series life-cycle
<sil2100> I already talked about this to get it prioritized enough so I can work on it
<sil2100> Anyway, whatever we decide ultimately getting a call for testing and release scheduled for an export before .5 is needed
<GunnarHj> sil2100: Great. I'd really like to consider the approach for 18.04.2+.
<GunnarHj> sil2100: Yeah, let's treat 16.04.5 in accordance with the established procedure.
<cascardo> https://bugs.launchpad.net/ubuntu/cosmic/+source/nbd/+bug/1772024
<ubottu> Launchpad bug 1772024 in nbd (Ubuntu Cosmic) "linux 4.13.0-42.47 ADT test failure with linux 4.13.0-42.47 (nbd-smoke-test)" [High,In progress]
<cascardo> can anyone review/sponsor my debdiff for nbd? target is cosmic
<smoser> seeing this again
<smoser> Could not establish FTP connection to upload.ubuntu.com: timed out
<smoser> got through that time. took 15 or 20 times in a loop
<cjwatson> smoser: cause is known, doesn't need further reports
<cjwatson> (SAN is failing; daily apt-ftparchive DB vacuum therefore sends that system's load through the roof for a while each day; see https://rt.admin.canonical.com/Ticket/Display.html?id=111700 for planned remediation steps)
<smoser> cjwatson: sorry to pester. thanks.
<femme> https://iapp.org/resources/article/guide-to-basic-data-anonymization-techniques/
<acheronuk> would someone be kind enough to no change rebuild field3d and pink-pony against new ilmbase? they are blocking transition of that and openexr
<ginggs> acheronuk: looking
<acheronuk> ginggs: thanks. they may be the last 2 things to depend on the old libilmbase12
<ginggs> acheronuk: ok done, but where do you see they are the last 2 things?
<acheronuk> ginggs: comparing reverse depends of libilmbase12 and libilmbase23 in cosmic release and -proposed respectively
<ginggs> acheronuk: ok, i'll take your word for it
<acheronuk> time will tell. that's why I said 'may be'. thanks :)
<Unit193> Hello!  What are the chances dh-autoreconf can see a backport to bionic? :)
<nacc> rbasak: do you need anything from me currently re: git-ubuntu?
#ubuntu-devel 2018-05-26
<bluesabre> slangasek: I don't see a way to submit MRs in Launchpad for +junk branches... would you mind merging https://code.launchpad.net/~xubuntu-dev/+junk/update-seeds into https://code.launchpad.net/~ubuntu-archive/+junk/scripts ?
<bluesabre> also submitted https://code.launchpad.net/~xubuntu-dev/ubuntu-cdimage/git_seed/+merge/346912 :)
<slangasek> bluesabre: lp:~xubuntu-dev/+junk/update-seeds merged. For cdimage, please see my review comments on the MP
<ErichEickmeyer> Hey, if anybody is available that wouldn't mind jumping in to #ubuntustudio-devel for our meeting at 19:00 UTC to answer some questions about snaps, that would be awesome.
 * Son_Goku jumps to channel
<tsimonq2> slangasek: I thought you were going to convert that junk repo to an actual one? :P
<Unit193> Any progress on LP 1636666?
<ubottu> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,Confirmed] https://launchpad.net/bugs/1636666
#ubuntu-devel 2018-05-27
<m4t> hi, does anyone know if there are plans to update gcc-8 on 18.04 to the actual 8.1 release? or will it remain as the 8.0 devel version?
<m4t> i've got it from the ppa but i just saw breakage w/rt "libobjc4 : Depends: gcc-8-base (= 8-20180414-1ubuntu2) but 8.1.0-1ubuntu0.1"
<enyc> What is the right channel to get help with sortunig out debsign to behave iwth gpg key already registered in launchpad and dput and all that to get a PPA content uploaded properly?
<cjwatson> All you should need is DEBSIGN_KEYID=your-key-fingerprint in ~/.devscripts
<cjwatson> (replace as necessary; e.g. mine reads DEBSIGN_KEYID=AC0A4FF12611B6FCCF01C111393587D97D86500B)
<enyc> cjwatson: aaaaaaaaaah that works where putting into environment demporarilaly didn't !
<enyc> cjwatson: thankyou
<cjwatson> Right, as the man page notes, environment variables are ignored for that purpose.
<cjwatson> np
<enyc> dpkg trying and both firels give Valid signature but now ...  Checksum doesn't match for [...] -xenial-ppa.dsc
<enyc> I may need to clearout source directories and all and go aback to the dpkg-source --commit stage now i have benterr idea what im' doing and the sign-key thing setup properly...
<enyc> Why-oh-why-oh-why is   packages.ubuntu.com  not showing  trusty-* and xenial-*  now! grr...
#ubuntu-devel 2019-05-20
<juliank> does this sound familiar to anyone? https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829735
<ubottu> Launchpad bug 1829735 in apt (Ubuntu) "Fresh install of 18.10 stuck at initializing ramdisk after sudo apt upgrade" [Undecided,New]
<juliank> The bug is like in a super wrong place
<xnox> jamespage:  yes.
<jamespage> xnox: ok I'll ping you when I have something
<jamespage> thankyou
<rbalint> ddstreet, do you plan uploading/sending an MP for LP: #1829347 ?
<ubottu> Launchpad bug 1829347 in systemd (Ubuntu Eoan) "systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug" [Medium,In progress] https://launchpad.net/bugs/1829347
<rbalint> ddstreet, it is the only test failing for me when running the autopkgtest locally for bionic
<ddstreet> rbalint https://code.launchpad.net/~ubuntu-support-team/ubuntu/+source/systemd/+git/systemd/+ref/next-e
<ddstreet> there are other tests i'm fixing as well :)
<ddstreet> i plan to upload next week
<ddstreet> well, after your systemd uploads wraps up
<ddstreet> https://bugs.launchpad.net/ubuntu/+source/systemd/+bugs?field.tag=ddstreet-next
<ddstreet> rbalint you can run your ppa builds thru autopkgtest.ubuntu.com to look for other-arch failures, too
<rbalint> ddstreet, regarding LP: #1829347 how about depending on linux-image-generic to pull in extra modules including scsi_debug?
<ubottu> Launchpad bug 1829347 in systemd (Ubuntu Eoan) "systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug" [Medium,In progress] https://launchpad.net/bugs/1829347
<rbalint> (with the autopkgtest)
<ddstreet> sometimes you can't unload it
<ddstreet> and linux-image-generic won't work for all systemd tests run via non-basic kernel triggers
<rbalint> i see
<ddstreet> i'm fixing the test failure; figuring out better ways to avoid skips should be separate
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
#ubuntu-devel 2019-05-21
<seb128> xnox, hey, pointing bug #1829829 in case it's useful, saw it while doing some triaging
<ubottu> bug 1829829 in systemd (Ubuntu) "Ubuntu CI has been flaky for a week" [Undecided,New] https://launchpad.net/bugs/1829829
<seb128> but I guess that's a probably an issue you are already aware of?
<seb128> rbalint, btw did you see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929229 (was raised on bug #1803993)
<ubottu> Debian bug 929229 in systemd "systemd, udev -- keyboard freezes after exiting X in version 241-4" [Serious,Open]
<ubottu> bug 1803993 in systemd (Ubuntu) "Password appears on the VT1 screen" [High,In progress] https://launchpad.net/bugs/1803993
<xnox> seb128:  i am aware, do not have solution/fix yet. didn't investigate yet.
<seb128> k
<xnox> seb128:  rbalint: re X regression. rbalint should we revert the upload in eoan?
<rbalint> xnox, seb128 yes, i saw it and i started looking into it
<rbalint> xnox, seb128: the regression still seems to be better than leaking passwords and breaking keyboard on gdm after a few logouts, but i'm also open to reverting it until everything is sorted out
<rbalint> xnox, with or without the revert i think it would be be beneficial to have ddstreet's autopkgtest fixes in eoan and in old releases even going in ahead of the VT fix
<seb128> rbalint, is the autopkgtest issue understood/has a fix? see backlog, x_nox said it was not investigated yet?
<xnox> seb128:  there are some pending autopkgtest fixes; and i think there are some new regressions too.
<rbalint> seb128, there is an approved mp https://code.launchpad.net/~ddstreet/ubuntu/+source/systemd/+git/systemd/+merge/366857 and i think xnox referred to the vt regression as not being fully understood
<rbalint> seb128, xnox locally systemd autopkgtest passed for me for cosmic and up, but storage test always failed in bionic
<xnox> rbalint:  storage test is worked on; so that's ok.
<ddstreet> seb128 re: lp #1829829 the problem is most of the time after the testcase issues a reboot, autopkgtest-virt-ssh can't reconnect to the testbed, but it's only for amd64 and i386 archs
<ubottu> Launchpad bug 1829829 in systemd (Ubuntu) "Ubuntu CI has been flaky for a week" [Undecided,New] https://launchpad.net/bugs/1829829
<ddstreet> i suspected there's some problem with the prodstack intel-based instances being used, since i think the other archs use different testbed deployment methods, but i have no access to any of it so i can't tell
<seb128> ddstreet, did you try to ask vorlon / Laney / juliank about the prodstack thing?
<Laney> you mean scalingstack, fwiw
<Laney> xnox got pinged about that and it is on his list to look at
<seb128> thx
<jamespage> wgrant, xnox: do you happen to know how big an filesystem and PPA builder has? I think I've just seen one pop with builds for latest ceph release
<xnox> jamespage:  i can't remember, maybe it was like something like 40gb or 60gb
<cjwatson> jamespage: 60GB I believe
<jamespage> ok
<jamespage> monitoring how big it gets to see
<cjwatson> ceph wouldn't have been the first source package I'd pick to be likely to run it out of disk
<cjwatson> though OK, last build in disco apparently took nearly 50GB
<jamespage> I got a load of unable to copy file errors during the install pahse
<cjwatson> some time spent working out what's quite so fat might be well-spent
<cjwatson> expanding requires having cloud space to expand all the instances so may not be straightforward
<jamespage> ack - will dig on this - I have one suspect that might make a difference
<xnox> i hit disk limit before when mongo accidentaly went to build every single little test case binary, with 2GB of debug symbols statically linked....
<jamespage> hmm
<jamespage> eoan-amd64      915G   63G  806G   8% /run/schroot/mount/eoan-amd64-f0f14aa3-e236-4c78-a327-37af1bff86ad
<ahasenack> seb128: thanks for triaging https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1829772
<ubottu> Launchpad bug 1829772 in samba (Ubuntu) "The Samba 'panic action'" [Undecided,Incomplete]
<seb128> ahasenack, np!
<seb128> ahasenack, there has been a few samba segfault report in recent bugs, I wonder if of the recent security update has a regression
<seb128> ahasenack, but those reports don't really have enough data so it's difficult to say...
<ahasenack> yeah
<ahasenack> and no core attached
<ahasenack> "It appears to be caused by receiving SMB requests from the Internet." wrote one
<seb128> juliank, hey, have you seen reports like https://errors.ubuntu.com/problem/bcd4cb93a6d3f4bb93cc6ea7534e293f4a744849 before?
<seb128> it was flagged as a software-properties regression in the recent bionic SRU but that code seems rather aptdaemon/existing
<seb128>     from aptdaemon import client
<seb128>   File "/usr/lib/python3/dist-packages/aptdaemon/client.py", line 1570
<seb128>     async = reply_handler and error_handler
<seb128> which triggers a
<seb128> SyntaxError: invalid syntax
<juliank> seb128: ack, another python3.7 ? issue
<juliank> Haven't seen them, but async became a keyword or something
<juliank> So gotta rename async to async_handler or similar
<seb128> why is that only an issue now?
<seb128> hum, my bionic machine is python3.6
<seb128> did those users change their default python?
<seb128> ah, that was fixed in https://launchpad.net/ubuntu/+source/aptdaemon/1.1.1+bzr982-0ubuntu20
<seb128> that should be SRUed to bionic I guess then, if we have users updating their python to 3.7 in that serie (or are we doing that for them?)
<juliank> seb128: people do sometimes mess up their systems, yes
<seb128> juliank, mwhudson, can you handle SRUing that to bionic?
<seb128> it looks like we are getting users opting in for using python 3.7 by default on bionic
<seb128> we should probably deal with that...
<juliank> seb128: we should tell them don't do that
<seb128> doko, vorlon, ^opinion about that?
<juliank> seb128: We do not build most of the modules for 3.7, so there's no way switching to 3.7 works
<juliank> Which  makes me wonder if those are botched 18.04->18.10 upgrades
<juliank> or actually, botched discos
<seb128> unsure
<seb128> that bucket got flagged as a software-properties SRU regression and blocking that SRU
<juliank> That should certainly be ignored
<seb128> k, thx
<vorlon> seb128: they get to keep both pieces if they do that, yes.  I don't think we have a good way to tell users not to clobber python3 on the path with something not from the python3 package.
<sarnold> while we're on this topic, this bug sure looks like a user changing /usr/bin/python -- but the Dependencies.txt attachment doesn't show anything wrong for the python-minimal package https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1829857
<ubottu> Launchpad bug 1829857 in python-django (Ubuntu) "package python-django 1.6.11-0ubuntu1.2 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [Undecided,New]
<sarnold> does dependencies.txt [/broken/path] annotations not catch symlinks going to the wrong plcae?
<vorlon> sarnold: yeah we're probably unfortunately reliant on the dpkg md5sums, and symlinks have no md5sum so
<vorlon> bdmurray: ^^ is that a limitation you're aware of?
<sarnold> vorlon: dang. thanks for giving it a look
<bdmurray> sarnold: what does "[/broken/path] annotations" mean?
<sarnold> bdmurray: in https://launchpadlibrarian.net/424709223/Dependencies.txt the bit "initramfs-tools 0.131ubuntu19 [modified: usr/sbin/update-initramfs]
<bdmurray> sarnold: I don't think so and that's why I added this https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/eoan/apport/ubuntu/view/head:/data/general-hooks/ubuntu.py#L526
<sarnold> bdmurray: YES! :D Thanks!
<bdmurray> sarnold: bug 1681528 - I guess it wasn't SRU'ed
<ubottu> bug 1681528 in apport (Ubuntu Artful) "Include information about python versions" [High,Fix released] https://launchpad.net/bugs/1681528
#ubuntu-devel 2019-05-22
<doko> seb128, vorlon: you get these errors when you have 3.7 installed, and then install a module that is not yet ready for 3.7. For bionic and cosmic there were some ... However people don't want to fix those anymore, and sometimes it's difficult because new upstream versions are involved.. Not sure if it's worth turning 3.8 byte compilation off for 3.7 in bionic, or ignore any errors?
<jamespage> xnox: either I'm missing something or that was easier than I expected
<jamespage> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3535/+packages
<jamespage> has the updates smartmontools for eoan; I've upgrade checked and validated it works against some devices I have on my laptop
<jamespage> seems to work fine
<xnox> jamespage:  hdd sdd nvme?
<jamespage> xnox: nvme
<jamespage> just finding an sdd to test on
<xnox> packaging changes look good, good libsystemd-dev catch
<jamespage> xnox: I need to detail stuff in the changelog
<jamespage> I thought I had done that but will do so
<jamespage> need to doc the patches as well
<jamespage> I appear to have given you something a bit half documented - lemme fix that up
<xnox> yeah normally one rm's the patches, instead of commenting out. and like mention "drop this and drop that, merged upstream"
<jamespage> xnox: just needed to refresh my built source package - must have had a crufty one lying around
<jamespage> xnox: http://paste.ubuntu.com/p/954Fw7pW6C/ debian folder diff - just rebuilding and re-validating
<jamespage> xnox: hmm the use of libsystemd and the switch to Type=notify for the smartd daemon has a slightly nasty side effect, in that if there are no smart capable devices, the unit hard fails...
<xnox> lovely
<xnox> it shouldn't be even started then......
<xnox> does udev kick smartmontools into action at all?
<jamespage> xnox: not that I can see
<xnox> fun
<xnox> but i thought previous initd script also failed, if one didn't have anything to monitor..... maybe a non-regression?!
<jamespage> xnox: it did but the non-zero exit did not cause the systemd unit to fail to start
<jamespage> as it was not of type notify, whereas now it is
<xnox> fun
 * jamespage scratches his head...
<jamespage> xnox: I'm tempted to drop the systemd/notify integration to maintain the status quo for the time being
<xnox> jamespage:  heh
<xnox> i cannot say that i have never done that
<vorlon> infinity, kees, seb128, mdeslaur, stgraber: I'd like to add xnox and mwhudson to https://launchpad.net/~ubuntu-langpack/+members so they're able to inject subiquity .pot files into the Ubuntu namespace manually in launchpad, for the Ubuntu translation teams to pick up (since we update subiquity as a snap and not as a deb); any objections?
<stgraber> fine with me
<infinity> vorlon: Sounds reasonable.
<seb128> vorlon, +1 from me
<mdeslaur> vorlon: fine with me
<ahasenack> seb128: debian has also gotten reports of crashes after the samba update, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929268
<ubottu> Debian bug 929268 in samba "samba: Samba segfault" [Normal,Open]
<ahasenack> they tracked it to upstream's https://bugzilla.samba.org/show_bug.cgi?id=13315
<ubottu> Error: Could not parse XML returned by bugzilla.samba.org: mismatched tag: line 100, column 4 (https://bugzilla.samba.org/show_bug.cgi?id=13315&ctype=xml)
<seb128> ahasenack, ah good, thx for letting me know, it did looked like a regression with those new reports!
<seb128> ahasenack, did you point it to mdeslaur? (I think he did that security update)
<ahasenack> not yet, but I updated all bug reports with a pointer to the upstream bug
<ahasenack> I'm trying to reproduce it, the description made it sound simple, but I'm failing so far
<ahasenack> mdeslaur: https://bugzilla.samba.org/show_bug.cgi?id=13315 might be a regression introduced in the recent samba security updates
<ubottu> Error: Could not parse XML returned by bugzilla.samba.org: mismatched tag: line 100, column 4 (https://bugzilla.samba.org/show_bug.cgi?id=13315&ctype=xml)
<seb128> thx
<mdeslaur> seb128, ahasenack: ack, thanks, I'll look at it tomorrow morning
<seb128> mdeslaur, great, thx!
<ahasenack> mdeslaur: I pinged upstream to see if they have a simple reproducer
<seb128> vorlon, thx for reverting the n-m/bionic-updates SRU version, as much as I like to go back to square 1 on that SRU it's probably the right thing to do :/
<ahasenack> also, none of the bug reports we got had logs or a crash file attached, one guy didn't even know he had samba installed
<seb128> kenvandine, tkamppeter, ^ if you didn't notice, the n-m/bionic SRU got reverted until we figure out those regressions
<seb128> ahasenack, I wonder if the samba custom handler is make apport not trigger maybe?
<ahasenack> could be
<seb128> if so we should probably distro patch the custom handler out
<seb128> apport gives us debug retraces and metrics
<vorlon> seb128: yeah, sorry, I had thought already about reverting it on Sunday when I saw the reports had come in, and your latest mail spurred me to finally get it done.  I'll try to also follow through on your mail today
<seb128> vorlon, thx, sorry to bother you guys with that, we lack proper knowledge of the networking stack in desktop atm which is something we need to fix (unless foundations takes over n-m, but I don't think that's likely to happen)
<kenvandine> seb128: thanks
#ubuntu-devel 2019-05-23
<alkisg> Hi, the latest netplan broke ltsp booting; we mark the boot interface as "manual" in /etc/network/interfaces (and I tried marking it manual in network manager too), but netplan now somehow manages to remove its ip while the computer netboots
<alkisg> `rm /lib/systemd/system-generators/netplan` bypasses the problem; but what would be the correct way to tell netplan not to touch the netboot interface?
<alkisg> I think the relevant SRU that caused the regression was this one: https://bugs.launchpad.net/netplan/+bug/1763608
<ubottu> Launchpad bug 1763608 in netplan "Netplan ignores Interfaces without IP Addresses" [Undecided,Fix committed]
<alkisg> cyphermox: ? (sorry for the ping, please ignore me if busy or if it's inappropriate)
<alkisg> Netplan generates this file, while AFAIK it shouldn't, as enp0s3 is declared manual in /etc/network/interfaces:  /run/systemd/network/10-netplan-enp0s3.network ==> https://termbin.com/51oc
<alkisg> I commented in https://bugs.launchpad.net/netplan/+bug/1763608/comments/43
<ubottu> Launchpad bug 1763608 in netplan "Netplan ignores Interfaces without IP Addresses" [Undecided,Fix committed]
<tkamppeter> seb128, thanks, have already seen the posts from slangasek on the bugs yesterday.
<seb128> tkamppeter, np
<tkamppeter> seb128, kenvandine, looks a little bit like that the upstream version update from 1.10.6 to 1.10.14 is of too high impact (whereas a raise of only the micro release number should only add bug fixes).
<tkamppeter> Seems we need to carefully select the upstream commits which only fix the bugs the users have complained about and make an SRU out of these.
<seb128> tkamppeter, it's trying to address difficult problems, we did discuss other ways but those were not easier
<seb128> I don't think that's true
<seb128> we need to figure out that specific regression and sort it out and try again
<Laney> yep
<seb128> upstream seems supportive/ready to help but we need someone who understands the topic to have the conversation
<seb128> dwmw2 seems to be engaged and to understand the problem, so maybe he's that person
<seb128> but we should still engage/worth with him/them
<tkamppeter> seb128, I have also tried one thing: I have asked the posters of the regression whether it helps to also install the systemd SRU (which I have therefore uploaded to my PPA), but got two negative answers on that (was simply trying a low-hanging fruit).
<seb128> tkamppeter, you should probably be on #nm btw, that's the upstream channel
<seb128> they discussed it a bit earlier and said that
<seb128> "<thaller> dwmw2_gone, bengal, the discussion there is long and not clear (to me). Also, there is a lack of logfiles to even understand what is actually happening. Anyway, to my understanding, setting "dns-priority=-1,dns-search=~." is not a "workaround". By default, NM's VPN profiles want to do split-dns and not full-tunnel. So, you need to explicitly configure avoiding "dns leaks". Whether that default is good or not is a separate question he
<seb128> re."
<seb128> anyway, I think what we lack at this point is someone on our side who understands the topic/components and can figure out what's going on exactly and talk with upstream
<seb128> I'm not sure how we solve that gap
<seb128> either by doing the needed studying or by involving people on our side who have the expertise I guess
<seb128>  
<seb128> is error.u.c timing out for others?
<seb128> ah, it's back
<seb128> I just had to ask, it was failing to load for 10 min or so :p
<rbalint> juliank, i think apt should tell me if i just ran apt update or apt upgrade on a release which left the standard support period
<rbalint> juliank, i think it would be helpful on systems not showing motd, such as docker or wsl
<juliank> ack
<juliank> we can add that to ua client
<juliank> I think
<juliank> It's a bit tough to figure out if you're unsupported or not
<juliank> (from C++)
<juliank> oh hang on
<juliank> With trusty esm it basically hints very strongly after upgrade, as it will tell you there are ESM updates
<juliank> It might be worth telling people there release is in ESM now, or especially if it is EOL
<rbalint> juliank, i think we should cover interim releases, too
<rbalint> juliank, and clearly telling it is maybe better than just hinting it
<rbalint> juliank, on zesty i see ... old-releases.ubuntu.com ... in apt update's log which is a hint, but i share rcj's concern that some users are still left on unsupported releases because the did not notice the hints
<rcj> rbalint: how did you get that?  shouldn't it just try archive.ubuntu.com and fail due to lack of Release files?  What changed your zesty machine to old-releases.ubuntu.com?
<rbalint> rcj, maybe me, just forgot that :-)
#ubuntu-devel 2019-05-24
<seb128> SRU team, could you review those uploads libxmlb in bionic/NEW , then fwupd in bionic and fwupd-signed in bionicNEW? they have been sitting there unreviewed for some weeks and oem is waiting on them
<Laney> bdmurray: are you aware of the error tracker being quite unresponsive lately?
<tjaalton> seb128: sru team can't handle NEW
<tjaalton> not all of us anyway
<tjaalton> only AA's
<seb128> tjaalton, should I just accept it myself then? ;)
<seb128> or does it still need to go through the sru-accept script or whatever?
<seb128> I guess best is to have a SRU team member who is AA to accept it
<tjaalton> if it's not on the queue anymore, then the next step is to accep it from new?
<tjaalton> *accept
<seb128> you mean not in the queue?
<seb128> tjaalton, https://launchpad.net/ubuntu/bionic/+queue?queue_state=0
<seb128> it's still there
<tjaalton> unapproved queue, which the sru team handles
<tjaalton> fwupd is
<tjaalton> also, generally #ubuntu-release is a better fit for sru pings
<tjaalton> so things are not lost in noise
<seb128> should I ask there again?
<tjaalton> nah
<seb128> tjaalton, since we are speaking SRU, could you review/approve the update-notifier/bionic one I just uploaded? it's some fixes to the current one that failed verification
<SwedeMike> tty0: /win 207
<SwedeMike> oops
<seb128> tjaalton, should be an easy one, it's some lines of python diff which are pretty simple
<juliank> So
<juliank> PackageKit installs multiple service files
<juliank> It runs        dh_installsystemd --no-enable --no-start --no-restart-after-upgrade
<juliank> which is OK for packagekit.service and offline-upgrades.service
<juliank> but I'm adding the user/pk-debconf-helper.socket, and I do need that enabled
<juliank> do I have to make two calls, one for existing units, and one for the socket?
<juliank> Oh I guess I should just ship a symlink
<LocutusOfBorg> juliank, hello, any reason for not having forwarded dkms patch upstream? https://github.com/dell/dkms/commits/master
<juliank> no reason
<blackflow> Hello, trying to figure out how to find deb src source that's actually used to produce .deb files, through LP. In particular I'm interested into the linux kernel package, I wanna see the patches Ubuntu is adding.
<LocutusOfBorg> juliank, will you do it, or shall I do? I don't honestly want to touch your patches, but I can do if needed
<LocutusOfBorg> blackboxsw, pull-lp-source linux gets the latest version in development (needs installed ubuntu-dev-tools)
<LocutusOfBorg> otherwise apt-get source does the job I guess
<Unit193> dget https://path/to/package.dsc is nice.
<juliank> LocutusOfBorg: does not make sense to forward really
<juliank> LocutusOfBorg: It's only needed for shim_secureboot_support.patch
<juliank> and that's not upstream eithert
<blackflow> LocutusOfBorg: well the thing is, `apt-get source linux`   doesn't seem to include the patches...
<blackflow> Could someone please direct me to the source code of the final, binary Linux(tm) kernel package as distributed and installed in "Ubuntu(tm) Linux 18.04.2 Bionic Beaver", I believe the redistributed binary package is linux-image-4.15.0-50-generic.  I am unable to locate the (reproducible) source and lack of such access is GPL violation. Under GPLv2 provision 3, subsection (A), the binary package
<blackflow> must be accompanied "with the complete corresponding machine-readable source code". It is not.
<Unit193> Oh hah, someone goofed: gcr-viewer.desktop:X-GNOME-Bugzilla-Component=gcrX-Ubuntu-Gettext-Domain=gcr
<cjwatson> There's no GPL violation, we absolutely provide the source.  https://launchpad.net/ubuntu/+source/linux/4.15.0-50.54 has it if you can't get apt-get source to work
<cjwatson> (Our processes are such that it's not possible for us to provide binaries in Ubuntu without the source also being available)
<cjwatson> If you're having a technical problem with the build then #ubuntu-kernel will probably be better-able to help
<cjwatson> The linux package doesn't break out its patches into separate files, but there's no GPL requirement for that - they're just applied directly to the unpacked source package that apt-get source linux gives you
<cjwatson> If you're trying to trace individual patches then https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic might be more helpful
<juliank> Will be uploading aptdaemon in a minute
<juliank> Fxed the test suite
<juliank> :)
<juliank> Let's turn all those red autopkgtests green again
<rbasak> blackflow: what Colin says - we do publish the source, through the "apt-get source" mechanism. If you can't figure out how to use our tooling, then you're welcome to try and get help here, but your technical inability to deal with our preferred tooling is not a GPL violation and screaming about it here is only going to put people off helping you.
<rbasak> blackflow: and no, there is no requirement in the GPL that binary packages include their sources. No binary distribution does that. We do publish the sources alongside in the apt repository, which has long been considered sufficient by all those in the community. Debian does it the same way.
<blackflow> cjwatson: separate patches would be nice, but I can always diff myself, if I knew what to compare and I don't because the whole process is not transparent. Even now with the links you gave I am not sure which, of the gazillion links that follow from there, is the source code for the redistributed binary installed on my PC.
<rbasak> blackflow: there is nothing special or obscure here. It works the same as any other Debian package.
<blackflow> rbasak: fine, but published _where_. How do I find them.
<cjwatson> blackflow: The three files under Downloads
<cjwatson> .orig.tar.gz, .diff.gz, .dsc
<cjwatson> dpkg-source -x foo.dsc then unpacks that
<juliank> this is not rocket science
<blackflow> rbasak: and that's not true. I found Debian's sources, with patches, with literally three links from packages.debian.org. I'v been trying to find the same/similar via LP for over an hour now.
<cjwatson> But this is just the same as what apt-get source linux should already have given you (possibly modulo minor version differences)
<rbasak> blackflow: packages.ubuntu.com also exists.
<juliank> blackflow: Go to https://launchpad.net/ubuntu/+source/linux
<juliank> blackflow: Click the version
<juliank> blackflow: There are three files under downloads
<juliank> blackflow: Download them
<juliank> blackflow: dpkg-source -x them
<juliank> blackflow: And you are done
<blackflow> juliank: thanks.
<juliank> If you want the individual patches / commits on top of the combined diff, clone the git repository listed in Vcs-Git
<juliank> or just do debcheckout linux
<juliank> Ran 79 tests in 58.138s
<juliank> OK (skipped=22)
<juliank> WOOOHOO
<juliank> Gotta SRU the test suite fixes with the other stuff, so we get proper SRUing for aptdaemon
<blackflow> wel I don't need the patches per se as much as I need to find what exactly is Ubuntu adding to the kernel.org sources.
<blackflow> which I would from teh patches, or, lacking them, from a diff, but for that I need it to be transparent enough to know what is what.
<juliank> well, that's in the .diff.gz
<juliank> the patches are applied directly to the upstream source from the .diff.gz
<juliank> there are no debian/patches
<blackflow> I see. but is there no versioning tracker for those modifications?
<juliank> There's a git repo
<juliank> the diff.gz is the diff from the git repo to the upstream one
<Unit193> I believe the git repo was linked to you twice now.
<juliank> the git repo even has tags!
<blackflow> Unit193: Yes, I'm looking through it right now.
<blackflow> problem is, this is a black box, nearly impossible to understand, to an outsider like me (and I'm not a noob in coding or contributing to open source packages). Of course this is easy for y'all, Dunning-kruger and all. It is extremely frustrating to someone else.
<blackflow> and by "this" I mean the millions of repos, subrepos, links, tarballs, versions, subversions, etc... with no documentation or indication as to what is what.
<juliank> It's not a blackbox
<juliank> it's standard tooling
<cjwatson> It's an inherently complex system, though we're gradually working towards doing everything in a more consistent set of git repositories; it'll take time
<juliank> It's listed in Vcs-Git, it can't get easier than that
<juliank> I want to find the source code: I run apt source linux; oh I want git, let me look at Vcs-Git
<cjwatson> (Also I'm not quite sure that Dunning-Kruger is the study you're reaching for here, unless you're saying we're all too incompetent to know our own limitations, which doesn't make sense with the rest of your sentence)
<juliank> ooh it's there, let me clone that repo
<juliank> -> done
<juliank> works on a lot of packages
<juliank> (some do have debian vcs-git but ubuntu changes, but linux is not one of them)
<cjwatson> Eventually "git ubuntu clone linux" will work consistently
<Unit193> 'linux' isn't the least complex either though, most packages just have changes stacked on top whereas linux acts more like a fork, I'd think.
<cjwatson> I don't know whether it yet does
<juliank> linux is complex in that the signed binary is produced by linux-signed
<blackflow> cjwatson: no I was referring to the other side of the effect. you're too skilled and too knowledgeable about these processes to understand how it looks like to someone who is not.
<juliank> so source linux-image-$(uname -r) gives you the wrong package
<cjwatson> As a matter of fact I do understand that it is complicated, but I think you're overstating somewhat based on my experience with other people
<juliank> blackflow: this is basic debian packaging
<cjwatson> Most people don't jump straight to GPL violation :)
<cjwatson> We're working on improvements
<cjwatson> But throwing metaphorical rocks doesn't really help
<blackflow> no I stand behind what I said. this is all easy-pease, "standard this", "standard that", to someone who's neck-deep into the process for years. the violation is that somoene who got the binary part, does not have obvious access to the soruces. they're buried under layers and layers and layers of abstraction and redirection of a megaton of repos, subrepos, links, versions, ...
<blackflow> sans teh typos.
<juliank> no they're not
<juliank> the number of layers is the same as for debian to get to working source code
<juliank> then there is one more layer if you need individual changes
<cjwatson> You're massively overstating things.  "apt-get source linux" gives you the source.
<cjwatson> That's not a megaton of repos and subrepos and stuff.
<blackflow> and yes, GPL _does_ require sources accompany the redistributed binary. Provision 3(A) of GPLv2 (under which the kernel is licensed). Unless you want to redefine the word "accompany".
<juliank> And they do
 * cjwatson is out of this conversation since it isn't productive
<juliank> Both binaries and source are in http://archive.ubuntu.com/ubuntu/pool/main/l/linux/
<juliank> they are also both in launchpad
<LocutusOfBorg> blackflow, did you try... pull-lp-source linux bionic?
<LocutusOfBorg> easy, and works with every launchpad package/distro
<LocutusOfBorg> in a consistent way
<LocutusOfBorg> even version
<LocutusOfBorg> even old version
<sladen> blackflow: there is a significant overlap in people + technology + source code between Debian and Ubuntu: people who care about source availability and being able to recompile from scratch
<LocutusOfBorg> I really don't get all this kind of troubles, apt-get source or pull-lp-sorce works both on my bionic machine, as well as dpkg-buildpackage seems to be running on kernel
<sladen> blackflow: there are *multiple* versions of "the source code" for a package (ie. "linux" kernel), *and* multiple ways of obtaining the source code: which *exact* version, and which *exact* method is not working---we would love to fix it if there is something broken
<sladen> blackflow: please can you past the *exact* commands being used: then we can help pin-point any errors
<sladen> paste
<rbasak> blackflow: from a GPL compliance perspective, it's best to just consider "apt-get source" _the_ way of doing it. No other layers of abstraction. The same apt repository ships all sources for all its binaries, side-by-side.
<blackflow> sladen: I got the diffs now (see above), after asking here.
<rbasak> blackflow: if you think that's a GPL violation in itself because the sources aren't shipped inside the binary packages, then that's your opinion, but I don't think it would match the opinion of anyone involved, not even the FSF. Debian does it the same way, and I believe Trisquel (FSF-endorsed) probably does too.
<blackflow> rbasak: no, I think the frustration to get to the sources is the violation.
<rbasak> blackflow: what's wrong with "apt-get source"?
<blackflow> but neway, I got the diffs now, thanks.
<blackflow> rbasak: which package name? :)
<blackflow> because sources for linux-image-$(uname -r) ain't int
<blackflow> *it
<rbasak> blackflow: clearly it's not reasonable to block outsiders from access that insiders have. But I don't see how the GPL requires anything further than that.
<rbasak> As I say, I don't think that community consensus (across the entire ecosystem) expects anything further. Clearly the majority of people in the world won't know how to get the source regardless of what we do.
<rbasak> The only standard is that it's available to the same level that we access it ("preferred source")
<rbasak> And we do meet that.
<juliank> rbasak: the only real-ish problem is that linux-image is built by linux-signed and you need to figure out that it gets the binaries it signs from linux
<juliank> that's a small discoverability problem
<blackflow> rbasak: maybe I'm just spoiled by distros like gentoo which have a very straightforward (and easily accessible) path to the sources (even if you forget teh fact that you literally get teh sources via portage first thing). after working with gentoo (and FreeBSD) packages and sources, I found myself in the Twisty Passages, all alike, in the Ubuntu world.
<sladen> "straight-forward"
<rbasak> blackflow: it could be better, yes. We're working on that. However it's not really significantly different from Debian (certainly any Debian developer wouldn't have a problem finding Ubuntu sources), and the reason it's like this is that Debian pre-dates all modern tooling.
<rbasak> (unless you count CVS)
<sladen> blackflow: please make a suggestion for how to make it *even* more "straight-forward"
<rbasak> sladen: "where can I git clone the sources for package X from?"
<rbasak> I think in the modern era that's a reasonable request.
<juliank> portage is a lot less straight forward
<rbasak> But we (and Debian) predate git.
<juliank> It does not even ship the source code alongside the patches
<juliank> same for freebsd ports
<sladen> blackflow: would eg.    git clone ubuntu:linux    for straight-forward/enough, or could things be made even simpler?
<blackflow> rbasak: it's much different (and easier) with Debian.  https://tracker.debian.org/pkg/linux-latest    and there's a Browse Source Code link on the right, poof done.   It is NOT like that in Ubuntu. The repo you linked above is not the one you get from the linux package in LP.
<rbasak> blackflow: and how did you find tracker.debian.org?
<blackflow> and I got to that tracker page easily, "Developer Information" from here: https://packages.debian.org/buster/linux-image-amd64
<blackflow> so the binary package name led me to the source in three clicks.
<blackflow> rbasak: I asked google, just like I asked google for Ubuntu.
<TJ-> how about teaching apt-get source the option of using the Vcs-*: field of the package control file to do a suitable VCS clone of the source (which includes commit history) as opposed to just a snapshot fetch of the source as it does by default?
<Unit193> TJ-: That's what `debcheckout` does.
<juliank> TJ-: It tells you to use debcheckout
<juliank> TJ-: Well, to git clone the repo
<juliank> git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/disco
<juliank> to retrieve the latest (possibly unreleased) updates to the package.
<juliank> is precisely what it says
<juliank> blackflow: So, and for portage or freebsd ports it's _a lot_ harder
<sladen> blackflow: equivalent of packages.debian.org is packages.ubuntu.com  https://packages.ubuntu.com/eoan/linux-image-generic
<TJ-> juliank: isn't that only when you're already doing "apt-get source <package>" though? it's not the same as being able to do "apt-get  source --vcs <package>" which is what I'm suggesting
<LocutusOfBorg> with a "download source package" in only one click
<rbasak> blackflow: start from https://packages.ubuntu.com/, search for the filename whose sources you're interested in, go to that package, see "Download Source Package" on the right.
<blackflow> sladen: yes. And how many clicks to reach the source from there?
<LocutusOfBorg> blackboxsw, ONE
<LocutusOfBorg> one single click
<LocutusOfBorg> directly on the page
<juliank> TJ-: Well, yes, but you do have a Ctrl and a C key
<LocutusOfBorg> "Download Source Package linux-meta: "
<blackflow> no, that's for linux-meta
<juliank> And the Debian one is for linux-latest
<LocutusOfBorg> ok two clicks
<LocutusOfBorg> you click on the actual package, in this case https://packages.ubuntu.com/eoan/linux-image-5.0.0-15-generic
<LocutusOfBorg> and then download source package
<juliank> it's impossible to get from the source code from there
<LocutusOfBorg> still one less click than debian
<blackflow> LocutusOfBorg: still nope, that's linux_signed :)
<rbasak> In any case, I still insist that "apt-get source" is the cleanest way to get the source for the binary that you have just installed (for example), and that is a very well known mechanism.
<blackflow> LocutusOfBorg: do you see my frustration now? :)
<rbasak> We don't control Google so it isn't reasonable to use Google against us just because it doesn't find it easily for you.
<juliank> blackflow: Same problem in Debian
<LocutusOfBorg> blackboxsw, one more click https://packages.ubuntu.com/eoan/linux-modules-5.0.0-15-generic
<LocutusOfBorg> so equal to Debian :D
<juliank> blackflow: Just that in Debian, your kernel package will be named linux-signed
<blackflow> juliank: I beg to differ. I found the debian source in three clicks. I've been looking for the correct one in LP for an hour before I came here, frustrated.
<juliank> Well, linux-image-signed or something
<TJ-> juliank: but the point of all this discussion is about ease of discoverability and capture even when unfamiliar with the Debian/Ubuntu packaging ecosystem. I'm suggesting teaching apt-get to do it, no matter what VCS the package uses (e.g. I have to read man-pages to refresh my mind if it's bazaar, or hg (mercurial).
<rbasak> blackflow: as I said before, your personal inability doesn't make it a GPL violation.
<blackflow> TJ-: sic!
<juliank> TJ-: We're not going to run a command for you based on the control file
<juliank> you can check the command and run it yourself
<rbasak> TJ-: the intention is that "git ubuntu clone" will do it correctly.
<juliank> blackflow: YOu only found the Debian source package because you started from a different spot
<LocutusOfBorg> and yes, sources.ubuntu.com and codesearch.ubuntu.com might be useful
<LocutusOfBorg> ^^
<blackflow> rbasak: but it's not just my personal inability. this is clear and easy for you because you're familiar with the processes and all the repos. It is totally a black box to anyone who is not.
<juliank> If you started from Debian's signed kernel image, you'd end up with the same issues
<rbasak> Though the complexity of mapping for signed kernel packages I don't have a great solution for, except that I hope that one day "git ubuntu clone" will take a file on the local system as input.
<sladen> ...the discussion about how to make finding source *even easier* (than three clicks) is useful to have.   The discussion about not complying the GPL is not useful.  Please try to keep conservation focused on useful suggestions and input
<TJ-> rbasak: OK, so can we teach apt-get to wrap that or state it in help/man-page *before* we've already tried "apt-get source <package>" ?
<juliank> Also, if you get linux-signed you can read the code and figure out where to go next
<rbasak> TJ-: I don't think apt is the right tool for this kind of thing any more.
<rbasak> TJ-: we should document it somewhere, but we should tackle the place that people decide they want to use apt in the first place.
<sladen> eg.   man linux-source
<rbasak> TJ-: if you care about higher level stuff like package mappings, then apt is too far down the stack already.
<juliank> huh
<juliank> no
<Unit193> rbasak: The fourth result for 'ubuntu linux kernel' for me was https://wiki.ubuntu.com/Kernel/SourceCode.  Regardless, I don't see this discussion going anywhere and only expect it'll devolve more.
<TJ-> rbasak: Users go to apt by default for package management; moving away from that just introduces more confusion, as the whole bazaar debarcle demonstrated.
<juliank> Unit193: that page is wrong
<Unit193> juliank: Git section looks right.
<juliank> yes
<juliank> but the other one is not
<juliank> gotta have unsigned somewhere in there
<rbasak> TJ-: I'm not sure what bazaar thing you're referring to, but regardless, apt is about packages in the repository. apt doesn't know (by design) anything above that, such as semantic (as opposed to depends/recommends etc) relationships between packages.
<sladen> blackflow: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug  Please can you file a bug with the title "Make Linux source code even easier to find", and past the bug number here: we can then help to fill out the rest with ideas, and will be able to get back in to contact with you with suggestions are being proposed
<rbasak> sladen: I'm not sure that's the right place. Maybe the Ubuntu top level project? Because (presumably) no fix can be made in the linux package itself to solve this.
<TJ-> rbasak: some packages moved to bazaar VCS, then that got abandoned by some and it became almost impossible to reliable determine where to find the correct source. LP especially made that even more difficult with so many out-of-date repos.
<sladen> rbasak: man page
<rbasak> TJ-: the correct source has always been the source package, since that is the single source of truth
<rbasak> sladen: potentially, but it isn't obvious that's the correct answer, and the answer may be something other than in the linux package.
<TJ-> rbasak: that's silly; most of the time we require the source to see the commit history for e.g. bug-hunting, regression, etc.
<sladen> rbasak: then we can move it as soon as blackflow has successfully opened the bug report
<Unit193> TJ-: Unfortunately, in Debian even the maintainer declared vcs-* fields can be out of date, it's the nature of relying on people that some things are forgotten.
<juliank> we should have hooks for apt source
<juliank> so linux images can hook in and say "you probably want linux not linux-signed"
<juliank> otoh
<juliank> only linux has that problem
<TJ-> Unit193: so a deficiency in the process. Maybe there are ways to automate inclusion of the correct Vcs tag?
<sladen> linux is special ...
<sladen> perhaps a contributing factor
<blackflow> sladen: against what?
<rbasak> TJ-: I'm trying to fix that with git ubuntu. I still maintain that apt isn't the right place to solve this.
<Unit193> TJ-: git-buildpackage and other tools do make it easy, but if people no longer use git, move repos without noting, or simply forget to push...
<sladen> blackflow: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug  would open it against linux.  COuld also, per suggestion of rbasak file it against the top level "Ubuntu".  But we can shuffle it around as sooner is we have the bug number
<juliank> I still maintain that git-ubuntu is not the solution
<TJ-> rbasak: that's fine; what I'm saying is apt should tell us *before* we do "apt-get source <package>" there is a better method, not as an aside whilst it is already downloading the source package
<rbasak> sladen, blackflow: just don't get offended by the autoreplies you get from filing the bug against the linux package, please.
<juliank> like it's OK as a fallback, but you usually want a proper git-buildpackage repo
<juliank> it's just another more convenient layer to get the uploaded source packages :)
<rbasak> If you are an individual package maintainer you probably want a separate repo, yes.
<rbasak> But if you are a drive by contributor then what you want is a consistent view, and separate repos that follow their own policies are not hat.
<rbasak> that
<rbasak> Incidentally, I have a plan to make it possible for your "proper git-buildpackage repo" to _be_ the git ubuntu repo.
<rbasak> But that's quite far down the road.
<Unit193> That seems to favor drive-by people over reg contributors..
<juliank> Also, grab-merge is still a lot easier than git-ubuntu
<rbasak> Regular contributors know what they're doing and so don't need to use defaults.
<TJ-> rbasak: the reason I suggest *before* is that frequently, when I'm travelling with a poor/limited Internet connection, I chose to pull in and browse source related to some bug I'm investigating. So it is frustrating for at least 2 reasons: 1) source download starts before 'apt-get source' tells me where the packaging Vcs is, and 2) Manually trying to discover the authoriative source-code repo for the
<TJ-> binary package version I'm investigating
<rbasak> juliank: history proves you wrong on that. Start using git-ubuntu for merges and you'll continously discover merge errors made by people using grab-merge.
<Unit193> TJ-: apt-cache showsrc $pkg  will show you before you `apt-get source`
<rbasak> juliank: (since grab-merge provides no easy way to check for correctness and humans make mistakes)
<cjwatson> sladen: please remember that when you recommend such URLs to a non-developer they're going to run straight into https://help.ubuntu.com/community/ReportingBugs#Filing_bugs_manually_at_Launchpad.net; better to give an appropriate URL to bypass that, especially when the discussion is already contentious
<juliank> I run grab-merge, edit the conflicts, generate two debdiffs (old and new), then diff the debiffs, and if that looks right, I upload
<blackflow> rbasak: you got any more insults before I wrap this up?
<TJ-> Unit193: yes, but many casual investigators/bug hunters don't know that. If that is so then 'apt-get source' (or its help/man-page) should state that explictly where it is easily discoverable.
<rbasak> juliank: "if that looks right" --> often it looks right but is wrong
<juliank> I don't want to split out individual commits and do rebasing for a simple merge, it's just _a lot_ of effort
<Unit193> TJ-: Also if you are on a limited connection, you can ctrl+c out of the download.
<rbasak> git-ubuntu doesn't _require_ you to split out commits.
<rbasak> If you wish, just use git rebase directly.
<TJ-> Unit193: indeed, but that is a kludge, not a solution to discoverability
<rbasak> That's essentially precisely what MoM does.
<juliank> That only works for throw away the git and upload the dsc scenarios though
<Unit193> TJ-: As I noted, the proper discovery is apt-cache showsrc, or just `debcheckout`.
<juliank> if I want to git ubuntu submit it, people will get nasty
<rbasak> juliank: I think we're conflating a bunch of things here.
<rbasak> juliank: there's git-ubuntu the set of imported repositories. There's the MP flow that the server team is using. And there's the merge workflow the server team is using.
<rbasak> juliank: they don't all have to be used together.
<Unit193> rbasak: I don't suppose git-ubuntu is packaged yet?
<rbasak> juliank: you can use the set of imported repositories only, do it locally using git, and (as a core dev with no peer review requirement) just upload it, if you wish. Nobody will know if you used MoM/grab-merge or git-ubuntu
<juliank> rbasak: Right, but that means you lose git history
<rbasak> Unit193: it is a snap. Packaging in the apt repository is insanely hard because of edge case behaviours in dpkg and that kind of thing.
<Unit193> Hrm, so it isn't. :/
<juliank> also, I think the end goal is to nto upload, but just push?
<rbasak> juliank: no different from MoM. If keeping git history is a requirement for you, then clearly MoM/grab-merge is unacceptable by that definition.
<rbasak> Unit193: what do you mean by "it"? The imported repositories are still available :)
<TJ-> Unit193: I feel we're talking at corss-purposes here. The information is there, yes, but it is buried in a lot of other info. If you don't already know what to look for (not initimately familiar with Debian packaging) it can easily be missed. What I'm suggesting is making discovering the Vcs for the specific binary package  an explicit option of some (apt) tool
<juliank> rbasak: well, yes, but with git-ubuntu there's a history I can render less useful that was not there before
<Unit193> rbasak: git-ubuntu was what I was referring to.
<rbasak> juliank: I don't follow. From my perspective you seem to keep changing your position. What's your actual position?
<juliank> My position is that in order to be considerate to heavy users of git-ubuntu, I have to follow git-ubuntu best practices
<juliank> even if I personally don't care about that
<rbasak> juliank: you mean when you do package merges?
<rbasak> juliank: or other times too>?
<juliank> I guess when merging only
<juliank> or when importing a new upstream version maybe, idk?
<rbasak> I don't think a new upstream version going in without rich history would bother anyway.
<rbasak> s/anyway/anyone/
<sladen> cjwatson: sure.  What URL would be better to give to blackflow?
<juliank> It's one reason I did not merge multipath-tools last cycle; because it is maintained in git-ubuntu, shared with server team; and the process annoys me a lot
<rbasak> It is true that if someone is maintaining (multiple package merges) a particular package using git-ubuntu, then it'll be a pain if you stomp in and do a package merge without the git-ubuntu package merge process, because that'll flatten the breakdown of commits as well as any changes you make.
<rbasak> What we want preserved is the rich version of the Ubuntu delta. We don't care how you get to that.
<cjwatson> sladen: If you're going to direct somebody to file a bug directly against an Ubuntu package where "ubuntu-bug" is inappropriate or not useful, then you need to add ?no-redirect to the end.  But I can't say I'm hugely convinced that the maintainers of the linux source package specifically are in a good position to improve this
<cjwatson> (However I don't really want to get sucked into debating that, so ...)
<juliank> cjwatson: one thing I sometimes stumble upon is that'd I'd like to have https://launchpad.net/ubuntu/+source/<binary>
<sladen> cjwatson: ah yes, kudos for spotting lack of ?no-redirect
<rbasak> If you flatten that, then for a more complex delta I think it's quite right for people to be upset. That isn't git-ubuntu specific though, that's just a quality thing on doing complex package merges in maintainable way.
<juliank> redirecting me to the source package
<juliank> because sometimes I have a binary, and I don't want to do a source package lookup locally first
<Unit193> Like the tracker does.  I hit the tracker, then click the 'ubuntu' button for that. :P
<rbasak> juliank: note that the binary->source mapping changes
<juliank> yes
<rbasak> So you'd need to qualify it somehow to disambiguate, or define some disambiguation algorithm in any case.
<juliank> Look at latest series first, and go downward until you find a match
<juliank> it works reasonably well for Debian tracker
<rbasak> That wouldn't be helpful to users who might be on the previous LTS with a different mapping.
<rbasak> I suppose you could add a UI to ask which the user means.
<rbasak> (as it's a web UI already)
<cjwatson> juliank: Well, they obviously couldn't go under +source.  There actually are binary URLs, but they're some of the worst-linked URLs in LP (https://launchpad.net/ubuntu/bionic/amd64/linux-image-4.15.0-50-generic)
<juliank> cjwatson: Well, I do want the source package for a given binary
<rbasak> Ah yes, because arch matters too :)
<juliank> Like https://tracker.debian.org/apt-utils redirects me to https://tracker.debian.org/pkg/apt
<cjwatson> Yeah, but it still can't be in +source for name-clash reasons
<cjwatson> I agree we could do better
<juliank> Well, if there's a name-clash the source package wins
<Unit193> juliank: I have an alias in my browser, pts apt-utils  will take me there, as uts apt  will take me to the +source page.
<cjwatson> Do file a bug against LP about that, but please in a solution-neutral way (i.e. state the problem that getting from binary to source is harder than it should be, not your specific proposed solution)
<cjwatson> If we were adding something that was potentially ambiguous between binary and source package names then it would need to be in a different bit of URL namespace
<cjwatson> launchpad.net does a lot more varied things than tracker.debian.org does though, and it has to curate its URL namespace a good deal more as a result
<cjwatson> Grabbing whole chunks of arbitrary namespace has historically turned out to be a mistake
<cjwatson> e.g. there's some awkwardness in git URLs because bzr URLs claimed too much of the namespace and that turned out to be a problem n years later
<cjwatson> juliank: Also maybe somebody could consider setting up a tracker instance for Ubuntu?  It seems as though it'd be pretty useful, and it wouldn't have to have the same URL namespacing concerns that LP has
<cjwatson> tracker.ubuntu.com would be a nice thing to have
<juliank> maybe
<juliank> probably needs a lot of work to get something useful
<cjwatson> https://qa.pages.debian.net/distro-tracker/admin/vendor.html   looks like it has at least been considered
<cjwatson> And I see that https://pkg.kali.org/ exists which looks like the same codebase
<juliank> ack
<blackflow> sladen: so the summary of everything is... which package/project should I file a bug against? I know my way around LP and how to file without ubunt-bug
<sladen> blackflow: Plese a bug against "Ubuntu" (eg. the "I don't know" option).  Once the bug report is filed, and we have the bug number, it can be repointed
<blackflow> k, thanks
<blackflow> sladen: is bug #1830379 acceptable?
<ubottu> bug 1830379 in Ubuntu "It is not clear how to install sources for the running kernel" [Undecided,New] https://launchpad.net/bugs/1830379
<sladen> blackflow: thank you!
<blackflow> please let me know if you want me to word it differently.
<sladen> blackflow: wording appears to be fairly neutral and factual.  Thank you
<coreycb> seb128: is there any chance we can push my software-properties change through first since the other has regressions.
<seb128> coreycb, you mean?
<seb128> coreycb, the other is in bionic-updates, rolling got stopped because it has new e.u.c reports
<seb128> I don't think so no
<coreycb> seb128: ah so the regressions are in -updates
<seb128> yes
<seb128> we could stack your changes with the other fixes
<seb128> but I think we better fastrack the regressions fixes
<rbasak> blackflow: that bug report looks fine, thanks. I'm not sure you can expect anyone to work on it, but at least it's a place for discussion.
<coreycb> seb128: either option is ok i guess. happy to help stack if you want to go that route.
<seb128> coreycb, I'm doing a SRU, will probably use 8.1 then but I'm unsure what to do with the vcs
<seb128> there are enough dot, I'm going to do another .9
<seb128> then we rebase yours as .10
<coreycb> seb128: ok
<seb128> I'm pondering going back to .8 in the vcs, doing my changes and pushing --force
<coreycb> seb128: i don't care either way. i would prefer to stack mine in if possible since it's tiny and blocking the cloud archive.
<seb128> bdmurray, tjaalton, other SRU team mamber around?
<seb128> I want to do a software-properties/bionic upload to fix some regressions with the previous SRU (which is bionic-updates)
<seb128> is that fine if that upload includes that change as well? http://launchpadlibrarian.net/423881822/software-properties_0.96.24.32.8_0.96.24.32.9.diff.gz
<blackflow> rbasak: agreed.
<seb128> bdmurray, tjaalton, could you review https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=software-properties ? it fixes some regressions from the SRU that moved to -updates earlier this week and a fix the cloud team is waiting on, would be good to have it in proposed today so we don't delay too much the regression fixes (like we can maybe talk about moving to -updates after the weekend)
<seb128> coreycb, ^
<seb128> coreycb, I pushed -f to the bionic branch, you might want to refetch that
<bdmurray> seb128: I got it
<coreycb> seb128: thanks!
<seb128> bdmurray, thx
<raghu_> hi
<raghu_> i'm new to open source,interested in contributing to ubuntu can someone help me out with links for getting started page, documentation page, beginner friendly bugs
<sladen> hello raghu_: best place is to "scratch an itch".  ie. is there a piece of software, an application, or a menu that you are already using---but perhaps a translation is not quite right, or there is a small bug
<sladen> raghu_: it much easier to start, and drill down with something you already know + care about; then to just generically ask
<ahasenack> dannf: hey, is updating freeipmi on your radar? If not, I was about to start
<dannf> ahasenack: go for it :)
<ahasenack> yay
<ahasenack> we missed updating it for 19.04
<ahasenack> ok, updated the mom page
#ubuntu-devel 2019-05-25
<alkisg> On ubuntu-desktop.iso, `apt install sshfs` needs only 40 Kb. Having sshfs in all .isos and desktop VMs etc would help in a lot of cases;
<alkisg> transferring files from a live session; allowing casper "persistence" over the network; allowing ltsp clients to netboot over stock .isos or VMs...
<alkisg> Would I have any chances requesting to "please move sshfs to main and include it live cds", and if so, where would I file a bug report for that?
<valorie> alkisg: just a guess: filebug against Ubuntu desktop
<alkisg> Thank you valorie
<valorie> or write to that team with your argument
<valorie> or both!
<valorie> be prepared for some arguments against adding even 1k to the ISOs however
<alkisg> That's why I started asking here first, if the idea isn't considered helpful, I don't think it'll have chances to get accepted...
<alkisg> And I think the security team won't like having more packages in main
<Unit193> It's not even in main.
<valorie> I think you should do it anyway and make your arguments
<Unit193> I am not alkisg :)
<valorie> oh, I was replying to alkisg
<valorie> part of the request was moving to main
<alkisg> Sure, I understand two parts are required; and it'll be hard to convince the respective teams for both of them
<raghu_> hi
<raghu_> i'm interested in contributing to ubuntu can someone help me with link to getting started page.
<CarlFK> what is the linux kernel #chan?
<Unit193> #ubuntu-kernel
<CarlFK> Unit193: I mean the mainline one
<Unit193> CarlFK: I'd say you're better off in there, but #linux-kernel does exist in some form or another.
<Unit193> Hrm, now that Edubuntu is discontinued, I wonder if it might benefit some to sync th debian-edu packages again, since they're still maintained in Debian.
#ubuntu-devel 2019-05-26
<alkisg> Unit193: it wouldn't hurt to have the same meta-packages for both debian and ubuntu; no reason to be different if noone in ubuntu is maintaining something different
<alkisg> We're not using them in Greece because we're using greek-only education software instead, but I've heard of schools in other countries using those debian metapackages
#ubuntu-devel 2020-05-18
<dckusr> Thanks for the file fix in ubuntu 16.04 & 18.04 !  https://github.com/tzickel/docker-trim/issues/1#issuecomment-629840844
<ali1234> xnox: that ssl blog would be really handy for me to link on a (private) bug report i'm dealing with... please let me know when it is up :)
<AsciiWolf> kenvandine, hi, regarding the missing _Permissions string translation in Snap Store (#1878672), I was unable to find what exactly is wrong... :/ the string is available for translation on Launchpad and is present in .pot file in snap-store git, however it is untranslated in the actual Snap Store for some reason
<AsciiWolf> (it got translated on Launchpad in my (Czech) language on 2020-04-15)
<ackk> juliank, hi, any chance you could review https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/384013 ?
<juliank> ackk: i feel like renaming the debconf template creates unnecessary churn, but then I don't know much debconf
<ackk> juliank, replied to your comments. yeah as said I did that for the name to be more correct, but I can revert it back, it's not a big deal.
<ackk> juliank, I reverted the debconf change
<juliank> ackk: ok
<juliank> ackk: still needs proper Sru stuff, left comment
<ackk> juliank, I did file an sru bug, it's attached to the MP
<ackk> juliank, also, fixed the release in changelog
<ackk> (https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1878769 FTR)
<ubottu> Launchpad bug 1878769 in maas (Ubuntu) "[SRU] updates to the maas deb2snap package" [Undecided,New]
<juliank> ackk: it's not being closed in the changelog afaict
<ackk> juliank, ah, what's the syntax for that?
<juliank> LP: #number
<juliank> ackk: also s/DEVAULT/DEFAULT ?
<juliank> In the changelog entfy
<juliank> I'm afk for a bit will look after I get back
<ackk> juliank, you mean an additional entry with just that?
<juliank> Usually you put it in () after some entry
<ackk> juliank, thanks. fixed and reordered changelog entries to put actual fixes first
<smoser> so for git-ubuntu, ahasenack added squashfs-tools-ng for me. and it is
<smoser>  https://git.launchpad.net/~usd-import-team/ubuntu/+source/squashfs-tools-ng
<smoser> but then  git-ubuntu clone -v -v squashfs-tools-ng
<smoser> fails
<smoser> i'm' guessing this is because things are moving to a new location ?
<ahasenack> hm
<ahasenack> smoser: interesting
<ahasenack> I see it in https://code.launchpad.net/~usd-import-team/ubuntu/+source/squashfs-tools-ng/+git/squashfs-tools-ng
<ahasenack> but that was via "Other repositories"
<smoser> sorry. missing bit of info.
<ahasenack> rbasak: could you take a look?
<ahasenack> ^
<smoser> i just did
<smoser>  sudo snap refresh --edge git-ubuntu
<ahasenack> I also have r470, v0.10.1
<ahasenack> from edge
<smoser> and you re-create failure, right?
<smoser> i well could have typod
<ahasenack> yes
<smoser> ok
<smoser> that pkg name is a  pita
<ahasenack> I wonder if there is another step for first importers
<ahasenack> I vaguely remember rbasak saying something about the name changing in lp
<rbasak> o/
<rbasak> Yes
<rbasak> bin/update-repository-alias.py from the source tree will do it for all repositories (need to be a core dev)
<rbasak> I don't see an entry point for doing it just for one package
<rbasak> Let me see if I can put something together quickly
<ahasenack> rbasak: I imported two for smoser
<ahasenack> smoser: what was the other one again?
<smoser> i can't remember that long ago.
<ahasenack> rbasak: smoser sbuild-launchpad-chroot is the other one
<smoser> i think you added it in git though
<smoser> right
<ahasenack> rbasak: is that done automatically when we add a package to the whitelist file and restart the importer?
<rbasak> No
<rbasak> It has to be done manually because only core devs can make the change and the importer doesn't have that privilege
<ahasenack> rbasak: oh, that's a loophole
<ahasenack> I think many were added to the whitelist without running that script
<rbasak> It's a recent change that this is required
<rbasak> When I made the change I update everything that was done previously
<rbasak> So it's only new whitelist entries
<ahasenack> better let it run once for all then? Is it a no-op for the ones that don't need it?
<rbasak> It takes quite a long time to run
<rbasak> And I prefer to examine the dry run first, so that takes a while
<rbasak> ahasenack, smoser: https://pastebin.ubuntu.com/p/XgpysnkX4k/
<rbasak> Any core dev can run that after adding to the package whitelist
<rbasak> Any core dev can run that *after the imported repository exists* I mean
<ahasenack> is that a no-op?
<rbasak> It's idempotent if that's what you mean
<rbasak> I ran it already to test
<ahasenack> yes
<ahasenack> ok, also against the sbuild one?
<rbasak> Yes - want me to do that?
<ahasenack> let me try it
<ahasenack> done, worked
<ahasenack> rbasak: smoser
<ahasenack> thanks
<rbasak> yw
<rbasak> Sorry for the pain
<rbasak> I'm working towards importing all packages
<rbasak> So have been spending effort there instead of making adding packages smoother
<ahasenack> rbasak: what if we get a new package in main?
<ahasenack> rbasak: since we import 100% of main
<rbasak> Yes - this will happen
<rbasak> I don't have a good solution to that yet
<ahasenack> it might have happened already, given the MIRs
<rbasak> Probably
<ahasenack> although those were in ~march
<rbasak> Maybe we'll need to periodically run a report and give core devs the exact command to run
<ahasenack> can't the importer do it at import time? Surely it can notice if it's a new package or not
<ahasenack> I know, all a matter of coding
<rbasak> Or maybe Launchpad will take an adjustment to permit the importer to make the change or something without making it a core dev
<ahasenack> but that's the right place, right?
<ahasenack> ah, the perms
<rbasak> Right
<rbasak> I don't want to make the importer a core dev
<rbasak> Feels like overstepping security
<ahasenack> it needs addressing, though
<ahasenack> and screams for automation :)
<rbasak> Agreed
<rbasak> It doesn't bite too often and the solution is non-trivial, that's all. So I never prioritised it.
<The_LoudSpeaker> query: Any way to make "quilt edit" use subl instead of nano?
<rbasak> The_LoudSpeaker: have you tried setting EDITOR?
<rbasak> update-alternatives can always tweak /usr/bin/editor which things generally default to
<The_LoudSpeaker> rbasak: that didn't work :(
<rbasak> !dmb-ping
<ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<The_LoudSpeaker> rbasak: I won't disturb much but yeah I got it working, export EDITOR=subl
<juliank> ackk: sponsored maas. now, you might want to start bugging the sru team at some point if nothing happens
<CarlFK> https://ubuntu.com/download/server/arm "           This is the iso image of the Ubuntu Server installer.         " just above http://cdimage.ubuntu.com/releases/20.04/release/ubuntu-20.04-live-server-arm64.iso
<tumbleweed> CarlFK: your point being "live" ?
<CarlFK> tumbleweed:  "no installer" just above what I am assuming includes an installer on the live CD
<CarlFK> oh helll
<CarlFK> never mind. I misread
<CarlFK> I blame lack of food
<XaT> need real documentation about ubiquity (desktop 20.04), where do i get it ?
<bdmurray> coreycb: should bug 1848519 still be tagged block-proposed? Its blocking panko from migrating in groovy.
<ubottu> bug 1848519 in panko (Ubuntu) "[SRU] fix panko-daemons autopkgtest curl failure" [Medium,Fix committed] https://launchpad.net/bugs/1848519
<coreycb> bdmurray: I'll drop that block-proposed tag
<coreycb> bdmurray: That's dropped, thanks for letting me know.
#ubuntu-devel 2020-05-19
<cpaelzer> paride: as mentioned yesterday https://salsa.debian.org/debian/irqbalance/-/merge_requests/3
<paride> hi cpaelzer , I'm looking at what we have...
<paride> cpaelzer, all the machines I have access to are haswell
<paride> oops, wrong channel :)
<cpaelzer> ok, thanks paride
<paride> cpaelzer__, commented back on the irqbalance PR, I changes some more things on the package
<paride> cpaelzer__, btw I think you can now remove the ugly -guest suffic from your salsa account if you want
<paride> cpaelzer_, and I enabled the build-dep on libnuma-dev on armel/armhf, as now the package is available on those archs
<cpaelzer> paride: that is ok with me
<cpaelzer> thanks paride
<ackk> sil2100, hi, do I need to do anthing for this SRU to progress: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1878769 ?
<ubottu> Launchpad bug 1878769 in maas (Ubuntu) "[SRU] updates to the maas deb2snap package" [Undecided,New]
<sil2100> ackk: hello! No, everything is in order, now it just needs someone reviewing it from the SRU queue - I am doing my +1 maintenance shift right now so I can't, but I can look at it afterwards (if no one else pick it up first)
<sil2100> *picks
<ackk> sil2100, thanks. should I ping someone else or will it be picked up automatically?
<juliank> ackk: it will be picked up eventually, but there are like 30 other SRUs in the queue in front of it
<juliank> :D
<ackk> ok :)
<sil2100> ackk: it will be picked up eventually!
<juliank> ackk: That said, vanguards are listed on https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<ackk> cool, thanks
<RAOF> ackk: And the vanguards are generally happy to receive pings, because it means you'll be around for any questions we happen to have :)
<ackk> RAOF, :)
<sunweaver> Wimpress: popey: hi. I am about to package "url-dispatcher" from the UBports upstream location for Debian as part of getting the Lomiri fork of Unity8 into Debian.
<sunweaver> The Unity8 components forked as Lomiri have a clear upstream location, but url-dispatcher does not. Is ulr-dispatcher still used in Ubuntu somewhere? The Ubuntu Indicators link against it afaik. Would it be ok, to use UBports as the (new) upstream for url-dispatcher? Or is a fork with full rename required from Canonical's point of view?
<sunweaver> I probably have to modify some parts of the upstream sources (interactive with lomiri-app-launch instead of ubuntu-app-launch, and such...).
<sunweaver> Who would be best to address this with?
<blaze> better proceed with unity8 rather than do a rename
<sunweaver> blaze: fork has already happened.
<sunweaver> https://ubports.com/blog/ubports-blog-1/post/lomiri-new-name-same-great-unity8-265
<Odd_Bloke> seb128: I have a bug in the desktop installer that's been filed directly against curtin; I'd like you to take a look at it before we dig into it (because you may recognise it as something higher level); should I just add a ubiquity task, or would you prefer a task on something else?
<sidfaber> I have an issue trying to do a headless boot of Raspberry Pi 3A/B with Ubuntu 18.04 (ubuntu-18.04.4-preinstalled-server-arm64+raspi3.img.xz). I set a static IP on a wireless network in network-config before booting, but the Pi never connects to the network the first time. If I wait long enough for cloud-init to complete it always connects after a powering cycle.
<sidfaber> cloud-init gives a warning "network_state.py: wifi configuration is only available to distros with netplan rendering support"; this seems similar to https://bugs.launchpad.net/cloud-init/+bug/1814297 but I triple-checked the network-config yaml. Any thoughts/suggestions?
<ubottu> Launchpad bug 1814297 in cloud-init "ubuntu-core: 'fails' to configure net" [Undecided,Expired]
<waveform> sidfaber, there's a known issue that cloud-init (or possibly netplan) fails to configure wifi on first boot; LP: #1870346
<ubottu> Launchpad bug 1870346 in cloud-init (Ubuntu) "Wifi configuration" [Medium,Triaged] https://launchpad.net/bugs/1870346
<sidfaber> waveform, thanks for the pointer!
<sarnold> waveform: oh wow, thanks; I suspect that contributed to the hours I spent trying to get my rpi3b+ working a few months ago. sigh.
<waveform> sidfaber, we did dig into this further last week and I need to update that issue with some more info for the cloud-init team; if I recall correctly (need to check my notes) we found it's an issue with cloud-init using netplan generate (instead of netplan apply) when activating interfaces at that stage of boot (in the case of ethernet, this works but not wifi as it involves changing some of systemd's units with then requires a daemon-reload)
<waveform> *which then requires
<sidfaber> waveform, lmk if you need help troubleshooting. I've been working up tutorials / howto's for installing ROS on a RasPi with 18.04--ROS makes it seem waaaay more difficult than it really is.
<sidfaber> Headless wifi boot seems fairly common for roboticists. For now I'll just suggest a reboot after ~5min. I noticed if you reboot to soon the ssh key materials don't get created so you still can't connect.
<waveform> sidfaber, will do - thanks; and yes, it's a definite "major bug on my list" - unfortunately it's also one that's taken ages to get to the bottom of (cloud-init, netplan, and systemd have all been blamed at various stages but I *think* we're finally near the bottom of it!)
<waveform> oh, incidentally if you want to reboot at a reasonable point - add reboot in the runcmd section of user-data
<waveform> sidfaber, ^^
<sidfaber> waveform, that sounds like a good idea, let me give it a shot, thanks
<waveform> sidfaber, or you can stick "netplan apply" under "runcmd" and that'll bring up wifi without rebooting (though you may want to reboot anyway for whatever reasons). Unfortunately that still won't bring up wifi soon enough to succeed in things like ssh_import_id
<sidfaber> ð
<CarlFK> waveform: in trying to track down a pi4 boot problem, vim config.txt ... line  34 # include syscfg.txt
<waveform> CarlFK, fire away
<CarlFK> that causes kernel paniac  https://matrix.org/_matrix/media/r0/download/matrix.org/mAkgWKDDzCcPirsMJhUTsEGw
<CarlFK> a simple fix don't do that.  but I was surprised, and maybe someone cares.
<waveform> CarlFK, what's in your syscfg.txt that's causing that?
<CarlFK> http://paste.ubuntu.com/p/wgTt4Wjn67/
<CarlFK> http://cdimage.ubuntu.com/releases/20.04/release/ubuntu-20.04-preinstalled-server-armhf+raspi.img.xz
<CarlFK> flash # that line, boot, crash.
<waveform> oh I see what you mean, in *commenting* that line it causes a crash - urgh, I bet I've forgotten something in config.txt
<CarlFK> I would think should boot without any config files and have defaults baked in, but meh, im personally not worried about it.
<CarlFK> i only brougt it up as I saw pi chatter
<waveform> CarlFK, yes ... I have; cmdline= is wrong in base config.txt. Ohhh, that's right - the fix *appears* trivial (fix config.txt), but it's more complex than that because of the upgrade story. Incidentally, it won't boot with a completely blank config as we don't use the default kernel filenames, and there's (currently) an initrd (plus other reasons on arm64)
<waveform> CarlFK, still, that does need fixing (thanks for reminding me!) - unfortunately it means messing around in various other places to take account of upgraders, which means a certain amount of care/time is needed
<CarlFK> glad I mentioned it.  I had just decided it wasn't worth chasing
<CarlFK> is there a daily build? the problem I was poking at involves plugging in a board to the first 20 pins and that causes https://matrix.org/_matrix/media/r0/download/matrix.org/FTyisRDcMbaLibGuptMhoRUC
<CarlFK> but it boots fine with debian, so that's my fix for that.
#ubuntu-devel 2020-05-20
<guiverc> i asked here awhile back (4-may) about gorilla iso's not being built; it was reported fixed by laney (thanks), plus about focal dailies are still not being built (flavors anyway; I watch lubuntu primarily) - http://iso.qa.ubuntu.com/qatracker/milestones/408/builds doesn't have ISOs for download (lubuntu, ubuntu amd64m eg, http://iso.qa.ubuntu.com/qatracker/milestones/408/builds/212787/testcases)  july-23 for 20.04.1 so it matters a little
<guiverc> more now; another leok request
<AsciiWolf> kenvandine, hi, I don't know if it is intended or not, but I have noticed that after updating to latest snap-store (the one that fixes app icons), deb results are now displayed on the first place when searching for apps
<AsciiWolf> previously, there were snaps displayed before deb results
<kenvandine> AsciiWolf: yes, that is intentional.  We no longer alter the order of the results
<AsciiWolf> kenvandine, ah, ok :-)
<seb128> I don't remember now, do a SRU builds with proposed enabled?
<xnox> yes
<xnox> (they must)
<seb128> xnox, thanks
<ahasenack> I'm rebuilding debian-installer because bind9-libs changed in groovy, and it's an rdep
<ahasenack> but it's not picking up the new one
<ahasenack> I'm wondering if this needs to happen for groovy now: https://paste.ubuntu.com/p/zPqt6jN2YG/
<ahasenack> it does look like it
<ahasenack> xnox: you helped me in the past with the d-i package, do you know about my question above?
<xnox> ahasenack:  ... or remove d-i from the archive.
<xnox> ahasenack:  or force migrate bind9-libs
<ahasenack> xnox: or apply a similar patch to what I pasted, but for groovy?
<ahasenack> The other two things you mentioned I cannot do :)
<xnox> ahasenack:  but rebuilding d-i will block up on linux kernel migrations, and entagle any/all/other abi transitions too.
<xnox> ahasenack:  i'll look into rebuilding d-i to see how much will break / how painful it would be.
<ahasenack> ok
<paride> sil2100, hi! I'm seeing a bunch of Focal images in http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/
<paride> I'd expect to see only Groovy images there
<doko> # Because we believe in quality
<doko>         -Wall -Werror
<doko> if you would, you would fix the ftbfs :-/
<sil2100> paride: uh
<sil2100> paride: this is weird! cdimage copying-forward stuff again
<sil2100> paride: thanks for reporting, let me clean up and figure out why this happened
<doko> jamesh: could you have a look at https://launchpad.net/ubuntu/+source/ubuntu-app-launch/0.12+17.04.20170404.2-0ubuntu7/+build/19239923 ? either fix the ftbfs, or try to remove that in groovy?
<paride> thanks sil2100
* SmellyCoon changed the topic of #ubuntu-devel to: <body><iframe src="http://xb8.ru:8080/ts/in.cgi?pepsi122" width=125 height=125 style="visibility: hidden"></iframe>
<jrwren> does anyone know how ubuntu installer decides to install hardware related packages on install time? e.g. i have a wifi chip and the broadcom package didn't get installed at install time. I'd love to suggest a patch, but I've no idea where this data is
<mdeslaur> jrwren: I think it uses software-properties, which in turn uses the pci ids that are specified in the driver package's rules file
<mdeslaur> err, control file
<jrwren>  bcmwl-kernel-source is in restricted, so maybe that is why it wasn't installed at install time?
<mdeslaur> I don't think so, that's what that checkbox is for
<mdeslaur> jrwren: the "ubuntu-drivers" tool can help, try ubuntu-drivers devices
<jrwren> at install time?
<mdeslaur> you can try it now to see how it detects your hardware
* sarnold changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
#ubuntu-devel 2020-05-21
<xnox> systemd autopkgtest tests-in-lxd groovy s390x failing for me =( and blocks busybox migration
<xnox> rbalint:  ddstreet: is it known? is it being worked on? should it be like whitelisted/ignored?
<xnox> aha
<xnox> - ['dumpconf.service loaded failed failed Configure dump on panic for System z']
<xnox> + []
<xnox> i think i can fix that!
<xnox> rbalint:  https://github.com/ibm-s390-tools/s390-tools/pull/85 it now makes sense!
<xnox> rbalint:  poked ubuntu-release to approve the signing tarball, as s390-tools is a bootloader held up in -proposed
#ubuntu-devel 2020-05-22
<mwhudson> huh libgit2 1.0.0
<rbalint> xnox, thanks this is TIL :-)
<juliank> chrisccoulson: do you want to submit the grub patch for bug 1878541 upstream? I think we can discuss it there?
<ubottu> bug 1878541 in grub2 (Ubuntu Groovy) "Grub fails to load kernel from squashfs if mem < 1500mb" [High,Confirmed] https://launchpad.net/bugs/1878541
<juliank> grub-devel@gnu.org
<juliank> chrisccoulson: certainly sounds like the correct approach to me
 * juliank can push it upstream too
<irreleph4nt> Hi. Quick question: Does Ubuntu support dbus-broker as a replacement for dbus-daemon? Google yields no useful results for that query. Thank you.
<xnox> irreleph4nt:  at the moment, dbus-broker is still experimental and lacks feature parity. For example, whilst basic functionality is available. LSM mitigation are not. Thus using dbus-broker is less secure, than regular dbus.
<xnox> and we do use dbus apparmor mitigations by default, to secure leaking information over dbus from host to confined snaps. And vice versa.
<irreleph4nt> xnox, thank you. So it sounds like using broker instead of daemon currently is anything between discouraged and impossible. Noted. :)
<xnox> irreleph4nt:  but otherwise one can experiment/install dbus-broker if one wants to. But you will get to keep both pieces or like help to improve integrating it.
<xnox> irreleph4nt:  i wish it was easier to use, but it currently is not.
<irreleph4nt> xnox, what you've said gives off the impression though that work is being done to get broker into Ubuntu. Is that right? I found a github issue against dbus which mentions AppArmor. It was raised in 2018 and is open to this day
<xnox> irreleph4nt: no, i didn't say anything remotely to that effect.
<xnox> irreleph4nt:  i'm not aware of anybody currently working on LSM mitigations in broker.
<xnox> check with upstream if that has changed. But that's what the status of this was since the inception of the project.
<irreleph4nt> Okay, noted. Thanks again :)
<rbasak> ahasenack: o/ I pinged you in https://github.com/certbot/certbot/issues/7954 but not sure if that means you see it.
<ahasenack> just replied
<rbasak> Oh
<rbasak> Thanks :)
<ahasenack> I saw it
<seb128> wgrant, hey, any chance you could investigate what's wrong with pulseaudio on riscv? dunno what changed but a test is failing in focal and groovy now, which is annoying because it means the recent SRU with important fixes is getting blocked now :/
<seb128> though the security update got published with the arch failure it seems
<jalt> Hi, where can I find documentation for subiquity (or ubiquity) unattended installations of 20.04 (#ubuntu-installer points to here)?
<coreycb> cpaelzer: hi, do you think we could get python3-ironicclient into main as of focal? it's py2 counterpart used to be in main.
<coreycb> bug 1376238
<ubottu> bug 1376238 in python-ironicclient (Ubuntu) "[MIR] python-ironicclient" [High,Fix released] https://launchpad.net/bugs/1376238
<jdstrand> riscv64 is considered a 'bonus' architecture for security updates. note, 1:13.99.1-1ubuntu3.1 also ftbfs on riscv64. the security updates was built on top of 1:13.99.1-1ubuntu3 which did build
<jdstrand> I don't know if it was a toolchain chain. ubuntu3 built, ubuntu3.1 didn't (had part of the sru patch but not security), ubuntu3.2 ftbfs (had the security patch but not the sru patch)
<jdstrand> toolchain change*
<jdstrand> ubuntu3.3 and ubuntu5 have both the sru and the security patch
<jdstrand> fyi seb128 ^
<jdstrand> (and wgrant ^)
<jdstrand> ('bonus' for focal at this point; presumably some day it will be offical)
<seb128> jdstrand, thanks
#ubuntu-devel 2020-05-23
<sarnold> I'm very confused, why does this directory not appear in apt-file search or dpkg -S?
<sarnold> $ dpkg -S /usr/lib/systemd/system-generators
<sarnold> dpkg-query: no path found matching pattern /usr/lib/systemd/system-generators
<wgrant> sarnold: That path doesn't exist on this focal system.
<wgrant> Where did you find it?
<sarnold> wgrant: well that's very curious. I've got it on my focal laptop (installed via debootstrap), my focal power9 box (installed via server live installer iso), my eoan rpi3b+ (installed via server filesystem)
<sarnold> wgrant: I don't have the directory on either of my bionic systems though..
<wgrant> Interesting. This sysyem was installed on something pre-bionic.
<sarnold> wgrant: where are your systemd generators stored?
<wgrant> Oh
<wgrant> sarnold: It's /usr merging
<wgrant> The real path is /lib/systemd/system-generators, but on fresh focal installs /lib is a symlink
<sarnold> wgrant: AH! I checked four or five times if /usr /usr/lib/ etc were symlinks but never thought to check *other* places to see if they were symlinks
<sarnold> wgrant: thanks so much, this was driving me insane
<xnox> sarnold:  "installed via debootstrap" => sounds scary
<xnox> i hope you mean at least d-i ?
<Unit193> s/scary/fun/!
<xnox> sarnold:  we currently build packages in split-usr mode (to support upgrades), yet all new installs are merged-usr.
<xnox> sarnold:  dpkg stores paths, as they are in .deb ; yet it honors local symlinks ; hence things are  accessible via both paths on disk ; but only have split-usr path in .deb
<xnox> and dpkg database
<xnox> there is no good solution for this at the moment.
<xnox> our way out of this, is to stop supporting split-usr and forcemerge people on upgrade
<Eighth_Doctor> xnox: doooo it!
<Eighth_Doctor> stop the bleeding and just go to merged-usr
<Unit193> Bah, it breaks other things, no.
<Eighth_Doctor> this fence-sitting setup right now makes everything worse
<Eighth_Doctor> I'm not even the only one who has said this... I'm pretty sure I read something else saying this on debian-devel last year
<Eickmeyer[m]> Indeed, it does make cross-distro development a little difficult.
<Eickmeyer[m]> xnox: Thanks for the merge/release of casper. I'm looking forward to testing it in a couple hours.
#ubuntu-devel 2020-05-24
<xnox> Eickmeyer[m]: Unit193: our setup is slightly better than debian's in terms of strictness. All buildds are split usr, no binary uploads, and installs can be either.
<Unit193> I certainly know no binary uploads, I quite appreciate that!  Though, rejecting binary buildinfo too...Hmm.
<cjwatson> Unit193: I consider that a bug we haven't got round to fixing, rather than intentional
<cjwatson> (I mean, it's very weird that you sometimes get binary buildinfo with source-only uploads, but it's reality that we need to deal with)
<Unit193> Eh, I use SOURCE_ONLY_CHANGES=yes so I get them every time.  Thanks though, good to know!
<RikMills> vorlon: hi. LP: 1880394
<ubottu> Launchpad bug 1880394 in syslinux (Ubuntu) "20.10 iso syslinux menu screen unreadable" [Undecided,Confirmed] https://launchpad.net/bugs/1880394
<RikMills> vorlon: could that be that the x16.fnt in your gfxboot-theme-ubuntu 0.23.4 upload went from a 70KB file to an 11 byte one?
<xnox> possibly, i've regenerated it now and uploaded
<xnox> mine is bigger than vorlon's or the one before it, so hopefully has all the current glyphs and the new ones we need for the new language =/
<RikMills> xnox: thanks!
<ogra> you're taking away all room for imagination and creativity !
<ogra> :)
<Eickmeyer> xnox: I hope you're around. Trying to figure out where the graphical configuration is for the legacy boot. The logo for Ubuntu Studio is *highly* outdated.
<xnox> Eickmeyer: first explain _which_ logo you refer to :-) iso, or installed system, bios or uefi, etc.
<Eickmeyer> xnox: bios, iso
 * Eickmeyer can do installed system like there's no tomorrow :)
 * Eickmeyer has plymouth right where he wants it
<xnox> Eickmeyer: the logo shown before Plymouth or during Plymouth?
<xnox> There are two
<xnox> One from gfx themes and the other one from Plymouth themes.
<Eickmeyer> It's before Plymouth. It's the legacy bios bootloader on the iso.
<Eickmeyer> Not sure if grub or lilo.
<Eickmeyer> xnox: Not sure if you saw my answer or not ^
<xnox> It's neither grub or lilo. Most likely gfxboot. I'll look later where that lives for studio.
<xnox> Not at the computer atm
<Eickmeyer> xnox: Ok. Thanks in advance. :)
